Amazing sleuthing, Philippe and Ralphy. :cool: A very tricky and obscure
bug.
I've been using r1419 with the default buffer size (no -b argument) for
a week without any issues. Have a Happy New Year!
thickasabrick's
Thank you philippe_44.
I've updated these lmsclient windows builds with the change.
'squeezelite 1.9.9-1419'
(https://sourceforge.net/projects/lmsclients/files/squeezelite/windows/)
'squeezeplay 8.0.1r1420'
(https://sourceforge.net/projects/lmsclients/files/squeezeplay/windows/)
and
'Marco
Resuming that discussion I think we have a final view and fix of the
problem which is a general problem, not specific really to us. I'll use
an example to describe the problem, although it is not exactly the flow
of events for squeezelite
- an mp3 file is 3.5 MB at 160 kbits/s = 20 kB/s
- a
Thank you, Ralphy and bpa!
Indeed, there are many threads that describe similar bugs, and I have
been using the "Cache HTTP(S) streams on disk" option.
The puzzling thing is that using a very large buffer size (-b 524288)
continues to work as a workaround in my case, including with
ralphy wrote:
> The issue you describe has been reported by other forum members and
> happens on hardware players too.
> I'm not discounting that there my still be an issue with the windows
> squeezelite builds, but
>
> The following google search returns at lot of different threads
>
thickasabrick wrote:
> Hi, Ralphy! Thank you for looking into this.
>
> I've tested v1.9.9r1401 with the default buffer sizes (no -b option) and
> have these observations to share:
>
> > > >
- playback still stops near the end of a long stream (ex. a 45
> minute long podcast)
-
Hi, Ralphy! Thank you for looking into this.
I've tested v1.9.9r1401 with the default buffer sizes (no -b option) and
have these observations to share:
- playback still stops near the end of a long stream (ex. a 45 minute
long podcast)
- playback does not, however, automatically resume
I've uploaded new 'windows builds of squeezelite v1.9.9r1401'
(https://sourceforge.net/projects/lmsclients/files/squeezelite/windows/)
which includes a change that should fix the issue.
If you have changed the buffer sizes to workaround the issue using the
-b option, please removed it, or
bwong wrote:
> I had been using Squeezelite-X from the Windows store on Windows 10. I
> just downloaded the latest Squeezelite here:
>
> https://sourceforge.net/projects/lmsclients/files/squeezelite/windows/
>
> It does not have the GUI but I usually use the web interface anyway so
> starting
I had been using Squeezelite-X from the Windows store on Windows 10. I
just downloaded the latest Squeezelite here:
https://sourceforge.net/projects/lmsclients/files/squeezelite/windows/
It does not have the GUI but I usually use the web interface anyway so
starting it in a DOS window is
I am seeing the same problem but my LMS server is running Rocky 8 as a
VM under Centos 7. The client is running on Windows 10. I have not been
able to track it to the level of detail here which is impressive but I
am seeing the same mode of operation.
Yes, I'd like to track down this issue.
So far, I haven't been able to recreate it locally. I will try your
method. Thanks.
Before commenting on your findings, I'd like to take some time to digest
them.
I'm in the middle of another lms project ATM so it will take some time
before I get to
Here's a visualization of the output underrun, the pause, and resume:
36848
I was wondering why this might be Windows-specific. A total shot in the
dark, but any chance it has to do with differences with Windows
sockets?
>
> Under BSD Unixes, if the remote peer closes its connection and your
Hi Raphy,
Thank you for maintaining Squeezelite! It's a great piece of software.
Sorry to resurrect an old thread, but I wanted to express interest in
squashing this bug if you were game to keep digging. My details:
* intermittent pauses in playback, about 20s long
* seems to happen most with
Ralphy, thanks so much for looking into this.
The good news is that your change did take effect, and client machine
now initiates TCP Keep-Alive packets every 30 secs after last
transmission from the server (frames 22775 and 23007 in Wireshark trace
below).
The bad news is that Linux TCP stack
Thanks for taking the time to research what's happening. Sorry, it's
taken so long for me to reply. There is a lot of information to digest
and I wanted to take the time to review it all.
One thought I had was if enabling tcp keep alive would prevent the
server closing the socket. I've sent
Last thing I was curious about is why only Windows users are seemingly
experiencing this issue. Logically thinking, the underlying condition
should be happening on Linux just the same. I ran a test on Linux to
find out.
34918
As we can see, TCP flow timing on Linux looks very similar to
We have a lot of different variables at play here: song size, song
bitrate, LMS, squeezelite, squeezelite stream buffer, server TCP send
buffer, client TCP receive buffer, server TCP FIN timeout. Lets briefly
look into what each of these contribute.
Song size and song bitrate - we don't have
Now lets look at the squeezelite logs:
Code:
[01:16:08.861] stream_thread:428 streambuf read 3132 bytes
[01:16:08.961] stream_thread:428 streambuf read 1566 bytes
[01:16:09.026] sendSTAT:166 ms_played: 328110 (frames_played: 14470092
device_frames: 441)
After the pause LMS starts streaming again, then pauses once buffers
fill up.
Code:
[21-06-01 01:11:41.5583] Slim::Web::HTTP::sendStreamingResponse (2168)
sendStreaming response begun... <-- streaming resumes after
the second pause
[21-06-01
LMS continues sending data to squeezelite non stop until buffers fill up
and then it pauses.
Code:
[21-06-01 01:10:42.7389] Slim::Web::HTTP::sendStreamingResponse (2168)
sendStreaming response begun...
[21-06-01 01:10:42.7390]
I figured the best way to explain the failure mode I am experiencing is
to combine/correlate data from LMS logs, squeezelite logs and network
traffic capture. Please note that Wireshark is running on the client
machine so Wireshark and squeezelite timestamps match, time on LMS
machine is ~2 secs
Thanks for your response guys, I did some more testing and I have a
pretty good idea of what is actually happening, but don't have time to
post all the details right now, maybe tomorrow.
Just to quickly answer your questions.
bpa wrote:
>
> You have virtualised system - can you give more
There have been 'similiar discussions in the squeezelite thread'
(https://forums.slimdevices.com/showthread.php?97046-Announce-Squeezelite-a-small-headless-squeezeplay-emulator-for-linux-(alsa-only)=981302=1#post981302).
The discussion goes on for many pages and I have not been able to
lngxa wrote:
> Few other musings:
>
> > > >
- this issue does not happen when playing flac most likely because
> it is higher bitrate so it drains output buffer quicker
- easiest way to reproduce this is probably to use long mp3 file
> with low bitrate
- there are few other
Few other musings:
- this issue does not happen when playing flac most likely because it
is higher bitrate so it drains output buffer quicker
- easiest way to reproduce this is probably to use long mp3 file with
low bitrate
- there are few other reports of a similar issue in this
Looked a little bit deeper into this issue. First I thought this might
be the same issue as described in this thread
https://forums.slimdevices.com/showthread.php?113554-SqueezeLite-on-Windows-pausing-interruption-dropout-of-audio-every-5-minutes,
but now I am not so sure about that.
Here are
I am attaching LMS log, but here are some pointers to locations in the
log
STMo received
Code:
[21-05-31 01:11:50.0069] Slim::Networking::Slimproto::_stat_handler (784)
00:02:c9:aa:bb:cc: STAT-STMo: fullness=1952, output_fullness=-1, elapsed=164.249
Since this is my first post, let me start by saying thank you to all the
devs and community for a great product.
I am having a weird problem that I need help figuring out. When I stream
from LMS to squeezelite the music sometimes stops playing for 20-30
seconds and then resumes playing again.
29 matches
Mail list logo
