philippe_44 wrote: > The 2.1.12.2 is fixing that issue, not in a way I prefer, but that seems > to be the only option. You don't see the problem happening on higher > bitrate because that very special sequence only happens is the N+1 track > is small enough to fit in the buffers but compressed enough so that the > CC plays track N for a long enough before requesting N+1, and so the > TIME_WAIT issue happens.
The 2.1.12.2 plugin is now working reliably for me in passthrough mode on Windows with every codec and bitrate I have tried. The only problem I have now is that the "Feedback to LMS" function of "Player volume management" does not function correctly with my Google Nest Minis the way it does with the CC Video devices. Adjusting the volume by using Google voice or Home commands, or the volume buttons on the device itself, changes the volume but does not cause those changes to be reflected in LMS. As a result, the volume reverts back to it's last known LMS value at the beginning of the next track, due to the bridge preceding each track start with a volume change command using its last stored volume level. It didn't work that way prior to the "dev" versions as I often change the volume with "Hey Google" voice commands on the Mini in my bedroom at night, usually to lower it as I'm falling asleep. When I do that now, I am startled when the volume reverts to its previous higher value at the next track change. Again, the Google volume change commands for the classic CC video devices are passed through correctly to LMS, just not for the Nest Minis. Sam ------------------------------------------------------------------------ SamY's Profile: http://forums.slimdevices.com/member.php?userid=63495 View this thread: http://forums.slimdevices.com/showthread.php?t=104614 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
