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, 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
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
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
