bpa wrote: > About the Get - normally the GET would either return with data or stay > open until source (e.g. BBC) has data to send - either way there is a > gap to allow other things to happen. With DASH URLs are allocated > sequentially (unlike HLS where an updated playlist has to be fetched) so > my player creates the next URL to become available but if player is very > demanding (I need to look at squeezelite to see how it handles the > thresholds) then URL is not ready and the GET is returned immeidately > by BBC with a 404 but becuase player is aking for more data - another > GET is scheduled asap so same invalid but it too will return in > millisecs and so on until in about 6 secs the URLS is readdy but then > DASH player will move onto next URL of next segment which is not ready > and so process will repeat.
okay, got it. About squeezelite, it has a 3 buffers, one for streaming, one for decoding and one for outputting to the sound card. Each buffer is managed by a different thread. They work obviously in cascade flow control and the stream thread does not read the socket if the stream buffer is full. In my bridges, I only use the stream buffer but it is immediately flushed to a file (assuming the file size is below the set limit if any). That file serves as a source for the GET of the UPnP/CCA 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
