design problem? infinite wait for long queue

Bug #334809 reported by Nicolò Chieffo
128
This bug affects 20 people
Affects Status Importance Assigned to Milestone
Banshee
Fix Released
Medium
Mail Notification
New
Undecided
Unassigned
Rhythmbox
New
Undecided
Unassigned
XChat-GNOME
Fix Released
Medium
banshee (Ubuntu)
Fix Released
Undecided
Unassigned
mail-notification (Ubuntu)
Confirmed
Undecided
Unassigned
netbook-launcher (Ubuntu)
Won't Fix
Wishlist
Unassigned
notify-osd (Ubuntu)
Confirmed
Wishlist
Unassigned
rhythmbox (Ubuntu)
Fix Released
Undecided
Unassigned
xchat-gnome (Ubuntu)
Fix Released
Wishlist
Unassigned

Bug Description

Binary package hint: notify-osd

I'm using pidgin-libnotify and I discovered a problem in notify-osd (maybe a design problem, not sure).
When a buddy writes me a lot of lines (say 25) all messages are queued and showed in the bubbles. Every bubble stays there for 7 seconds. 7*25=almost 3 minutes.

What happens is that if any other contact writes to me, the bubbles are scheduled too! And also the notifies sent through "notify-send" are.

(Instead volume notifies are displayed below.)

This is a problem, because it seems that an application can bring the monopoly of the notification bubbles.

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
Package: notify-osd 0.8-0ubuntu4
ProcEnviron:
 PATH=(custom, user)
 LANG=it_IT.UTF-8
 SHELL=/bin/bash
SourcePackage: notify-osd
Uname: Linux 2.6.28-8-generic i686

Revision history for this message
Nicolò Chieffo (yelo3) wrote :
Revision history for this message
Mat Tomaszewski (mat.t.) wrote :

Thanks for reporting that.
Messages from the same person arriving in sequence should appear in one appending bubble. Max. time for the bubble to stay on the screen is 15 seconds. Once you switch to your IM client *all* bubbles generated by this app should be deleted from the queue.

Revision history for this message
Nicolò Chieffo (yelo3) wrote : Re: [Bug 334809] Re: design problem? infinite wait for long queue

You are right, *but* if some other app sends a notification (for
instance notify-send) it should not be queued. It should be displayed
under.
So there should be one notification per-app. with the possibility to
differentiate the notification bubbles in the same app (usefull for IM
applications, which might want to show one bubble per-user)

Revision history for this message
David Barth (dbarth) wrote :

We cannot currently remove messages from the queue. The suggestion is interesting, but the protocol does not currently supports it. We may add this option later though as part of other enhancements to notify-osd and the message indicator.

Changed in notify-osd:
importance: Undecided → Wishlist
status: New → Confirmed
status: New → Confirmed
Changed in notify-osd:
importance: Undecided → Wishlist
Revision history for this message
Nicolò Chieffo (yelo3) wrote :

Can you answer to this question: why isn't there one queue per
application? so that if an application has lots of notifications to
display, at least another app which wants to show something does not
have to wait for infinite time!

Revision history for this message
Mark Shuttleworth (sabdfl) wrote : Re: [Dx-team] [Bug 334809] Re: design problem? infinite wait for long queue

This is a real bug, the specification includes provisions to address
this very case.

First, repeated messages from a user in IM should be appended in the
notification, so you see one notification which grows and scrolls rather
than multiple notifications. Each append extends the life of the bubble
slightly.

Second, no bubble should live longer than a certain maximum time, so
that other app notifications can't be DOS'd.

We could probably improve things by saying that an app which has
dominated the presentation space for a period should be deprioritised to
give other apps a slice of the action.

MPT?

Mark

Revision history for this message
Matteo Collina (matteo-collina) wrote :

I think the main problem here isn't about other bubbles waiting time. It's all about user interaction. Everyone expects his computer to be smart, while it'll be stupid to show a notification after 5 minutes it was sent. A notification is something important now, not later.

Moreover if the top-right corner of the screen is blighting every 7 second for 3 minutes a user won't look there anymore until the congestion ends. So all notifications in that stream will be useless.
It's my opinion that a notification system should have some kind of Quality of Service guarantee from the user point of view.

It's possible to silently drop long waiting messages? In this way we can detect any abuse of the notification system and restore a normal situation.
Let's consider a timeout of 90 second, so it's possible to deliver almost 13 notification in that time. Even a more aggressive value can do the job.

