After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 528208 - [artdisplay] Covers for radios
[artdisplay] Covers for radios
Status: RESOLVED OBSOLETE
Product: rhythmbox
Classification: Other
Component: Plugins (other)
HEAD
Other All
: Normal enhancement
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
: 601314 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-04-15 12:31 UTC by Jérémie Detrey
Modified: 2018-05-24 13:18 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Adds support for radio covers (1.01 KB, patch)
2008-04-15 12:41 UTC, Jérémie Detrey
needs-work Details | Review

Description Jérémie Detrey 2008-04-15 12:31:36 UTC
Everything is in the title: why not support images/logos for radios too?
Comment 1 Jérémie Detrey 2008-04-15 12:41:02 UTC
Created attachment 109301 [details] [review]
Adds support for radio covers

Radio covers/logos can be uploaded as "~/.gnome2/rhythmbox/covers/<Title>.jpg" where "<Title>" is the title given to the radio.

This patch just changes the "<Artist> - <Album>.jpg" scheme used for songs and replaces it by "<Title>.jpg" when both "<Artist>" and "<Album>" are empty (which is the case for radios).
Comment 2 Jonathan Matthew 2008-04-15 14:22:30 UTC
Well, this isn't very useful without either a way to automatically find a logo for a station or a means for the user to provide one.  Telling the user to copy a file into the cover cache directory isn't going to work.
Comment 3 Jérémie Detrey 2008-04-15 14:33:59 UTC
Yes, sure, but that's already what the user is told to do if a cover automatically downloaded from Amazon doesn't correspond to the actual cover.

I know it's nothing revolutionary here, but it's already a useful[*] patch before someone really addresses this cover management issue. And I guess it doesn't hurt to already adopt this naming scheme for the radio covers.

[*]: At least _I_ use it :)
Comment 4 Jonathan Matthew 2008-04-15 21:34:20 UTC
Whoever is telling users to do that should stop.
Comment 5 Jérémie Detrey 2008-04-15 22:20:45 UTC
Well... It's pretty much written in the Rhythmbox FAQ: http://live.gnome.org/Rhythmbox/FAQ

  "Where are lyrics and artwork stored?
   Lyrics are stored in ~/.lyrics and artwork in ~/.gnome2/rhythmbox/covers"

(Even though I have to admit that the next item details a simpler way to change a default cover. But then again, why mention those internal directories in the FAQ in the first place?)

But it's not the important reason for my patch here. The reason is simply that there is currently _no_ other way to have cover art for radios. Apart from editing the "rhythmdb.xml" file, filling in the <Artist> and <Album> fields for the radio and then putting a correctly named (ie. "<Artist> - <Album>.jpg") file in the ".gnome2/rhythmbox/covers" folder. But even then, the tray icon tooltip would incorrectly report the <Artist> and the <Album>.

I just think that this patch introduces a new feature (unsignificant that it may well be) without hurting anything else in Rhythmbox. If users don't want to go through the hassle of copying a file to the correct directory, no problem. But if they do, why not letting them do so, only with a more appropriate naming scheme?
Comment 6 Jonathan Matthew 2008-04-16 04:09:55 UTC
"pretty much" - but it doesn't actually say "stick files in here with this naming scheme".  I'm not sure why the person who added that to the FAQ did so.  The cover art cache directory and naming scheme are implementation details, subject to change at any time for any reason.

I'm not trying to say that this feature is a bad one, just that this implementation is lacking.  It's not at all discoverable, it's hard to use, and it may break at some point in the future.

Here's how I'd like to see this work:  implement a new cover art search class that only handles http URIs; have it look in a separate directory (~/.gnome2/rhythmbox/covers/iradio/ or something) based on the stream URL (not title), and give it a save_pixbuf method that saves the image to this directory.

That isn't a huge amount of work, and it will make this feature usable.
Comment 7 Jérémie Detrey 2008-04-16 05:53:35 UTC
Alright, I'll look into that then, no problem.

Although I'm not sure about this URL-based naming scheme. I would think that the stream URL of a radio is more likely to change than its title. What are your thoughts on this?
Comment 8 Jonathan Matthew 2008-04-16 08:55:41 UTC
I'm not sure how the stream URL is going to change.  It is user-editable, but I'd be surprised if stations actually moving is common enough that it's something we should think about at all.  I have changed station titles in the past, usually because they're overly long and don't actually describe the station well.
Comment 9 Jérémie Detrey 2008-04-16 12:40:50 UTC
OK then. It's just that I've had the exact opposite experience: changing the stream URL because it was updated on the radio page, or because they introduced higher-bitrate streams, and so on...

Anyway, we'll see about it later. The naming scheme is no big issue to change.
Comment 10 Arthur Taylor 2008-06-30 05:54:14 UTC
I support this patch as it enables dragging artwork into the cover display for radio stations. Currently you can drag artwork there and it will display when listening to radio, but the file gets named " - .jpg" as the artist and title fields are blank. To an end-user who doesn't even know of ~/.gnome2/rhythmbox/covers this just seems broken as it seems that "Radio" can only have one piece of artwork for all stations, as every station is " - .jpg" for all rhythmbox knows.
Comment 11 Jonathan Matthew 2009-11-09 21:55:33 UTC
*** Bug 601314 has been marked as a duplicate of this bug. ***
Comment 12 GNOME Infrastructure Team 2018-05-24 13:18:13 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/rhythmbox/issues/539.