Spacegrass wrote: > Hi Philippe - here is the further log. I will send you a link to the mp3 > files later today.
I thought the issue was something on my side but with further investigation, I'm back to believing that this is a socket issue with Windows & firewalls. Here is a reason why and I hope somebody will be able to confirm that: Streaming through the bridge is a long, multistage, pipeline. First, LMS sends the encoded samples to the bridge that stores them in a "stream" buffer of about 1MB. They are then decoded an put as raw pcm in an "output buffer" of 4MB. Of course in "thru" mode, they are just moved untouched from "stream" to "output". Then, they are re-coded (except in thru mode where they are untouched again) and put/copied in a "http" buffer of 2.5MB to finally be streamed to the upnp player (or chromecast). In normal LMS, as soon as a player has finished "decoding" samples (putting the last decoded "stream" byte into the "output" buffer, then it signals LMS that he is done with that track and LMS sends the next one. In the bridge the "end of decoding" happens then same way but you can see that in thru mode, the first track might very (very) quickly be absorbed: 1MB in the stream buffer, moved to 4MB in the outputbuffer, moved to a http buffer and gobbled by the player that usually have big buffers as well. When playing mp3 files of a few MB, it all happens in a few seconds. So the next track is requested pretty quickly. Now, without entering into too many details, the UPnP player is not ready to receive the 2nd track, so as far as LMS is concerned, the 2nd track will see a burst of LMS to bridge transfer and then everything will go stall *until* the first track is fully *played* (not received) by the player. Than means the connection between LMS and the bridge will be idle for minutes and what the logs say is that such connections seem, on your configuration, to be closed automatically by the system (and there is another user of the CC bridge who has the same issue). I don't think it's LMS, I've never seen such a timeout there, but I'll look again. With larger tracks, it is less likely to happen because the player will regularly call for data and activate the whole pipeline: get a bit from "http" buffer, which pulls a bit from "output" buffer which pull a bit from "stream" buffer, so there is always a bit of activity and when first track has been fully received by the bridge, the second one will start to be sent by LMS but it's likely not going to be such a big "idle" period. NB: This problem is very frequent with online streaming services and for these there is a dirty mechanism to not request track N+1 more than 15s before end of track N, but I don't want to extend that to local tracks. a local TCP connection should *not* be closed after 3 minutes on a well-configured system (usually 1 or 2 hours). If my hypothesis is correct, these firewall are way too aggressive LMS 8.2 on Odroid-C4 - *SqueezeAMP!*, 5xRadio, 5xBoom, 2xDuet, 1xTouch, 1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, RivaArena 1 & 3 ------------------------------------------------------------------------ philippe_44's Profile: http://forums.slimdevices.com/member.php?userid=17261 View this thread: http://forums.slimdevices.com/showthread.php?t=116980 _______________________________________________ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
