Jobarr wrote: > Ah ha. That makes sense now! Thanks for explaining. > > > It showed the 3% if I remember right. That is, it started at 3, I turned > it up, paused it, it dropped to 3% on the device and in the UI and never > returned after playing again. > > > > That fits perfectly with what I have seen, some sort of echo feedback > loop. It probably kept trying to set it to 0%, seeing it bumped up to > 3%, and then assumed that 3% was the correct value that I set manually, > so it never saw a need to return to 43%. Even times when the volume > seems to jump around and needs to be reset several times before > stabilizing, it seems like LMS is constantly trying to catch up with > what the device is doing while making things worse by also adjusting the > device at the same time, causing it to have to catch up again. In any > case, no matter what value I set the device to in the UI, it is never > exactly that value on the device. It is always off by some small > amount. > > > The fact that it is not going to 0 might be a bug, but I have definitely > seen this weird feedback loop behavior on multiple devices from multiple > manufacturers (Nvidia, Google, and JVC). I just updated and will try > disabling the feedback to LMS. I can definitely live without that > function, and that sounds like it might solve the issue. Thanks a lot. > > I am still seeing an odd bug occasionally where it starts playing again > after pausing it or even pausing it after playing. I am having a had > time reproducing it, but I think I caught it here once: > 32870. Might this be the same issue? Is it possible > that LMS is seeing the "playing" or "paused" status with a slight delay > and then playing or pausing when it shouldn't? Maybe it would make sense > to ignore all feedback for x seconds after any change? > > Edit: Disabling the volume feedback is working well so far! (5+ hours, > with lots of pausing and resuming)
I'll look into the log, but I can't ignore the feedback because this is what allows me to confirm me that (e.g.) playback has started and that would have many ramification in the state machine to inform LMS of the status. In addition, I really hate using timers, usually they are crutches that ultimately lead to disaster. In any case, for command like play/pause/stop, the cast protocol offers a transaction ID that I'm using to discard any status information ID that is older than the most recent request ID, so it should be filtered out (I mean a "'paused" status polled after a "play" request has been sent will have a transaction ID lower than the play request ID and will be ignored). I'll investigate to see if there is some race condition. Still, the volume has a filtering timer to avoid ping-pong of the echo effect (i.e. when I send a command, every feedback is ignored within 1 sec) but volume is not an event, it's a status (like everything), that's why the "request 0 and read -anytime- that 3 got set" in your case was still failing, no filtering loop would have avoided that, no transaction ID would either. LMS 7.9 on Pi 3B+ & Odroid-C2 - *SqueezeAMP!*, 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, Riva 1 & 3 ------------------------------------------------------------------------ philippe_44's Profile: http://forums.slimdevices.com/member.php?userid=17261 View this thread: http://forums.slimdevices.com/showthread.php?t=104614 _______________________________________________ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
