Bug 295311 - mixer_applet2 tooltip doesn't show the right current volume level
mixer_applet2 tooltip doesn't show the right current volume level
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: gnome-applets (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
: Reopened
: 251433 (view as bug list)
Depends On:
Blocks: F8Target
  Show dependency treegraph
 
Reported: 2007-09-18 14:53 EDT by Ugo Viti
Modified: 2007-11-30 17:12 EST (History)
3 users (show)

See Also:
Fixed In Version: 1:2.20.0-2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-18 10:57:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
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...

Note You need to log in before you can comment on or make changes to this bug.