philippe_44 wrote: > 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 for that explanation Phillippe - the technical stuff is over my head, but i get the general concept. I edited the buffer value as you suggested, and in the first run-through, it was a success - first 4 tracks (same ones as in previous logs) played through with no truncation or skips - but the log info seemed odd because the track names did not show up - so i cleared the log and started the same album again - the log attached is from the second try with the same increased buffer value. There was a problem this time - first track Wildflower played through no problem; on the second track, Peace Dog, the song kept playing but the counter started skipping at 2:08, back to 2:00, up to 2:08, back to 2:00, etc. When the song completed, the track did not advance to track 3 - i advanced it manually, then stopped it in track 3 after 10 seconds. So the buffer size change has definitely altered the behaviour, but not consistently - any further thoughts on what is happening? Thanks again for your time on this! +-------------------------------------------------------------------+ |Filename: upnpbridge-log6buffer.log | |Download: http://forums.slimdevices.com/attachment.php?attachmentid=38750| +-------------------------------------------------------------------+ ------------------------------------------------------------------------ Spacegrass's Profile: http://forums.slimdevices.com/member.php?userid=68163 View this thread: http://forums.slimdevices.com/showthread.php?t=103728 _______________________________________________ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
