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

Reply via email to