Revision history for this message
Matteo Collina (matteo-collina) wrote :

Maybe the best solution is to use a "Leaky Bucket" model for the notifications. Each application has its own bucket which has a fixed capacity. Bubbles in the bucket are queued for displaying at a constant rate, equivalent to the size of the hole in the bucket. Obviously if the bucket is empty the bubble will pass through. If the bucket is full every message from that application will be discarded.

Revision history for this message
Mat Tomaszewski (mat.t.) wrote :

I agree that there should be a default timeout. 15 minute or even 3 minute old notification is pretty pointless. Also, all notifications from a given app should be deleted from the queue once the user switches focus to this app.

Revision history for this message
Matthew Paul Thomas (mpt) wrote :

I don't think it would make sense to delete all notifications for the focused application. For example, if I focus the window for one IM buddy, I don't want to see any more notifications of what that buddy said; but that has nothing to do with whether I want to see notifications for other buddies who are messaging me at the same time.

If a program is sending too many notifications, that's a bug in the program and should be reported against the program -- in this case, pidgin-libnotify. Reporting it against Notify OSD is like reporting a bug against Metacity complaining that an application opened 200 windows, or reporting a bug against GTK complaining that an application menu has too many items in it.

Revision history for this message
Mat Tomaszewski (mat.t.) wrote :

Right, yes, I agree that you may want to keep track of what's going on in other IM windows that may be hidden in the background. It is actually a very good point.

Revision history for this message
Matteo Collina (matteo-collina) wrote :

That's true that if a program is sending too many notifications, it's the program's fault. However it makes sense to prevent this kind of things to happen because the notifications are system wide and there are bugs.
I think that a notification system is quite different from a window manager. In fact your bug examples happen inside the bugged application while the notification are handled externally.
What do you do with an app that opens 200 windows? kill -9 ...
What do you do with an app that has sent 200 messages? Even if you kill it they'll be displayed, so the only solution is to kill Notify OSD.
That's the reason because there must be some kind of control about how apps use Notify OSD.

Revision history for this message
Mark Shuttleworth (sabdfl) wrote : Re: [Dx-team] [Bug 334809] Re: design problem? infinite wait for long queue

I agree that an app should not be able to DOS the system. When an app
has many notifications in the queue (i.e. they aren't updates or
appends, they are distinct bubbles that are going to be displayed
sequentially) then we should allow the notifications of other apps to
jump ahead in the queue.

MPT, would you work with Mirco to specify an algorithm for that?
Something like "if there are more than 3 notifications in the queue for
an app, then they are downgraded one notch (i.e. critical to normal,
normal to low). If there are more than 5 notifications from a single app
in the queue, then they are downgraded two notches. And if there are
more than 10 in the queue then any other app notification will go ahead
of them.

Mark

Revision history for this message
Nicolò Chieffo (yelo3) wrote : Re: [Dx-team] [Bug 334809] Re: design problem? infinite wait for long queue

This algorithm sounds good!
But I also think that old notifications should be trashed.

And it could be really usefull to present a call to invalidate pending
notifications (usefull for pidgin as someone told before)

Revision history for this message
Michael Rooney (mrooney) wrote :

Is this the same bug that causes notifications to never disappear while others are changing? For example if you change the volume and then move the brightness up and down repeatedly, the volume notification will never go away until you stop changing the brightness.

I can imagine the potential reasoning for this was that if the volume disappeared, the brightness notification should move up, but that might be jarring/confusing to a user if it moves instantly to a new position. However if it smoothly slid up (and others below it) I think that would address this issue.

Revision history for this message
Matthew Paul Thomas (mpt) wrote :

