Bugzilla – Bug 11217
Un-mute does not work (from CLI)
Last modified: 2009-10-05 14:35:53 UTC
The muting toggle/on/off command causes the player volume to fade to zero on first use but no variation of the command can then restore (un-mute) the volume back to its previous level. Only way out is to raise volume from zero using the volume up command.
QA to try to repro. Assign to michael if so.
We are now planning to make a 7.3.3 release. Please review your bugs (all marked open against 7.3.3) to see if they can be fixed in the next few weeks, or if they should be retargeted for 7.4 or future. Thanks!
Edward: what firmware version and which player are you using to test with? Does the issue still happen with 7.3.3?
Since there's now a planned 7.3.3 release, bugs which won't make the cut-off are being moved to the next target out. If you feel that this bug needs to be addressed more (or less) urgently than the 7.4 release, please cc chris@slimdevices.com and leave a comment in the bug to that effect so we can review it. Thanks.
For some reason Bugzilla did not change the target when I did this yesterday. Or maybe it was me. In either case, I'm trying it again.
This bug is getting me significant complaints from users of my Software (The Pronto Controller). Is there any word on when this will be addressed. It is obviously recognized as a BUG and I always thought that bugs, especially those that can be reproduced get fairly high priority!
Edward: can you list out in the bug, the exact CLI commands you are using?
Also, there is a patch in bug 11973 which may address this issue, can you give that patch a try to see if it does?
Yes bug #11973 is discussing the same issue. SC code seems inconsistent in how muted state is represented. Either -1 * a valid volume or zero and the prefs mute flag. Mute via CLI fades to zero and sets the mute flag but in other places the -ve volume approach is used. Unmute command clears the flag but then applies * -1 to a zero value so (a kind of)muting remains. I attempted a fix but gave up because I could not see what the right approach should be (eg see comment in Utils/Alarm.pm ln 826 vs player/player.pm ln 445 and control/Commands.pm around ln 560 sub MixerCommand etc). I found this while using CLI these calls: mixer mute mixer mute 0 mixer mute 1 so nothing obscure.
*** Bug 11973 has been marked as a duplicate of this bug. ***
I guess as a person outside the basic development team but with a long history in software development my comments are as follows: 1) This needs to be fixed not talked about (no offense intended) 2) It does not matter the approach, however I favor the negative volume approach as it simplifies retrieving volume state 3) This used to work perfectly all the time prior to 7.3 4) It really does need to be fixed and soon!
Alan - is this a side-effect of the new streaming code?
I guess that has to be possible but I cannot think of any specific reason why it should be. I do remember looking at the volume mute/unmute code recently in passing and noticing that it seemed rather odd.
*** Bug 12503 has been marked as a duplicate of this bug. ***
Barry - investigating this issue right now. You said it was good before 7.3. Any 7.2.x? And any 7.3.x is broken? And just to be sure we're talking about the same command: it's "mixer muting", not "mixer mute", right?
Barry - I think I've found the culprit. Just to make sure I'm heading into the right direction: would a volume change on a muted player start at 0 again, or would it unmute before the volume change?
Micheal, I have worked around it, but as I recall the volume would be 0 when you did a volume change after muting it. The volume ould then advance as volume up commands were issued (signed positive integers)
Thanks Barry. Change 27319 - don't normalize volume when muted - unmute before changing volume using the mixer command - reset volume to 0 when doing relative changes using the mixer command, to match the IR behaviour
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server! * SqueezeCenter: 28672 * Squeezebox 2 and 3: 130 * Transporter: 80 * Receiver: 65 * Boom: 50 * Controller: 7790 * Radio: 7790 Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.