bpa wrote: > THis is my theory. AFAICT the design of LMS expects each player to be > served with data until it is "Full" (or in the case of live a threshold) > whereupon it will go quiet, play the audio at normaltime and then data > need only be sent to it a in small lumps as audio data is consumed. The > round roibin scheduler in LMS shares its time amongst web pages and > players. You said Castbridge has effectively an infinite buffer in > which case it will take a whole audio file before saying full so for a > burst it will take a disproportinate amount of time compared to the > players but with a finite file it will end. I've made DASH live stream > to be infinite and the player's buffer is infinite. > > This needs ot be checked out and also determine why/how HLS does not > fall into this trap and at the same time avoid the rebuffering/DNS > problem of HLS.
Doesn't the LMS scheduler spread time to each player on the GET response ? Still, if it happens to be a problem, setting <buffer_limit> gives flow control, unless the UPnP player eats everything as well (and some do). In such case, I have no way to know what the real internal buffer level of the player LMS 7.7.5 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos 2xPLAY:1, PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBMC, Foobar2000, XBoxOne, JRiver 21, Chromecast Audio, Chromecast v1, Pi B2, Pi B+, 2xPi A+, Odroid-C1, Cubie2 ------------------------------------------------------------------------ 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
