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.
A
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
---
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 co
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 forum;
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 deta
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
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] Slim::Web::HTTP::sendStreamingRespons
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 0
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)
[01:16
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 an
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 Windows
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
12 matches
Mail list logo
