No notification on audio changes (Play, Pause, Next, Previous)

Thank you for reporting this problem and giving us a chance to make Ubuntu work better. Maybe I'm missing something. What application are you playing music with?

I did find this problem using Totem, Rhythmbox and Banshee. The multimedia keys work with all of them, but the notification does not appear at all. I also tried returning to default human theme, but the result is the same, no notification with audio track changes.

Ok, thank you for clarifying that. Let's see what we can get done.

Damiano Dallatana wrote:
> I did find this problem using Totem, Rhythmbox and Banshee. The
> multimedia keys work with all of them, but the notification does not
> appear at all. I also tried returning to default human theme, but the
> result is the same, no notification with audio track changes.
>
>

Reporting this bug against notify-osd is invalid. It needs to be filed against the applications in question to properly use the new notification-spec to feed notify-osd with the correct data, thus it can display notification-bubbles upon mm-keys being triggered.

Reported against rhythmbox, banshee and totem Ubuntu packages.

what notifications is totem using?

the desktop team doesn't work on banshee

is the rhythmbox window focused? it works fine here if the window is not focused. And there's no notifications on totem, so that bug could be probably closed as invalid.

Well, I thinks there is some misunderstanding. There should be two notifications on audio track changes with notify-osd:
1. the "old" notification with the title of the playing track
2. the "new" notification on multimedia keys actions, as explained on https://wiki.ubuntu.com/NotifyOSD#Play,%20Pause,%20Stop,%20Previous,%20and%20Next

While the first one has no problem on rhythmbox and banshee, and totem has not had any notification before (and I do not expect it to notify the new playing track), the second one does not appear.

Use cases:
1. I press "play" button on keyboard - I expect a confirmation bubble to be displayed with "play" icon, eventually (for enabled media players) with a consequent non-critical notification bubble with the title, author and cover of the playing track
2. I press "next" or "previous" - I expect a confirmation bubble with "play next" or "play previous" icon, with the eventual playing track non-critical notification bubble
3. I press "pause" or "stop" - as said on the Notify OSD specification previously linked, I should expect a confirmation bubble (the icons are not present on the icons table)

So, I do not see it as a "player problem" but more as a notify-osd bug (I can surely be wrong). notify-osd should intercept the use of an hotkey, and, if correctly handled by a multimedia application, show the right confirmation bubble. It's not a "fundamental functionality", but as it is in the notify-osd specs, I did think it is a broken or missing functionality.

The next and previous notifications are shown even if the media player is not started, so it's not their fault. someone suggested gnome-settings-daemon

On Thu, Mar 19, 2009 at 12:33, Nicolò Chieffo <email address hidden>wrote:

> The next and previous notifications are shown even if the media player
> is not started, so it's not their fault. someone suggested gnome-
> settings-daemon
>

You'll see in the master bug that notify-osd was already marked Invalid. You
should discuss there the possibility of adding a gnome-settings-daemon; I
can't speak to that.

I didn't touch notify-osd. I just marked as invalid the bugs reguarding the media players, because it's clearly not their fault.
I'm having a look at the gnome-settings-daemon code to see if the problem is there.
If not I will mark it as invalid too, and we must figure out who is the daemon that sends keys notifications

On Thu, 2009-03-19 at 17:07 +0000, Nicolò Chieffo wrote:
> I didn't touch notify-osd. I just marked as invalid the bugs reguarding the media players, because it's clearly not their fault.
> I'm having a look at the gnome-settings-daemon code to see if the problem is there.
> If not I will mark it as invalid too, and we must figure out who is the daemon that sends keys notifications
It definitely is. I've patched gsd code before to fix the media keys
priority part.
--
Chow Loong Jin

I am experiencing this bug too. The media keypress event is correctly being sent on the session bus, as this snipped from dbus-monitor --session shows:

  signal sender=:1.11 -> dest=(null destination) serial=90 path=/org/gnome/SettingsDaemon/MediaKeys; interface=org.gnome.SettingsDaemon.MediaKeys; member=MediaPlayerKeyPressed
   string "banshee-1"
   string "Next"

So the event is correctly being sent. The bug is with whatever is supposed to pick this event up and cause the notification to be displayed.

popey suggested that it might be a problem with my icon set (I'm using Tango and not Human), but changing makes no difference.

With latest updates (a lot of, I cannot tell where in particular) I see part of the bug is solved.
In particular, it solved the second use case I listed above (going to put them in the bug's description):
2. I press "next" or "previous" - I expect a confirmation bubble with "play next" or "play previous" icon, with the eventual playing track non-critical notification bubble

Still no confirmation bubble on play, pause and stop events.

We discussed this a bit on #ubuntu-desktop last night. The problem is with gnome-settings-daemon, and was resolved yesterday. Seb also made an additional upload to enable the eject icon. Play/pause cannot be enabled just yet as there is not a suitable icon available. I guess someone is working on this.

On Fri, 2009-03-20 at 11:02 +0000, Iain Lane wrote:
> We discussed this a bit on #ubuntu-desktop last night. The problem is
> with gnome-settings-daemon, and was resolved yesterday. Seb also made an
> additional upload to enable the eject icon. Play/pause cannot be enabled
> just yet as there is not a suitable icon available. I guess someone is
> working on this.
>
It would be important to note that in the case of gsd, the PLAY_KEY is
actually triggered for Play/Pause key events. Confirming gsd bug

  affects ubuntu/gnome-settings-daemon
  status confirmed

Reopening the notify-osd bug, since notify-osd is yet to ship the
play/pause as well as pause icons. Only when notify-osd ships the said
icons, can the gsd bug be fixed.

  affects notify-osd
  status confirmed
  affects ubuntu/notify-osd
  status confirmed
--
Chow Loong Jin

There is also no notification for "stop".

On Fri, 2009-03-20 at 22:14 +0000, Siegfried Gevatter (RainCT) wrote:
> There is also no notification for "stop".
>
Nor is there an icon for it.
--
Chow Loong Jin

I think that the bug description must be modified accordingly to what
is missing now.

Well, solving bug #345363 and bug #351986 did remove completely the notification for audio change notification in g-s-d 2.26.0-0ubuntu3.
In the notify-OSD specs ([1]) there is still the description of the hotkey notification system, but now it is in fact not working at all by default.
I did think the desired behaviour for notify-osd was to follow the written specs...

[1] https://wiki.ubuntu.com/NotifyOSD

See also https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/345363/comments/4

> did remove completely the notification for audio change notification in g-s-d 2.26.0-0ubuntu3.

no it didn't, you still get the track changes buble from rhythmbox

Uh, yes, sorry for the misunderstanding, I was thinking of the confirmation bubbles - the hotkey action notifications.

So wontfix, for 9.04 at least. See https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/345363/comments/4

Re-qualified as "whishlist" for 9.10

I also get no notification at all. I'm also on Jaunty 64. I used to see libnotify notifications on older versions.

Damiano, thanks for the suggestion. However, the result would be for a keypress to produce a notification bubble in cases where the key does nothing, and two notification bubbles when it actually does something. Neither of those seem like a good idea. We do have a few other cases where a notification bubble appears after nothing happens, but those are mainly to reassure you that you've gone as far as you can go, e.g. that you're already at maximum brightness.