mherger wrote: > > Basically: if the buffer is larger than "a few tracks" (eg. 100MB), then > > these plugins could run into issues. > Michael
Where you able to find the problem? Is there any help I can provide? I don't think a "more than 2 tracks in buffer" issue exists with LMS. Normally, in slimproto, you can never have more than 1 playing track and one streaming track (I mean HTTP download). AFAIK, this is the slimproto exchange server wants to play track n 1) S ==> strm-s (i.e. play track n) 2) C ==> STMc (ack) client gets track n through HTTP (in streambuf) and decodes it (in outputbuf) client starts to play 3) C ==> STMs (track n started) ... once track n has been fully received and decoded 4) C ==> STMd (track n fully decoded, ready for n+1) 5) S ==> strm-s (i.e. play track n+1) 6) C ==> STMc (ack) client gets track n+1 through HTTP (in streambuf) and decodes it (in outputbuf) ... track n ends, client starts to play n+1 7) C ==> STMs (track n+1 started) ... once track n+1 has been fully received and decoded 8) C ==> STMd (track n+1 fully decoded, ready for n+2) then server instructs player to play track n+2 by going back to step 5) and so on What can happen with a very large outputbuf is that the end of decode of track n+1 (step 8) can happen before step 7, so the client requires the n+2 track (STMd) while track n is still playing. But LMS' state machine will not send another strm-s request for track n+2 before it has received a STMs (playback started) for track n+1, so you cannot have more than 2 "active" tracks, regardless of the size of your buffers. I don't think there is an issue here. Now what I have observed is a very different problem which is, with large buffers and on-line streaming services, the HTTP connection to acquire track n+1 can start very early but then stall for a pretty long time while track n is still being played (client uses TCP flow control and does not query more data from my bridge). Some services then think that something wrong happened with track n+1 because you started to GET it, but then stalled for an amount of time which is way more than the expected playback duration of what has been downloaded, so they assume that the client has a problem and then close the connection. Deezer and RP where identified as some of these Normally, I have a protection against that which is to not send STMd (step 4) of track n more than X seconds before the end of track n, so that n+1 does not start to "HTTP stream" too early (that's an ugly patch, but I have no choice) LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi B3, B2, Pi B+, 2xPi A+, Odroid-C1, Odroid-C2, Cubie2, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5 ------------------------------------------------------------------------ philippe_44's Profile: http://forums.slimdevices.com/member.php?userid=17261 View this thread: http://forums.slimdevices.com/showthread.php?t=104614 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
