Spacegrass wrote: > Hi Phillipe - to answer your questions: 1) this track skipping only > happens on UPnPBridge players, not on "real" Squeezebox devices (i have > a Duet and two Radios). The album folder for "Whiteout" is 49.1 MB and > track Stereolight is 6.39 MB and track Nursery Rhyme is 6.20 MB. Those > are MP3 tracks. > Curiously, after i posted my message, I played a flac album and had no > skips (it was a different UPnP player - Sonos Arc instead of Naim QB2) > I attach that log (8 tracks played normally, and i stopped it in track > 9) > > We had a lengthy exchange about this skipping issue between Sept 17 and > 20 2022 in the "Announce: UPnPBridge ..." thread, which would of course > have occurred with prior versions of LMS and UPnPBridge - so maybe it is > a similar issue? You suggested at that time increasing the buffer size > in the bridge config file, which did seem to significantly lessen the > skipping. Here is one of your posts from then about possible causes: > "No, I really don't think so. The issue you are having might really be > due to the antivirus being overly protective of sockets. I've read that > some people had similar issue with the same antivirus/security suite. I > don't know how you are familiar with that part of technology, but to > communicate between the bridge and LMS, a channel must be opened using > two sockets (IP address and port). There are many complications with > sockets left open by programs on computers and although it should not be > the case, there is a risk of exhaustion or security and various solution > (not always great) have been developed to deal with these problem. > > The issue with the bridge is that when it opens a channel with LMS to > grab the audio data, the transfer is not smooth due to the nature of a > bridge and the numerous buffering involved (in the bridge and in the > UPnP player). So typically, the 1st track is very quickly transferred, > then the beginning of the second starts quickly as well and then... > streaming might pause for a very long time (might even be almost the > whole duration of the 1st track). So, for example, some on-line servers > can't cope with that and assume the link is broken and systematically > close it. What I'm wondering in your case is if a monitoring application > of some sort could not force-close such sockets that have a burst of > activity then *nothing* for minutes. It's not a good behavior, but... > > The test I'm asking you to do will ensure that no matter what (at least > for mp3) the whole track is quickly gobbled by the LMS-to-Bridge side, > regardless of what happen on the Bridge-to-UPnP side."
Thanks - Meanwhile I've found a interesting pattern that happens every time there is a failure. I think I understand what happens but not why it happens, so I'll continue searching 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