Michael, no, volume and brightness notifications are not supposed to appear simultaneously (<https://wiki.ubuntu.com/NotifyOSD#Animations%20and%20durations>, "Replaces any earlier confirmation bubble immediately"). Please report that as a separate bug.

Revision history for this message
Michael Rooney (mrooney) wrote : Re: [Bug 334809] Re: design problem? infinite wait for long queue

Thanks mpt, I've reported it as bug 344664 which Ara mentioned is the
issue of them showing up at the same time. Thanks for the awesome work
so far everyone!

Revision history for this message
KillerKiwi (killerkiwi2005) wrote :

I get some thing similar when I get 2 many emails...

My thunderbird plugin sends a message for each email which is nice but I just received about 200 emails and the notify-osd just keeps displaying them one at a time...

My first thought was close thunderbird.. which of course dosnt help as the notification are queued

This is probably primarily a bug in the plugin but noify-osd should insure you never get into this position regardless how how badly apps may behave

Its VERY annoying, maybe there should be a anti spam type deal.. if more than N items are on queue from an application drop all but latest N

Even that might not be enough.. maybe block an app from notify-osd for 5 mins if it sends too many notification in a timespan as well

Revision history for this message
Mark Shuttleworth (sabdfl) wrote : Re: [Dx-team] [Bug 334809] Re: design problem? infinite wait for long queue

KillerKiwi wrote:
> This is probably primarily a bug in the plugin but noify-osd should
> insure you never get into this position regardless how how badly apps
> may behave
>
> Its VERY annoying, maybe there should be a anti spam type deal.. if more
> than N items are on queue from an application drop all but latest N
>
> Even that might not be enough.. maybe block an app from notify-osd for 5
> mins if it sends too many notification in a timespan as well
>
Yes, there should be a throttle which means that masses of notifications
are choked appropriately.

Mark

Revision history for this message
Jeremy Nickurak (nickurak) wrote :

I reported #357150, which seems to be a duplicate of this bug.

I'd just like to point out:

- Many applications already use the notification system for delivering messages to the user. This is a desired behavior, that many users depend on.
- There is no other standard mechanism defined by freedesktop.org that would allow these messages to be displayed in a consistent desktop-agnostic manner.

Additionally, (afaik):
- The indicator applet doesn't have a way to push text information to the user (Ie, message subjects).

Blocking messages as suggested here is not a great solution. I would very much like to be able to recieve 20 notifications about different things happening at once -- the key is to be able to handle them in a useful way. In this regard, notification-daemon is substantially better than notify-osd.

Given that there are a lot of applications that use notifications this way, and that legacy applications may never be corrected, to me this is a pretty significant regression in usability for Ubuntu, and I think it deserves a importance much higher than "wishlist"

Revision history for this message
Ara Pulido (ara) wrote :

There is already a confirmed upstream task

Changed in notify-osd (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
Mark Shuttleworth (sabdfl) wrote : Re: [Bug 357150] Re: Regression vs notification-daemon: Notify-osd doesn't deal with a large number of notifications well

Given that there is another dup of the "long queue" issue, I'm cc'ing
the Ayatana list.

Ayatana team, for reference:

   https://bugs.launchpad.net/bugs/357150
   https://bugs.launchpad.net/bugs/334809

MPT, can you point to a spec for the 9.10 queue throttling behaviour,
that captures the ideas around discarding notifications? Also, do we
have a list of applications which can generate 10's of notifications
(like a notification for every new message in the inbox when you start
up mail) that we can fix (to send a summary message in those cases)?

Mark

Revision history for this message
Dana Goyette (danagoyette) wrote :

One example I've run into most often: the music player QuodLibet (with notifications plugin enabled). Try playing an album, and then skipping forward or backward about 5 tracks.
What happens with notification-daemon: all the notifications pop up at roughly the same time, and then shortly disappear.
What happens with notify-osd: the bubbles tie up the desktop so long that you no longer have any idea which track you're on.
It's especially bad if you try to skip back when you're already at the first track -- it still shows a new notification for that.

Another app that may be taken as a torture-test: service-discovery-applet. Try adding one to the panel, enabling discovery for all services, and enabling notifications. On joining a busy network (such as one at a library), this can generate a ludicrous number of notifications all at once. With notification-daemon, it spams them all at once... but with notify-osd, it ties up the notifications for a very long time.

Revision history for this message
Dana Goyette (danagoyette) wrote :

Another comment: one possible solution could be a variation of the "leaky bucket" algorithm: instead of discarding new messages if a program queues too many in a short interval, you could have notify-osd shorten the time it displays the _older_ messages -- almost like a "pressurized" leaky bucket.

Revision history for this message
Jeremy Nickurak (nickurak) wrote :

I would have much less of a problem with most of these solutions (Dropping messages, summarizing as "5 notifications from application-X, or dramatically shortening the time messages are available) if there was a proper notification history ( http://bugs.launchpad.net/notify-osd/+bug/382094 ), where I could look back and see what I missed. (Provided of course there was some indication of me missing something...)

Revision history for this message
Mark Shuttleworth (sabdfl) wrote : Re: [Bug 334809] Re: design problem? infinite wait for long queue

Ted, I'm cc'ing you on this because of the app developer interface
issues it raises. Mirco, your comments would be valuable too.

An obvious solution to the apps-that-spew-notifications problem is to
encourage the app developers to keep track of notifications and use
appends / replaces more efficiently. You give a good example, of a music
player that has a user skip through a series fo tracks very quickly. It
makes sense for the app to say "hey, I put a notification on the queue,
and I replace it with the latest playing track whenever that changes,
till it dies". That way, once it gets displayed it's current (and can
even be updated during display, extending its life).

At least, that makes sense to ME. Ted however feels that it's too much
to ask of developers to track their notifications. That drove some of
the design on the interface to appends, it's possible to do appends as a
series of notifications tagged "append please".

Does anyone want to look at the additional complexity required to make
the music player behave that way? It would put a notification on the
stack and then update it rather than putting new ones out there, till it
died (after which it would put a new one on there if the track changed).

Mark

Revision history for this message
Mirco Müller (macslow) wrote :

What Mark describes there is is possible with notify-osd right now. Ted I don't think it's too much to ask of a application developer to watch one notification. It's easy to implement. Have a look at the attached screencast were I simulate Mark's music-player example with a simple python script feeding notify-osd (but that could very well be done from rhythmbox/banshee/etc). You "see a user" skipping 4 tracks at 2 second intervals, then "listening" for 7 seconds (thus the first notification lives for 13 seconds), skipping 4 more tracks, "listening" again for 7 seconds (so second bubble also lives for 13 seconds) and finally skipping 2 more tracks (third bubble lives for 7 seconds).

Revision history for this message
Mark Shuttleworth (sabdfl) wrote :

Thanks Mirco, that's very cool. Can you look into the feasibility of
having the default Karmic music player adopt this pattern?

Revision history for this message
Steve Dodier-Lazaro (sidi) wrote :

Hello people,

I worked on the libnotify plugin for Exaile (0.2 & 0.3, but well, they're
not stable yet). The behaviour described by Mark is really not difficult to
implement. You just have to use update() instead of creating new
notifications, it's nothing hard (but notification-daemon is a big failure
with update(). It doesn't really manage it properly).

Now about my point of view on developers who don't want to bother with these
"details", as much as bother with the whole interface design, well, they're
just gonna lose their users to other apps with less features but easier to
use and looking nicer with a desktop. Users don't want exclusively features,
they also expect some coherence between the apps (æsthetically, but also for
menus, keyboard shortcuts, etc), and if an app looks different, it's just
not used by the vast majority. Making one's app behave nicely in an aimed
desktop is just as important as making it work at all.

Cordially, SD.

PS : if anyone wanna test the plugin there is a bug on LP where it's
attached ( https://bugs.launchpad.net/exaile/+bug/332999 ). This isn't the
latest version but I'm waiting for Exaile to hit 0.3 before recoding it
properly.
PS2 : video here http://www.youtube.com/watch?v=HGBAZXfbwB8

Revision history for this message
Mirco Müller (macslow) wrote :

Well is it banshee or rhythmbox? :)

Revision history for this message
Steve Dodier-Lazaro (sidi) wrote :

Apparently it's Banshee, but it'd be good to also have a plugin for
Rhythmbox, since some of the current users will want to stay on it. If you
need some help doing it for RB I think i can have a look at the code.

Revision history for this message
Mark Shuttleworth (sabdfl) wrote :

Steve, you rock.

Revision history for this message
Steve Dodier-Lazaro (sidi) wrote :

Mark, if you keep telling me that I'll end up believing it.

Revision history for this message
Alex Murray (alexmurray) wrote :

I'm still seeing this (ie a large queue of notifications which quickly become irrelevant) with banshee when skipping tracks (ie. the notification for the track I skipped 20 seconds ago is currently showing and it will be at least a minute until the notification for the now playing track is shown since I skipped about 20 tracks in a row...) Is this still being worked on for Karmic?

Revision history for this message
Steve Dodier-Lazaro (sidi) wrote :

I don't know if Banshee is still going to be used as the new music player for Karmic (apparently not since RB is still seeded ?). The only thing to do is to replace the spawning of new notifications by an update of the current one, it's not hard to do. An answer from the bug triager for Banshee about this bug would be nice. Anyway, it's not a NotifyOsd bug, so I'm closing it. Feel free to reopen it if Banshee actually uses append / update and if there is a problem with NO itself.

Changed in notify-osd:
status: Confirmed → Invalid
Changed in notify-osd (Ubuntu):
status: Triaged → Invalid
Revision history for this message
Jeremy Nickurak (nickurak) wrote :

I still think this is a notify-osd problem. If 5 different apps send notifications just a little too quickly, the wait time for notifications can quickly become unreasonable. This is still a regression vs Intrepid.

Revision history for this message
Steve Dodier-Lazaro (sidi) wrote :

It's absolutely not a regression, it's a design decision. When you skip 20
tracks in a row, you'll have 20 bubbles queueing in notification-daemon too,
but they'll be shown and de-queued faster. The problem comes from
applications spamming the libnotify daemon instead of updating their
notification bubbles.

Revision history for this message
spiral (perfectdrug) wrote :

what about if I press Volume Up for a long time, on my multimedia-keyboard, and the notification keeps on flickering for a long time even when the max volume is reached, where should we address this bug?

Revision history for this message
Jack Leigh (leighman) wrote :

Definitely notice the problem with track changing here. Makes notify-osd kinda useless if it's displaying a track which started a few tracks back.

Revision history for this message
Alex Murray (alexmurray) wrote :

Attaching a patch against banshee which fixes this for me by just updating the existing notification each time rather than creating a new one for each track change. I've uploaded a patched copy of banshee with this patch to my PPA if anyone else wants to test it out:

https://launchpad.net/~alexmurray/+archive/ppa

Although I think its currently still in the build queue so you may have to wait a bit for it to build...

Changed in banshee:
status: New → Confirmed
Revision history for this message
Alex Murray (alexmurray) wrote :

Any word on whether this patch will be included in Karmic? It definitely fixes the problem and means one less regression from Jaunty.

Revision history for this message
Mirco Müller (macslow) wrote :

Alex have you linked your patch to banshee upstream in some way?

Revision history for this message
Mirco Müller (macslow) wrote :

If not please do so. hyperair wrote a patch too and put it here https://bugzilla.gnome.org/show_bug.cgi?id=597099 not knowing about your patch. Linking such stuff to lp and gnome-bugzilla helps avoiding this sort of thing.

Revision history for this message
Chow Loong Jin (hyperair) wrote :

Filed upstream.

Changed in banshee:
importance: Undecided → Unknown
status: Confirmed → Unknown
Revision history for this message
Alex Murray (alexmurray) wrote :

I had already posted a patch upstream against current git HEAD for Banshee: https://bugzilla.gnome.org/show_bug.cgi?id=596870 - although I think hyperair's patch in https://bugzilla.gnome.org/show_bug.cgi?id=597099 is cleaner. Will make sure I link launchpad bugs against upstream ones in the future. The reason I hadn't linked it is the patch for the Ubuntu version is significantly different from the current git version so I wasn't sure how relevant it would be. Thanks anyway.

Revision history for this message
Chow Loong Jin (hyperair) wrote :

On Friday 02,October,2009 09:14 PM, Alex Murray wrote:
> I had already posted a patch upstream against current git HEAD for
> Banshee: https://bugzilla.gnome.org/show_bug.cgi?id=596870 - although I
> think hyperair's patch in
> https://bugzilla.gnome.org/show_bug.cgi?id=597099 is cleaner. Will make
> sure I link launchpad bugs against upstream ones in the future. The
> reason I hadn't linked it is the patch for the Ubuntu version is
> significantly different from the current git version so I wasn't sure
> how relevant it would be. Thanks anyway.
>
> ** Bug watch added: GNOME Bug Tracker #596870
> http://bugzilla.gnome.org/show_bug.cgi?id=596870
>
Strange, I didn't see your bug when I searched for it on BGO earlier. My bad.
Thanks for your efforts anyway. I just happened to look into this issue after
Laney alerted me to this on #debian-cli. I didn't think to look in launchpad for
an existing patch either.

--
Kind regards,
Chow Loong Jin (GPG: 0x8F02A411)
Ubuntu Contributing Developer

Revision history for this message
Alex Murray (alexmurray) wrote :

No worries, I guess as long as the bug gets fixed thats all that really matters :) Cheers.

Revision history for this message
Jeremy Nickurak (nickurak) wrote :

Pretty much any application that doesn't support the indicator but supports notification is still going to be a problem.

A couple cases I deal with *frequently*:
- mail-notification
- xchat-gnome

xchat or xchat-gnome in particular are the de facto irc clients under linux, as far as i can tell, and it can handle this case VERY badly.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Could somebody give details on what xchat-gnome should be doing to avoid the issue for example?

Revision history for this message
Mirco Müller (macslow) wrote :

Like I mentioned in an earlier comment (with examples screencast) these apps should make use of the "replace" or "append" feature of notify-osd. Examples (in C, C# and Python) how to do that an upstream developer can find in notify-osd trunk under...

./notify-osd/examples/update-notifications.[py|c|cs]
./notify-osd/examples/append-hint-example.[py|c|cs]

I'd say in general apps, which are not IM-clients (à la empathy or pidgin) should use the update/replace feature of notify-osd.

Revision history for this message
Alex Murray (alexmurray) wrote :

Just wondering if hyperair's patch will get applied to Ubuntu's banshee before Karmic is released?

Revision history for this message
Chow Loong Jin (hyperair) wrote :

On Saturday 10,October,2009 08:44 PM, Alex Murray wrote:
> Just wondering if hyperair's patch will get applied to Ubuntu's banshee
> before Karmic is released?
>
Fixed in latest upload by Iain Lane

  affects ubuntu/banshee
  status fixreleased

--
Kind regards,
Chow Loong Jin (GPG: 0x8F02A411)
Ubuntu Contributing Developer

Revision history for this message
Jeremy Nickurak (nickurak) wrote :

The more I think about it, it's really unfortunate that you're calling for standards-compliant applications to be "fixed" to work with notify-osd, instead of the other way around.

Revision history for this message
Matthew Paul Thomas (mpt) wrote :

It is possible for a program to be standards-compliant and badly-behaved at the same time. With notification-daemon, the same programs would be causing either a queue just as bad, multiple overlapping notifications (which is no use to anyone), or notifications which are too brief to read.

That said, if there is any part of <https://wiki.ubuntu.com/NotifyOSD#Flood%20prevention> that is not implemented, please report a separate bug for that, preferably with a test case.

Bryce Harrington (bryce)
Changed in xchat-gnome (Ubuntu):
importance: Undecided → Wishlist
status: New → Triaged
Changed in banshee:
importance: Unknown → Medium
status: Unknown → Fix Released
Revision history for this message
Jeremy Nickurak (nickurak) wrote :

Affects netbook-launcher, as in dupe # 414356

Revision history for this message
Jeremy Nickurak (nickurak) wrote :

Patch for xchat-gnome to use append.

Question though for notify-osd developers: Is there any scenario where appending ISN'T the right behavior? Is it a common case?

Since the normal behavior of upstream's notification-daemon is to add another notification for each notification, it seems that appending as the default would be the closest to "normal" behavior. In the odd case where one wouldn't want append, maybe an opt-out hint ("x-canonical-no-append"?) could be specified.

Changed in xchat-gnome (Ubuntu):
status: Triaged → In Progress
Changed in notify-osd:
status: Invalid → New
Changed in notify-osd (Ubuntu):
status: Invalid → New
Revision history for this message
Omer Akram (om26er) wrote :

package netbook-launcher does not exist in maverick. and the project is not being maintained anymore

Changed in netbook-launcher (Ubuntu):
importance: Undecided → Wishlist
status: New → Won't Fix
Revision history for this message
Matthew Paul Thomas (mpt) wrote :

Jeremy, that's a good question. One example that occurs to me is where two people are chatting with you at once: their messages shouldn't appear in the same bubble. It would be interesting to collect a sample of $HOME/.cache/notify-osd.log files and count how many of the notifications would make sense appended vs. how many would not.

Changed in xchat-gnome:
importance: Unknown → Medium
status: Unknown → Confirmed
tags: added: patch
Changed in xchat-gnome:
status: Confirmed → Incomplete
Changed in xchat-gnome:
status: Incomplete → Confirmed
Changed in xchat-gnome:
status: Confirmed → Fix Released
Changed in mail-notification (Ubuntu):
status: New → Confirmed
Changed in notify-osd (Ubuntu):
status: New → Confirmed
Revision history for this message
JC Hulce (soaringsky) wrote :

Fixed version for xchat-gnome has been released

Changed in xchat-gnome (Ubuntu):
status: In Progress → Fix Released
Revision history for this message
Moritz Oberhauser (zomtir) wrote :

Added rhythmbox to the affected packages ( Bug #1198144 ). Either rhythmbox shouldn't send notification when songs are changed manually or the notify OSD has to handle the queue and cut it down.

no longer affects: notify-osd
Revision history for this message
Moritz Oberhauser (zomtir) wrote :

Tested on 13.10 and was fixed. Skipping song immidiatly updates the notifier.

Changed in rhythmbox (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.