philippe_44 wrote: > Thanks for the log. It's going to sound strange, but on every case it's > an error between LMS and the bridge, more precisely it's LMS that > disconnects with an "unknown cause" before everything has been sent. The > bridge signals that and LMS moves to next track. > > It seems that we received 5,243,095 bytes and that played for 185 sec > where the track should have lasted 237 sec. At that 185 sec time, the > UPnP player ran out of data and stopped, the bridge detected that and so > feedback that to LMS which moved to next netx track. > > Can you tell me the size of the file artist:Boss, Hog album:Whiteout, > title:Stereolight (and Nursery Rhyme)? > > PS: do you have other players (non UPnP) and have you notice that with > these? We'd need to investogate that wth @mherger but that log really > tells me (and that might very well be a Win10+ issue) that LMS *stalls* > the connection then *closes* it for no reason.
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." +-------------------------------------------------------------------+ |Filename: upnpbridge log 2 flac.zip | |Download: http://forums.slimdevices.com/attachment.php?attachmentid=39322| +-------------------------------------------------------------------+ ------------------------------------------------------------------------ Spacegrass's Profile: http://forums.slimdevices.com/member.php?userid=68163 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