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

Bug #343261 reported by Damiano Dallatana on 2009-03-15
42
This bug affects 4 people
Affects Status Importance Assigned to Milestone
banshee (Ubuntu)
Undecided
Unassigned
gnome-settings-daemon (Ubuntu)
Wishlist
Matthew Paul Thomas
notify-osd (Ubuntu)
Low
David Barth
rhythmbox (Ubuntu)
Low
Ubuntu Desktop Bugs
totem (Ubuntu)
Low
Ubuntu Desktop Bugs

Bug Description

Binary package hint: notify-osd

I am using notify-osd 0.9.3-0ubuntu1 (with /usr/share/notify_osd folder renamed to notify-osd) on Ubuntu Jaunty x64.
Whenever I use the (correctly working) multimedia keys on my keyboard, a Microsoft Wireless Multimedia Keyboard 1.1, I do not get any notification at all.
Play, Pause, Next, and Previous are all affected.
Notifications are working correctly for everything else.

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)

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?

Damiano Dallatana (damidalla) 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.

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.
>
>

Changed in notify-osd:
status: New → Confirmed
Changed in notify-osd:
status: New → Confirmed
David Barth (dbarth) on 2009-03-17
Changed in notify-osd:
assignee: nobody → dbarth
importance: Undecided → High
assignee: nobody → dbarth

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.

Changed in notify-osd:
status: Confirmed → Invalid
Changed in notify-osd (Ubuntu):
status: Confirmed → Invalid
Damiano Dallatana (damidalla) wrote :

Reported against rhythmbox, banshee and totem Ubuntu packages.

Sebastien Bacher (seb128) wrote :

what notifications is totem using?

Changed in totem (Ubuntu):
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Incomplete
Changed in rhythmbox:
assignee: nobody → desktop-bugs
Changed in banshee:
assignee: nobody → desktop-bugs
Sebastien Bacher (seb128) wrote :

the desktop team doesn't work on banshee

Changed in banshee (Ubuntu):
assignee: desktop-bugs → nobody
Changed in rhythmbox (Ubuntu):
importance: Undecided → Low
Pedro Villavicencio (pedro) wrote :

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.

Changed in rhythmbox:
status: New → Incomplete
Damiano Dallatana (damidalla) wrote :

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.

Changed in banshee:
status: New → Confirmed
description: updated
Nicolò Chieffo (yelo3) 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

Nicolò Chieffo (yelo3) on 2009-03-19
Changed in banshee:
status: Confirmed → Invalid
Changed in rhythmbox:
status: Incomplete → Invalid
Changed in totem:
status: Incomplete → Invalid

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.

Nicolò Chieffo (yelo3) 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

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

Iain Lane (laney) wrote :

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.

Damiano Dallatana (damidalla) wrote :

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.

description: updated
Iain Lane (laney) 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.

Chow Loong Jin (hyperair) wrote :

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

Changed in gnome-settings-daemon:
status: New → Confirmed
Changed in notify-osd:
status: Invalid → Confirmed
status: Invalid → Confirmed
Siegfried Gevatter (rainct) wrote :

There is also no notification for "stop".

Chow Loong Jin (hyperair) wrote :

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

Changed in notify-osd (Ubuntu):
importance: Undecided → Low
Changed in gnome-settings-daemon (Ubuntu):
importance: Undecided → Low

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

Damiano Dallatana (damidalla) wrote :

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

Sebastien Bacher (seb128) wrote :

> 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

Damiano Dallatana (damidalla) wrote :

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

David Barth (dbarth) wrote :
Changed in notify-osd:
status: Confirmed → Won't Fix
Changed in notify-osd (Ubuntu):
status: Confirmed → Won't Fix
Changed in notify-osd:
status: Won't Fix → Invalid
Changed in notify-osd (Ubuntu):
status: Won't Fix → Invalid
David Barth (dbarth) wrote :

Re-qualified as "whishlist" for 9.10

Changed in gnome-settings-daemon (Ubuntu):
importance: Low → Wishlist
assignee: nobody → dbarth
Changed in gnome-settings-daemon (Ubuntu):
assignee: dbarth → mpt
Allan Caeg (allancaeg) wrote :

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

Matthew Paul Thomas (mpt) wrote :

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.

Changed in gnome-settings-daemon (Ubuntu):
status: Confirmed → Invalid
no longer affects: notify-osd
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers