GNOME Bugzilla – Bug 576022
gst-mixer shows disabled mixer tracks
Last modified: 2009-05-04 19:13:52 UTC
Please describe the problem: This was reported at https://bugs.edge.launchpad.net/ubuntu/+source/gnome-media/+bug/345645. When launching gnome-volume-control (gst-mixer), the Playback tab opens for my default mixer with the Master, PCM, Line-in, CD, Microphone and PC Speaker tracks displayed. However, if I click on the Preferences button only the Master track is checked. If I use the combo box at the top of gst-mixer to select a new mixer, then switch back to my default mixer, only the Master track is displayed now (correctly) without me changing any preferences. Steps to reproduce: 1. Launch gnome-volume-control (for me, it opens on Alsa mixer) 2. Note that there are extra tracks displayed in addition to what there should be. 3. Open Preferences and note that only the Master track is checked. 4. Switch to a different mixer, then switch back to the default one again. 5. Note that the correct tracks are now displayed. Actual results: When I first open gnome-volume-control, extra tracks are displayed in addition to those enabled in the preferences. Expected results: Only those tracks enabled in the preferences should be displayed. Does this happen every time? Yes Other information:
Created attachment 131435 [details] [review] Fixes whitelist behaviour Reverts the whitelist behaviour back to that in 2.24 by clearing the whitelist before checking against it. The fix is a bit hacky as I don't exactly understand the whitelist behaviour.
Ccing Brian who did the svn changes
Created attachment 131459 [details] [review] updated patch Thanks for catching this. I am now providing a patch is a little cleaner. I think it's better to just init the array in the two calling functions rather than calling the function with a special NULL argument. Could you test? If this works, I'll commit this fix upstream.
Thinking about this a bit more, I think the original patch proposed by Robert in comment #1 is the best way to fix this. I committed this upstream. However, this does seem a little odd. Note that the code seems to properly initialize the 2nd element of each array element to "FALSE" already in the gnome_volume_control_element_whitelist function in element.c: static struct { gchar *label; gboolean done; } list[] = { { "cd", FALSE }, { "line", FALSE }, [...] }; So, I'd think that the "done" values should all be FALSE without needing to set them with initial values. However, it doesn't hurt to initialize the structure again if this makes it work better on some platforms. Might be worth finding out why the structure definition isn't working, though. Would be better to fix this to avoid the extra initialization if possible.
The issue is the structure is static - so each time the elements are iterated over the whitelist needs to be reset.
(afaik a static structure will only be initialised once - does this behaviour vary between platforms?)
Oh yes, you are right. I understand the need for this patch more now. The problem happens when you switch to a different device in gnome-sound-mixer, so it is necessary to re-initialize the structure when this happens. The fact that the structure is initialized on program startup, doesn't ensure that it gets reset when you change devices. Thanks for explaining. I believe the patch in comment #1 is reasonable, and is already in SVN head. So this issue should now be fixed. I improved the comment in the code slightly so I think this is more clear.
works for me. This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.