Bugzilla – Bug 1249
Pause changes volume level
Last modified: 2008-08-18 10:53:41 UTC
I paused the currently playing track (mp3) through my SqueezeBox G remote. After refreshing the Windows GUI (Fishbone Skin) I noticed that the voume went down to almost 0 (1 bar, I think). I tried pressing pause again via the Fishbone Skin, and it went up to about 75%. Subsequent presses toggles the volume between the two settings.
have you tried other skins?
ah... pause is fading the volume down to zero then back up. The HTML is being rendered before the fade is completed. pausing and unpausing should be toggling between zero volume and your chosen volume setting. That is what I hear when I test. htlm probably needs to test against the targets instead of the instantaneous volume.
Created attachment 386 [details] use pref instead of actual volume $client->volume NOW always returns the current volume, even mid-fade. Because of this, the skins will render using a volume level that might be mid-fade. Instead, use the preference. This now has the effect of showing the volume SETTING instead of the actual volume. of course, this still leaves the mute button broken, but I think I'll just remove that.
Further info: If I pause the music via the remote control on the SBG and then unpause without doing anything else, the music resumes at the correct volume level. If I press pause and then press volume up/down on the SBG remote, it can be seen that the volume had been set to 0. This can also be seen in the Windows GUI (1 bar in the volume ramp in Fishbone skin). Having changed the volume when paused, the volume doesn't get restored back to its initial value when unpausing. Doesn't appear to be due to the fishbone skin, as I haven't actually interracted with the GUI, other than refreshing the display. Just confirmed: the same effect can be seen when using ExBrowse2 skin. Note also that when changing volume from 40 to 39 or vice-versa, there is a click in the sound. I also hear this click when pausing/unpausing, presumably as the volume level is being changed. Should this bug be moved to a different component?
I had two "mid-air collisions" whilst trying to submit that comment - not sure if its appropriate any more!
the click from 39 to 40 is already reported as bug488
KDF is this patch applied?
nto yet. I've been too busy to be sure I'd be around (gf in town for two weeks only), so I've been dumping patches to the bug reports for safe keeping. If the patch looks ok for review, I'll commit it sometime tonight to 6.1/6.01 or both in time for the build.
I've commited this as subversion change 2872.