Bugzilla – Bug 2218
"<playerid> mixer muting <0|1|?>"
Last modified: 2008-09-15 14:39:24 UTC
From joseph@controlability.com.au: "Btw, it will be great if the "<playerid> mixer muting" can be changed to something like "<playerid> mixer muting <0|1|?>", where the ? will return the current muting condition. :-)" Given the toggle behaviour is used today by the remote control, what is really needed is "<playerid> mixer muting <|0|1|?>" (i.e. support the toggle case). Muting is really an action term so supporting ? is strange. We could do "<playerid> mixer mute <|0|1|?>" and support "muting" as deprecated for legacy support. I agree that if the player is muted, "mixer volume ?" returning "mixer volume -30" is ambiguous given it is the same answer the valid command "mixer volume -30" would produce. If you sent the command yourself, there's a way out of it (check the reply against the command). When using "listen", it is impossible, but the real problem is that listen echoes queries when it should not, and I intend to fix that. The question really is what should "volume" return if the player is muted. Having it return negative values was a nice way to return in a single call both the muting state AND the unmuted volume. Maybe we can leave it as is and do a new set of commands to return a different data.
Now I understands how muting affects the value returned in the volume query (including fading timing), so I can live without the thing I initially proposed. Perhaps all we need is just a few lines of explanation of this behaviour in the CLI documentation (p.s. I am using cli-api.html all the time). :-)
SVN 5543 supports "<playerid> mixer muting <|?>". Will add "<playerid> mixer muting <|0|1|?>" for coherence real soon.