Banshee album art is blurred in notification bubbles

Cached album art in .cache

I've can confirm with that exact album art (good choice!). I've noticed when using rhythmbox it is also blurry, so I think this is notify-osd scaling the art so I am reassigning it there.

Maybe it's the scaling algorithm notify-osd uses, there is a similarly sized thumbnail on the main banshee ui by the slider and it doesn't look too blurry, but I'm just measuring with the naked eye.

We use gdk_pixbuf_scale_simple(pixbuf, size, size, GDK_INTERP_HYPER) which is the best we can get. Jorge can you provide a comparison screenshot from banshee with the same cover-art?

Here's a comparison screenshot using Nicolò's supplied cover-art image directly via notify-send. I place the screenshot of his notification direcly under my live one. You can clearly see that notify-osd renders it crisper (above). So my guess is that ryhthmbox is not handing the origingal source cover-image to the notification, but scales it down before sending it to the daemon. Thus it is out of notify-osd's control to ensure crisp rendering.

According to upstream Banshee they do a resize to 42px:

http://svn.gnome.org/viewvc/banshee/trunk/banshee/src/Extensions/Banshee.NotificationArea/Banshee.NotificationArea/NotificationAreaService.cs?revision=5084&view=markup

Upstream would like us to file a bug if they're supposed to be doing something different, I don't see anything in the notify-osd guidelines or the notification spec that mention scaling of images at all so I don't know what the apps are supposed to here.

Wait. I just realized a strange thing. My notification are bigger than yours.
And are also bigger than the one shown in a session of a new user.

The problem might be this: the icon is sized for a smaller notification!

How is it possible to control the size of the notification?

And how can I use notify-send with a jpg image? I've tried
--icon=filename but it does not work

Nicolo,

Even when testing locally it's a Banshee problem, I think the notifications size according to your fonts and DPI but I am unsure.

Apparently pidgin has the same problem, not when sending buddies
icons, but when sending its own icons (for instance when a user has no
buddy icon)

Yes, this is more than a bansheeproblem. As Nicolò said, pidgin suffers from the same problem and so does Rhythmbox. The error is in notify-osd I think

what is the size of the icons that banshee sends? in pidgin it's 48x48

"According to upstream Banshee they do a resize to 42px"

This problem is in every application using the new Notify-OSD. Dropbox is having the same problem!

I have now talked to people in #pidgin, the problem with pidgin in this case (and most likely dropbox to) is that they do not actually have a highresversion of the icon in question and therefore we see a lowresicon

feel free to send this upstream at bugzilla.gnome.org for the rhythmbox task as well.

