Hide Forgot
Description of problem: When playing audiofiles via audacious a notification that the volume has changed pops even on every title change. This is totaly anoying Version-Release number of selected component (if applicable): xfce4-mixer-4.8.0-1.fc15.i686 How reproducible: allways Steps to Reproduce: 1. start audacious 2. activate the libnotify-aosd plugin 3. play some audio files Actual results: on every track change a volume-notification pops up Expected results: volume-notifications should only pop up on manual volume modifications Additional info:
Odd. xfce4-mixer has no notification ability. Are you sure this is coming from xfce4-mixer? Perhaps it's gnome-volume-control or whatever?
I try to verfiy this behaviour with parole and no volume-notifications pop up. So it could also be that audacious is causing these pop ups.
gnome-volume-control isn't installed on my system but xfce4-volumed-0.1.12-1.fc15.i686
Moving over to xfce4-volumed for comment.
There is not much we can do here. It's a combination of audacious, puseaudio and xfce4-volumed and of them behave correct - at least from there point of view. If you look at pavucontrol you will see that audacious has no continuous stream but disappears when the track changes. Thus it is a new channel for pulseaudio and a new channel is like raising the volume form 0-x for xfce4-volumed. So if one application is to blame it is audacious - but I am not sure if it's developers will agree, so I am not sure how to move on.
Let's try and see what's their point of view :-)
I guess they'll blame PulseAudio... are you taking care of this? Please file a bug against audacious upstream or reassign this one to the audacious component in Fedora. To get rid of the notifications, I suggest to uninstall xfce4-volumed. Volume keys will continue to work through amixer directly.
> 2. activate the libnotify-aosd plugin Completely unrelated. Else, expand on how this would be relevant. > 3. play some audio files Missing some steps here. At least with F-15, one must first install xfce4-notifyd and xfce4-volumed, then relogin to have them both autostarted. Without xfce4-notifyd there would not be any notifications from Audacious' libnotify plugin either. > on every track change a volume-notification pops up Cannot reproduce. This is with Pulse Audio and XFCE Mixer Plugin reconfigured to control "Playback: Internal Audio Analog Stereo (PulseAudio Mixer)" as the default controlled something that didn't affect the master volume. If I change the current volume level with either Audacious or XFCE panel mixer, I do get the volume level displayed by volumed, and it vanishes automatically after several seconds. While typing this comment, XFCE mixer stopped working. Using the mouse-wheel on it displays the right animation of the mixer icon, but without an audible effect. Trying to make it work again, audio suddently turnt silent. Audacious continues to play, but changing the volume level is not possible. 100% completely silent. I may have to log out and in again, and would still need a test-case. > Please file a bug against audacious upstream Appreciated, because I couldn't answer any questions they might have. It's likely they will ask whether it's reproducible with 3.0.2 (F-16) or latest git. I couldn't even answer that without a clear test-case. Does it need to be a specific volume level in Audacious? Perhaps a rounding error that triggers the notification?
You need to active the libnotify-aosd plugin otherwise you truely can't reproduce this behaviour. But at the moment I can't reproduce this problem myself. strange.
The libnotify-aosd plugin cannot trigger any xfce4-volumed notification. It is just the "Audacious OSD" plugin modified to use libnotify instead of on-screen-display. A direct library call with some message text and no information about the volume level. libnotify itself would not "magically" decide to show an unrelated second notification based on a data poiner from a separate process (xfce4-volumed) … just in case you start thinking it could be in a bug in libnotify. ;) It isn't. [...] So, since it is xfce4-volumed that notifies about volume changes, when exactly does it do that? Speaking in terms of its implementation. How does it get notified about volume changes? Does it poll a service? And how/where does it read out the current volume level it displays?
Hi Michael, I think I already answered some of your questions in my previous comment, but maybe my comments were not clear enough.(In reply to comment #10) (In reply to comment #10) > So, since it is xfce4-volumed that notifies about volume changes, when exactly > does it do that? Whenever a new track starts. The problem with audacious is that it doesn't really do continuous playback from PulseAudio's POV. Whenever the title changes, the volume of the playback stream goes to zero and then back to the original value. This change is then seen and reported by xfce4-volumed. > Speaking in terms of its implementation. How does it get > notified about volume changes? Does it poll a service? And how/where does it > read out the current volume level it displays? It uses gstreamer. It creates a GstBus and then used gst_bus_add_signal_watch. I'm pretty sure that if one wrote a test program we'd see this moment of silence in GStreamer.
I'd like to add that it's not just Audacious but other programs, too. Some players are fine, others not. So who is to blame? GStreamer? PulseAudio?
Audacious does not use GStreamer, however, so that comment only confuses the matter. Audacious' PulseAudio plugin connects to Pulse Audio with default stream volume, at least since I fixed it to do that in 2009, and it has seen upstream maintenance since then again, too. It used to connect with a custom start volume level years ago (the original code is from the Pulse Audio author even, albeit for XMMS). In comment 8 I wrote I cannot reproduce the problem. Latest Audacious (3.2-beta1) is in Rawhide, so if it's still reproducible for you, that would be the latest code of interest. [...] I don't know what to report upstream. I don't want to waste any resources there with a mysterious issue that is not specific to Audacious. I also cannot support Pulse Audio, since I'm one of the users who need to run it with "flat-volumes = no" in /etc/pulse/daemon.conf. Activity related to that can be found in audacious-plugins %changelog before 2.4.0, and the cause is something that's known by Pulse Audio upstream. It is not specific to Audacious either.
Perhaps you also need to disable flat-volumes. Here are some of the links to the pulseaudio.org bug tracker tickets: http://pkgs.fedoraproject.org/gitweb/?p=audacious-plugins.git;a=blob_plain;f=README
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I can reproduce the doubled notification in two popups. 1) new mail message from claws-mail 2) volume level for sound Request to reopen this bug!
(In reply to comment #16) > I can reproduce the doubled notification in two popups. > 1) new mail message from claws-mail > 2) volume level for sound > > Request to reopen this bug! xfce4-notifyd-0.2.2-6.fc18.x86_64
(In reply to comment #16) > Request to reopen this bug! Then please DO NOT file a duplicate.
*** Bug 960584 has been marked as a duplicate of this bug. ***
(In reply to comment #18) > Then please DO NOT file a duplicate. It's not allowed to me to open foreign bug reports.
As stated in bug #731430 ... # rpm -q xfce4-notifyd xfce4-volumed claws-mail xfce4-notifyd-0.2.2-6.fc18.x86_64 xfce4-volumed-0.1.13-4.fc18.x86_64 claws-mail-3.9.0-1.fc18.x86_64 Upstream seems to be aware of the spam problem
See Also: https://bugzilla.xfce.org/show_bug.cgi?id=7437 https://bugzilla.xfce.org/show_bug.cgi?id=8069 https://bugzilla.xfce.org/show_bug.cgi?id=10003 A short discussion in IRC #xfce-dev showed that it should be to blame claws-mail to generate the sound (a short "plop") with the popup notification, I use the claws' systray icon / notification plugin.
Well, I could solve the issue. Disable the checkbox in claws-mail settings: Plugins > Notification > Use sound theme Works for me.
(In reply to comment #23) > Well, I could solve the issue. Disable the checkbox in claws-mail settings: > Plugins > Notification > Use sound theme > > Works for me. Unfortunately, it does not work properly. Claws-Mail seems to prevent the deactivation of the check box "Use sound theme" (see comment #23) to stay persistently over a restart / reboot process. I get the nasty popup with the volume again.
> Claws-Mail seems to prevent the deactivation of the > check box "Use sound theme" (see comment #23) to stay > persistently over a restart / reboot process. Ambiguous. Do you mean the checkbox is reset to "ON" after a restart of Claws Mail? (can't reproduce) Or do you hear sound even if the checkbox is off? (haven't tried) $ grep -i sound ~/.claws-mail/clawsrc canberra_play_sounds=0 Problems with the checkbox being reset or being ignored would be a bug in Claws Mail (claws-mail-plugins-notification).
(In reply to comment #25) > Do you mean the checkbox is reset to "ON" after a restart of > Claws Mail? (can't reproduce) Or do you hear sound even if the checkbox is > off? (haven't tried) > > $ grep -i sound ~/.claws-mail/clawsrc > canberra_play_sounds=0 > $ grep -i sound ~/.claws-mail/clawsrc canberra_play_sounds=1 > Problems with the checkbox being reset or being ignored would be a bug in > Claws Mail (claws-mail-plugins-notification). Okay, this bug may be closed as "works for me". Should I report the issue to upstream (claws-mail devs)? How is the change event of the check box handled in claws-mail? When I click on "Apply" or "OK", the change gets *not* into the rc file marked with rw access rights. $ ls -l ~/.claws-mail/clawsrc -rw-------. 1 raphael raphael 11409 6. Mai 19:43 /home/raphael/.claws-mail/clawsrc
You need to exit Claws Mail for the config settings to be saved.
(In reply to comment #27) > You need to exit Claws Mail for the config settings to be saved. No helpful solution for me. I mostly suspend my laptop to hdd while claws-mail keeps running. Sometimes, kernel decides to reboot for an unknown reason and boots up freshly and claws-mail thinks to have to play sound again... Better would be to have it as a separate feature request to upstream, maybe to touch it down into the rc file when user clicks on "apply". What do you think?
??? Do you toggle the setting often? Or why can't you unmark the checkbox, exit Claws Mail to save the config, then never touch the checkbox again? > and claws-mail thinks to have to play sound again... Well, I've asked you before whether you experience a situation when the config value is reset from OFF to ON without you doing that? That would be something to report upstream.
(In reply to comment #29) ... > Well, I've asked you before whether you experience a situation when the > config value is reset from OFF to ON without you doing that? That would be > something to report upstream. As said already, if claws-mail has crashed after the check box was unchecked, it's checked again cause of the restart without proper shutdown (of claws-mail). With having the "apply"-button store all values into the rc file, this would be a good work-around. Relevant for Upstream or not at all? Because the crash does not happen with claws-mail itself, but with the machine (for instance by a broken suspend image on hdd). I hope this use case is clearly understandable now. Eitherwise, I would suggest to just set the issue to "works for me".
That sounds strange. What exactly happens with your clawsrc file during a spontaneous reboot of your machine? Is the file lost (deleted)? Is it corrupted? If not, who resets the key=value setting in the config file? And why? That is still not clear. The config is not kept open while Claws is running, so why would it change? Do you face file system corruption, or do you only lose data that has not been stored on the physical media prior to the crash? > With having the "apply"-button store all values into the rc file, > this would be a good work-around. Relevant for Upstream or not at all? Asking wouldn't hurt, ;-) but from the perspective of a configuration database, often those implement an internal cache (because, for example, one doesn't want configdb I/O be mapped directly to storage I/O when there are many key/value lookups in the database). Saving to disk likely would need to be requested explicitly (think "sync" or "flush") by any component that accesses the configdb. It could be that current behaviour is by design and works, too. Spontaneous system crashes are not good reason to change Claws Mail, IMO.
*headache* kopf-tisch.de
Resetting the NEEDINFO flag as it is unclear to me what info was requested. If you set it again, please come up with a proper question.
Never had crashes any more, so I guess this issue is fixed with newer versions of claws-mail / Fedora releases (reported against F15, as long EOL).
This bug is currently assigned to an unsupported release. If you think this bug is still valid and should remain open, please re-assign it to a supported release (F22, F23) or to rawhide. Bugs which will be assigned to an unsupported release are going to be closed as EOL (End Of Life) on January 26th, 2016.