Red Hat Bugzilla – Full Text Bug Listing
|Summary:||mixer_applet2 tooltip doesn't show the right current volume level|
|Product:||[Fedora] Fedora||Reporter:||Ugo Viti <ugo.viti>|
|Component:||gnome-applets||Assignee:||Ray Strode [halfline] <rstrode>|
|Status:||CLOSED NOTABUG||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||bnocera, sangu.fedora, tjb|
|Fixed In Version:||1:2.20.0-2||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-10-18 10:57:26 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Ugo Viti 2007-09-18 14:53:05 EDT
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): gnome-applets-2.20.0-1.fc8 How reproducible: click in the volume mixer applet and change the volume Steps to Reproduce: 1. 2. 3. Actual results: the tooltips remain stucked to login volume Expected results: change the volume tooltip content in realtime as volume change from the mixer Additional info:
Comment 1 Matthias Clasen 2007-09-19 02:02:58 EDT
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.
Comment 2 Ugo Viti 2007-09-19 03:52:15 EDT
Yes i agree, i verified other apps and the tooltips visualization is working fine. Best Regards
Comment 3 Bastien Nocera 2007-09-19 20:19:13 EDT
(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: http://koji.fedoraproject.org/koji/taskinfo?taskID=166805
Comment 4 Ugo Viti 2007-09-19 21:13:44 EDT
Hi Bastien, 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. Best Regards
Comment 5 Bastien Nocera 2007-09-20 06:15:35 EDT
Excellent, thanks for testing Ugo.
Comment 6 Bastien Nocera 2007-09-24 16:55:35 EDT
*** Bug 251433 has been marked as a duplicate of this bug. ***
Comment 7 Thomas J. Baker 2007-09-24 19:48:32 EDT
Is this patch supposed to be in rawhide yet? The referenced packages are older than what's currently there.
Comment 8 Bastien Nocera 2007-09-25 07:50:51 EDT
(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.
Comment 9 Thomas J. Baker 2007-10-05 15:34:45 EDT
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.
Comment 10 Matthias Clasen 2007-10-09 13:20:35 EDT
What is "this problem", exactly ? The updating of the tooltip works correctly now for me.
Comment 11 Thomas J. Baker 2007-10-09 13:43:13 EDT
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.
Comment 12 Matthias Clasen 2007-10-11 09:12:00 EDT
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 ?
Comment 13 Thomas J. Baker 2007-10-11 09:21:57 EDT
raptor> rpm -q gnome-media gnome-media-2.20.0-2.fc8.x86_64 gnome-media-2.20.0-2.fc8.i386 raptor> Rawhide of today should have this update. I'll retest later this morning.
Comment 14 Thomas J. Baker 2007-10-11 10:10:32 EDT
raptor> rpm -q gnome-media gnome-media-2.20.1-2.fc8.x86_64 gnome-media-2.20.1-2.fc8.i386 raptor> 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.
Comment 15 Thomas J. Baker 2007-10-18 09:45:14 EDT
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.
Comment 16 Bastien Nocera 2007-10-18 10:57:26 EDT
I guess this is "fixed" then. I have no idea why it wouldn't have worked before...