The issue with lowresicons in pidgins buddyicons (check here: http://pici.se/396034/ ) is unfixable. That image is the only image we get from MSN and there is no way to make it bigger without upscaling it (and making it look bad). The only way this can be fixed is to use a smaller picture inside the bubbles.

On Fri, 2009-04-17 at 19:48 +0000, Åskar wrote:
> The issue with lowresicons in pidgins buddyicons (check here:
> http://pici.se/396034/ ) is unfixable. That image is the only image we
> get from MSN and there is no way to make it bigger without upscaling it
> (and making it look bad). The only way this can be fixed is to use a
> smaller picture inside the bubbles.
>
How big does notify-osd require the icons be? I believe the buddy icons
are 96x96 mostly (from poking in ~/.purple/icons), which is very much
bigger than the icon shown in the screenshot (46x46?)
--
Regards,
Chow Loong Jin

At least "128 pixels in either width or height, to minimize the appearance of artifacts when it is scaled" according to https://wiki.ubuntu.com/NotificationDevelopmentGuidelines

This bug needs to be fixed with different code in different programs, so it's not really appropriate to have them all in the same bug report. This bug report is about Banshee. Bug 360228 is about Pidgin. Please report a separate bug about Rhythmbox.

I've produced this patch. If this is ok for you I can make a debdiff.

I'm building banshee now, I will tell you if it works soon

It seems it works. this is the comparisons of the 2 screenshots

it doesn't affect notify-osd... I resolved it with a patch to banshee...

I have now tried your patch and it seems to work :)

On Mon, Apr 20, 2009 at 04:51, Matthew Paul Thomas <email address hidden>wrote:

> This bug needs to be fixed with different code in different programs, so
> it's not really appropriate to have them all in the same bug report.
> This bug report is about Banshee. Bug 360228 is about Pidgin. Please
> report a separate bug about Rhythmbox.
>

I know it's OT, but isn't that one of the things Launchpad encourages? Don't
get me wrong, I totally agree, but there are plenty of bugs like this that
have multiple, separate projects on them.

Please also commit the banshee patch if possible

GNOME watch seems to be broken but this is fixed in 1.5.0 upstream now.

I confirm it fixed

"there are plenty of bugs like this that have multiple, separate projects on them"

Yes, single bug reports have been used in the past for things like library/language transitions on many different packages. However, that tends to waste more time (in extra bug mail to uninterested people) than it saves (in sharing code and ideas). So it's not clear-cut, but in general, two projects/packages should share a bug report only if it's likely that the same diff will fix the bug in both places (e.g. Mozilla Firefox vs. Ubuntu firefox), or if there's only one bug but the respective people need to collaborate in working out which software needs fixing (this often happens with Notify OSD vs. gnome-settings-daemon) .

This bug is confirmed to not exist in the latest release of Banshee (1.5) it is however not going to be available in Jaunty because this bug is not a security issue. It will however be fixed in the next Ubuntu release (Karmic).

Thank you for reporting this bug and helping to make Ubuntu better.

This bug was fixed in the package banshee - 1.5.1~git2260a87-0ubuntu1

---------------
banshee (1.5.1~git2260a87-0ubuntu1) karmic; urgency=low

  [ Chow Loong Jin ]
  * debian/control, debian/changelog:
    + Use mono-csc instead of csc for MCS.
    + Bump mono-devel version to 2.4.2 for mono-csc

  [ Iain Lane ]
  * Upload upstream snapshot from revision 2260a87. FFe granted on IRC by
    ScottK and sistpoty. Uploading a snapshot as 1.5.1 is almost released,
    which has a lot of improvements over 1.5.0. We have preliminary SRU
    approval to update to 1.5.1 final if it is released after Karmic, subject
    to the usual criteria:

    New Features:

    - Play Queue Auto DJ keeps the tunes coming
    - Shuffle by album and artist
    - Shuffle by weighted rating and score mode
    - Add tooltips for ellipsized ListView text
    - Keep the playing song visible in the track list
    - Add support for WebOS devices
    - Add support for the Samsung Galaxy Android Phone

    Enhancements:

    - When user picks new sort column, default to sort ascending
    - Drop the " Library" suffix on the Music and Video sources
    - Add thin highlight to ListView selection for 3D effect
    - Keyboard shortcut (ESC) to clear the search box
    - Expose LAME's "preset" option
    - Added a --gconf-base-key for running sandboxed
    - Trim URL pasted from clipboard to podcast dialog
    - Allow selection of multiple folders on import
    - Support playlists on Android G1 devices
    - Better support for devices running Rockbox
    - Set video sync folder for Android and WebOS devices
    - Made the error message label selectable
    - Save and load the Gtk.AccelMap
    - Added taglib/oga mimetype to the vorbis audio profile
    - Auto-completion for composer, conductor, grouping and copyright
    - Added the 'comment' search filter
    - Selectable song properties
    - Show a tooltip in track editor when the property is truncated

    Notable bug fixes:

    - Fix blank MimeTypes for tracks ripped before 1.4
    - Fix a Bit Rate column sizing glitch
    - Fix browser positioning when Banshee is maximised
    - Fix compilation metadata reading and writing
    - Work with new notification-daemon
    - Avoid needlessly syncing iPods twice
    - Deterministically sort sources to avoid fluttering
    - Look for Rhythmbox db at both new and old paths
    - Fix bug with scrobbling after skipping a track
    - Fix crash in equalizer
    - Fix an exception on startup when DBus is disabled
    - Fix off-by-one-day date querying bug
    - Fix a UI/spacing glitch in the Smart Playlist Editor
    - Don't hide the track info popup while it has focus
    - Prevent endless "Searching for CD metadata..."
    - Fix Last.fm now-playing for non-decimal track lengths
    - Dispose the SqliteCommand after it's executed
    - Fix notification area popup positioning on multi-monitor systems
    - Fix the playing indicator when song in list more than once
    - Fix crash when opening the profile conf dialog
    - Fix crash stopping jobs on shutdown
    - Fix notification area popup flashing
    - Trim filename dots and spaces to be NTFS compliant
    - Stop playing from audio CD ...