Bugzilla – Bug 2211
Strange return from "<playerid> mixer volume ?" query
Last modified: 2008-09-15 14:36:01 UTC
When a player is muted, the return value from "<playerid> mixer volume ?" is -ve. For example, if the original sound level is 50, when muted, the return is -50. This cause a problem that the feedback becomes exactly the same as the feedback when the user wants to "reduce" the current sound level by 50. An even more interesting thing is that if the interval between "<playerid> mixer muting" and "<playerid> mixer volume ?" is very short, the returned sound level is always "16" less than original one! For example, if the original sound level is 60, the return value becomes 44, if 55 -> 39, etc. But if the original is less than 16 (only 5/10/15 tested so far), the return value from the same procedure is -5/-10/-15. Or course, all subsequent ? query returns the -ve value as well. This doesn't happen if I'm typing the query by hand (probably because of the long interval between 2 queries), but appear consistantly in the program I wrote. Here's an example output, Sent: 00:00:00:00:00:00 mixer volume ? Got: 00:00:00:00:00:00 mixer volume 90 Sent: 00:00:00:00:00:00 mode ? Sent: 00:00:00:00:00:00 time ? Got: 00:00:00:00:00:00 mode play Got: 00:00:00:00:00:00 time 0 Sent: 00:00:00:00:00:00 mixer muting Got: 00:00:00:00:00:00 mixer muting Sent: 00:00:00:00:00:00 mixer volume ? Got: 00:00:00:00:00:00 mixer volume 74 The "sent" is the query sent by my program and the "got" is the reply from slimserver. Btw, this is a debugging message where I have procedures to do % encoding for the actual packets, but not presented here. I guess that there may be a racing condition happening at the slimserver's end. To support it, I also discovered this behaviour, Sent: titles 0 5 Sent: 00:00:00:00:00:00 mode ? Sent: 00:00:00:00:00:00 time ? Got: 00:00:00:00:00:00 mode stop Got: 00:00:00:00:00:00 time 0 Got: 00%253A00%253A00%253A00%253A00%253A00 time 0 It seems that if multiple query is sent at a very short interval, the reply of a long query will be corrupted, in this case, it's the reply of "titles 0 5" 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. :-)
Fred - any ideas here?
Joseph, Quite a nice one :-) First, SVN 4454 fixes your last issue. Titles and other extended query calls try to leave some idle time to the system and this was used to process the next command during execution of the current one. Oops. Also, SVN 4454 makes the behaviour of "mixer volume" in case of "mixer muting" coherent between muting and un-muting. There was a bug in the unmuting case. Now "mixer volume" returns the instantaneous volume of the player. "mixer muting" happens to fade the volume rapidly (1/3 of a second, asynchronously from the command). If you fire commands fast enough, you can see the volume go down. It did not happen when unmuting because the fading was broken. SVN 4454 fixes that, so now you can see the volume go up as well. The exact same code is called when using the mute remote control button. As for many CLI commands, there is little or no interpretation layer between the command and the internal server behaviour (like there is between the server and the player UI). When muted, the volume is returned as a negative number because this is the way the server remembers the volume before the mute. Likewise, you can read the falling volume in case of a mute if you're fast enough. Sleep also does a long fade before turning off the player and you can read this as well from the CLI if you try about a minute to 10 s before the sleep time. Both actions are hidden from the player UI. In other terms, what you are observing is the defined behaviour. I added comments in the documentation to this effect in SVN 4455. Given 6.2 is feature-frozen, I will add an enhancement request for your "mixer mute <0|1|?>" proposal.
Cool, thanks for the fix. I assume that the nightly release on 9/29 will include it, right?
Next nightly of 9/29, right. You being in Australia (i guess), me in Switzerland and the Slim guys in the US, "nightly" is a very relative term :-)