Home of the Squeezebox™ & Transporter® network music players.
Page 3 of 3 FirstFirst 123
Results 21 to 26 of 26
  1. #21
    Senior Member ralphy's Avatar
    Join Date
    Jan 2006
    Location
    Canada
    Posts
    3,011
    Quote Originally Posted by bwong View Post
    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.
    Last edited by ralphy; 2022-02-12 at 04:54.
    Ralphy

    1-Touch, 5-Classics, 3-Booms, 2-UE Radio
    Squeezebox client builds donations always appreciated.

  2. #22
    Senior Member ralphy's Avatar
    Join Date
    Jan 2006
    Location
    Canada
    Posts
    3,011
    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,
    Ralphy

    1-Touch, 5-Classics, 3-Booms, 2-UE Radio
    Squeezebox client builds donations always appreciated.

  3. #23
    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.

    Code:
    [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

  4. #24
    Senior Member ralphy's Avatar
    Join Date
    Jan 2006
    Location
    Canada
    Posts
    3,011
    Quote Originally Posted by thickasabrick View Post
    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.

    Code:
    site:forums.slimdevices.com podcasts stop
    Ralphy

    1-Touch, 5-Classics, 3-Booms, 2-UE Radio
    Squeezebox client builds donations always appreciated.

  5. #25
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    21,493
    Quote Originally Posted by ralphy View Post
    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.

    Code:
    site:forums.slimdevices.com podcasts stop
    Try WebUI Settings/Advanced/Network/Streaming mode for HTTP(s) -> Persistent

  6. #26
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •