philippe_44 wrote: > This happens because the Sonos reports a time progress of 0 (it means it > has started the track Mogwai) but does not report a "PLAY" event and as > the previous track (Beatles) was very short, it has received all the > Mogwai track so the state machine of the bridge is fooled and believes > that Mogwai has been fully played and so request the next track from > LMS... > > It is *very* complicated because of the variety and non-compliance of > many UPnP devices, some never send the events that they are supposed to > send. So I've tried a very risky modification in that sync state > machine, let's see.
So that's not going to work and I don't have a solution, let me explain why In UPnP, a player can maintain 2 track contexts: the playing one and the queued one. It is used for gapless and it automatically moves to the queued context when the playing one reaches its end. It's possible to read which context is active and thus to detect what is being played. When they switch between contexts, players might send a "transition" event then a "play" event which can be used as well to detect change, but they don't always do, so the safest method is to poll the active context and detect the transition. The bridge informs LMS that the "virtual" player is ready for a new track when the current data has been sent in full to the "real" UPnP player *and* the track has been confirmed to be playing. In response, LMS sends the next track and the bridge translates that into a UPnP queue request. What happen in your case is that the Beatles are quickly absorbed, so the bridge informs LMS which sends Mogwai. The bridges queues Mogwai and because Sonos has large memory buffers, it swallows it entirely while the Beatles are still playing. When the bridge detects that the Sonos has moved to Mogwai, it tells LMS that this track has started *but* because Mogwai has been sent in full, it also tells LMS that we are ready for the next track. LMS sends Mojave 3 and the bridge immediately queues it to Sonos. It seems that this is where the shit its the fan as Sonos seems to believe that this queue request should replace the current track and not just be put in the queue, so you hear just a fraction of Mogwai. I don't know what else I can do. It seems that I'm going "too fast" for the Sonos but I don' want to "wait a bit" before telling LMS to send the next track (it's really bad practice and looking for other troubles) and I can't see an event that would be produced by the Sonos (and all other UPnP players!) and that would allow me to wait. Now, why did it not happen on LMS < 8.1.1, well we have changed formats handling in LMS for more consistency and before it's likely that your Sonos was being sent pcm/wav all the time, which meant a different size of data and a different timing. LMS 8.1.x 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=103728 _______________________________________________ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
