bastrup wrote: 
> Hi Again, 
> 
> Did a test setup: Tidal -> LMS (Pi) -> squeezelite (Windows). After a
> couple of start up problems, it played complete playlist > 20 tracks
> without any skipping in tracks.
> 
> However, by accident it did a parameter change in the upnpbridge
> configuration, that made things work again. I changed the "Pacing size"
> to >"-1" - i.e. infinite. After that, playback has been errorfree. Also,
> I do not see the connection reset by peer in log any longer. Just to
> validate, I did a change back to the original 1MB and sure enough the
> problem reappeared. No idea on why this work, could it be related to a
> more gracefull way of closing the connection?
> 
> I've attached an updated log for working setup, together with
> configuration, if you want to inspect further. Please let me know if you
> need any more information. 
> 
> So all in all, problem fixed, things are working again :-)

What's likley to happen is a timeout on Tidal side. A few technical
explanations if you are interested

- SB players start requesting data and will consume as much as the
source (LMS/Tidal) can provide to fill up their internal audio buffer
(that can create a demand spike at the beginning)
- When the buffer is full, they will use TCP flow control to regulate
the HTTP download from LMS/Tidal
- During playback, player's buffer will empty and so players will use
TCP flow control to get more data from LMS/Tidal and so on.

- When using my bridges, you have 2 levels of buffering : the one that
my bridge does (and by default it is unlimited) and the one that the
UPnP player does, which can be pretty large as well and is
unknown/uncontrollable
- In other words, the Bridge receives as much data as it can from LMS
(using the normal LMS HTTP/TCP flow control), put that in a local file
and then uses again HTTP/TCP to forward that buffered data to the UPnP
player
- I cannot control what the UPnP player requests, he controls me (and I
don't want to "guess" how much data the UPnP player has really
consumed)
- The Bridge unlimited local buffer mode can creates very large and long
spikes of data download to LMS and some services like iBBC are suffering
from that
- A while ago, I added the parameter <buffer_limit> that limits the size
of the Bridge's buffer and avoid too long spikes, but that has a
consequence on some player pause/resume capabilities (they want to seek
from the beginning of the data ...)
- I also added another parameter <pacing_size> which limits the amount
of data that the bridge can store "ahead" of the UPnP player. So, with a
limit of 1MB, when the UPnP player "flow controls" me, then I "flow
control" LMS as soon as the gap between what I have in my buffer and
what the player has accepted is more than 1MB. Still, if <buffer_limit>
is set to -1, I will buffer the entire track, but I will buffer it
"slowly" versus as fast as I can

- Long explanation to say that the consequences of all these buffering
is that the Tidal side of the flow can see large pauses because even
with pacing of 1MB, if your UPnP player accept 64 MB of buffer, the
bridge will get from LMS/Tidal these 64MB and will forward it all. When
the UPnP player "flow control" me, I'll gather another 1MB and then
pause until the UPnP player requests more ... but that can be a long
pause and maybe, what happens there is that Tidal sees an idle time that
is too long and then closes the connection with LMS. That's just an
hypothesis, but seems to be consistent with what you experience.

So, net net, if your player does not have problem with pause/resume, you
potentially can use <buffer_limit> instead (put it at 16MB) and with
that, the flow should be smoother, end to end.



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=103728

_______________________________________________
plugins mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/plugins

Reply via email to