Red Hat Bugzilla – Bug 295311
mixer_applet2 tooltip doesn't show the right current volume level
Last modified: 2007-11-30 17:12:16 EST
Description of problem:
just updated my devel system to today rawhide release, and
gnome-applets-2.20.0-1.fc8 was updated, now when i change the volume level via
mixer applet, the tooltip doesn't update the current volume any more... always
show the old one (the volume level at user logon)
i think this could be a symptom of a wider problem caused by the latest gtk2
tooltip's framework rewrite... i also noted a increase of delay when showing
tooltips and updating his contents in realtime (in Fedora7 it's almost immediate)
Version-Release number of selected component (if applicable):
click in the volume mixer applet and change the volume
Steps to Reproduce:
the tooltips remain stucked to login volume
change the volume tooltip content in realtime as volume change from the mixer
I don't think that GTK is to blame for this; there is other brokenness in the
mixer applet right now, e.g. the values dont' always go from 0 to 100, and
the muting/unmuting happens semi-randomly when changing the level. This may
be fallout from the switch from polling to notification.
Yes i agree, i verified other apps and the tooltips visualization is working fine.
(In reply to comment #1)
> I don't think that GTK is to blame for this; there is other brokenness in the
> mixer applet right now, e.g. the values dont' always go from 0 to 100, and
> the muting/unmuting happens semi-randomly when changing the level. This may
> be fallout from the switch from polling to notification.
I've fixed those bits, should be in 1:2.20.0-2. The problem also exists upstream
(without the notification patch) when changing the volume fast, some calls to
alsa-lib fail, but we don't know that. So we ignore the failed gets/sets and
just use the value that's in the UI.
The obvious problem is that the hardware and the UI might get out of sync, but
that's better than the UI going bananas and the mute state switching all over
the place. I filed http://bugzilla.gnome.org/show_bug.cgi?id=478498 against
GStreamer, and http://bugzilla.gnome.org/show_bug.cgi?id=478485 against the applet.
Let me know how the new build works for you. Should be at:
just tried your patch and now the mixer applet is working good!
i also noted the out of sync mixer bug, but it happened only on fast volume
change... however the mixer applet is now fully usable...
many thanks for your light fast patch, very very good job Bastien.
Excellent, thanks for testing Ugo.
*** Bug 251433 has been marked as a duplicate of this bug. ***
Is this patch supposed to be in rawhide yet? The referenced packages are older
than what's currently there.
(In reply to comment #7)
> Is this patch supposed to be in rawhide yet? The referenced packages are older
> than what's currently there.
It might have been stuck in the rawhide queue. I've made another update to it to
fix the crasher in bug 302881.
I'm still having this problem. As far as I can tell, the fix has never been
pushed into rawhide, or if it did, it doesn't work. I can't reopen this bug as I
am not the owner.
What is "this problem", exactly ?
The updating of the tooltip works correctly now for me.
See the original bug I hopped on: #251433 from comment #6. Sound volume is
changed in random ways when using the scroll button on the mixer applet or using
volume control keys.
This was broken for me too; it works fine now with gnome-media-2.20.1-2.fc8
What version of gnome-media do you have ?
raptor> rpm -q gnome-media
Rawhide of today should have this update. I'll retest later this morning.
raptor> rpm -q gnome-media
Not fixed for me. Scrolling the mouse wheel over the mixer applet changes the
sound in non-linear ways. Using the volume knob on my Dell USB keyboard has the
same problem. Clicking on the mixer applet so the slider pops up and then
dragging volume works but you can hear the random changes along the way.
This is now better for me. The strange thing is that the version of gnome-media
hasn't changed since the 11th. I wonder if it was related to pulseaudio? Things
are not perfect (seems graphic representation of level and actual level are not
always in sync) but at least the actual sound levels change linearly without the
random muting, channels becoming unlocked, etc.
I guess this is "fixed" then. I have no idea why it wouldn't have worked before...