Music streaming stops intermittently

[ralphy]

I had been using Squeezelite-X from the Windows store on Windows 10. I just downloaded the latest Squeezelite here:

https://sourceforge.net/projects/lms...elite/windows/

It does not have the GUI but I usually use the web interface anyway so starting it in a DOS window is something that gets done when the PC boots. The latest version has no issues.

Thanks for confirming. I did make a change in that build to see if it helped.

[ralphy]

I've uploaded new windows builds of squeezelite v1.9.9r1401 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 change the values back to the default -b 2048:3446 before testing.

There are very few reasons to change the default buffer sizes in squeezelite and in many cases, larger buffers cause playback issues.

Thanks,

[thickasabrick]

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 after a minute or two — LMS is in "stopped" state
• an STMu (rather than an STMo) is now logged (along with an output underrun message)

Here are some logs, and please let me know if I can be of any further help.

[08:18:52.077] mad_decode:207 end of stream
[08:18:52.078] resample_drain:119 resample track complete - total track clips: 0
[08:18:52.078] process_drain:116 processing track complete - frames in: 109952687 out: 239352788
[08:18:52.078] decode_thread:100 decode complete
[08:18:52.078] sendSTAT:195 STAT: STMd
[08:18:52.078] sendSTAT:195 STAT: STMt
[08:18:53.005] process:528 strm
[08:18:53.005] process_strm:280 strm command t
[08:18:53.005] sendSTAT:195 STAT: STMt
[08:18:54.007] sendSTAT:195 STAT: STMt
[08:18:56.020] sendSTAT:195 STAT: STMt
[08:18:58.012] sendSTAT:195 STAT: STMt
[08:18:58.012] process:528 strm
[08:18:58.012] process_strm:280 strm command t
[08:18:58.012] sendSTAT:195 STAT: STMt
[08:18:59.019] sendSTAT:195 STAT: STMt
[08:19:01.039] slimproto_run:716 output underrun
[08:19:01.039] sendSTAT:195 STAT: STMu
[08:19:03.012] process:528 strm
[08:19:03.012] process_strm:280 strm command t
[08:19:03.012] sendSTAT:195 STAT: STMt

[ralphy]

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 after a minute or two — LMS is in "stopped" state
• an STMu (rather than an STMo) is now logged (along with an output underrun message)

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 reporting a similiar problem.

site:forums.slimdevices.com podcasts stop

[bpa]

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 reporting a similiar problem.

site:forums.slimdevices.com podcasts stop

Try WebUI Settings/Advanced/Network/Streaming mode for HTTP(s) -> Persistent

[thickasabrick]

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 v1.9.9r1401.

Thanks again for your help, and please let me know if I can provide any further information.