Docky

Rhythmbox Helper Not Showing Cover Art... Again

Bug #578254 reported by Chris Gross on 2010-05-10

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	Docky	Fix Released	Low	Rico Tzschichholz	Docky 2.0.4 "Do you think you're better off alone?"

Bug Description

This bug was previously reported and supposedly fixed (https://bugs.launchpad.net/docky/+bug/519977), but it's back again. I've since upgraded to ubuntu 10.04/64 and I am not seeing album art in the rhythmbox helper. Last time, it seems that you guys found a way to have all album art automatically extracted to ~/.cache/rhythmbox/covers because for some reason, art embedded in the files could not be read (even though this works with the banshee helper).

Tags:

Related branches

lp:ubuntu/lucid-proposed/docky

lp:debian/docky

lp:~minium/ubuntu/trusty/docky/fix-1271131

Robert Dyer (psybers) on 2010-05-10

Changed in docky:
assignee:	nobody → Rico Tzschichholz (ricotz)
importance:	Undecided → Low

Revision history for this message

Rico Tzschichholz (ricotz) wrote on 2010-05-10:

Is it possible you are just missing the "python-mutagen" package?

Changed in docky:
status:	New → Incomplete

Revision history for this message

Chris Gross (gross-cw) wrote on 2010-05-10:

actually, a cover appears when a track is played, but that particular album cover remains displayed indefinitely, even after the next track starts playing.

Revision history for this message

nam (nam85) wrote on 2010-05-12:

rhythmbox_control.py not updating cover image when using covers from id3 tags Edit (1.6 KiB, text/plain)

This is a bug in rhythmbox_control.py when you play two songs where the covers are extracted from the embedded tags. Then, the variable arturl in DockyRhythmboxItem::update_icon points to /tmp/docky_$USER_rhythmbox_helper.original.png. This file may get updated as the next song comes up, but the rhythmbox helper only check if the filenames differ (line 190).
I simply uncommented that if statement on my machine. I don't know if it would be more efficient to check the mtime of that file or get a hash.

But there's actually another thing I'd like to adress. rhythmbox_control.py looks for image files in the song folder first.
I have quite a few folders, where the cover image is called "Folder.jpg" (Windows Media Player did that), but rhythmbox_control.py looks for the lower-case variant and fails to detect the "Folder.jpg" file.

I added the other cases as well.

See attached patch.

Changed in docky:
status:	Incomplete → Confirmed

Revision history for this message

Rico Tzschichholz (ricotz) wrote on 2010-05-12:

@nam: Thanks for the patch

Changed in docky:
status:	Confirmed → Fix Committed

Revision history for this message

Chris Gross (gross-cw) wrote on 2010-05-12:

It works now. Thank you!

Rico Tzschichholz (ricotz) on 2010-05-25

Changed in docky:
milestone:	none → 2.0.4

Rico Tzschichholz (ricotz) on 2010-05-31

Changed in docky:
status:	Fix Committed → Fix Released

Revision history for this message

Martin Pitt (pitti) wrote on 2010-06-17: Please test proposed package

Accepted docky into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

tags:

added: verification-needed

Revision history for this message

Rico Tzschichholz (ricotz) wrote on 2010-07-02:

Helpers are python-scripts running independently of docky and were fully synced with our trunk versions in this case.

The problem here was that embedded cover images of songs played in rhythmbox aren't updated correctly. Playing two songs with embedded images that are different revealed the problem. Therefore we added a check for the modification time of our temporary file to solve this case.

This fix was confirmed to work and therefore it is verified.
https://bugs.edge.launchpad.net/docky/+bug/578254/comments/5