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 528137 - banshee no longer looks for cover.jpg in folder
banshee no longer looks for cover.jpg in folder
Status: RESOLVED FIXED
Product: banshee
Classification: Other
Component: Importing
git master
Other All
: Normal normal
: 1.2
Assigned To: Banshee Maintainers
Banshee Maintainers
: 527645 535024 540716 545744 (view as bug list)
Depends on:
Blocks: 512456 512457 523567
 
 
Reported: 2008-04-15 01:04 UTC by nyall
Modified: 2008-08-04 17:54 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description nyall 2008-04-15 01:04:13 UTC
Please describe the problem:
Most of my music is arranged in folders of albums, with a high quality cover image saved as cover.jpg in the same folder.

In 0.13.2, when banshee was importing music, it would look to see if this cover.jpg existed and use that for the album artwork (and if no cover.jpg was present, it'd do the web lookup for artwork). This setup worked really well.

In 0.98.3, it seems banshee no longer searches for a local cover file, and instead always grabs the artwork online. This isn't optimal, since the online grab sometimes gets the wrong cover, or a poor quality version.

Can a search for a local artwork file be readded into the import routine?



Steps to reproduce:
1. 
2. 
3. 


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Scott Peterson 2008-04-23 22:11:53 UTC
*** Bug 527645 has been marked as a duplicate of this bug. ***
Comment 2 Scott Peterson 2008-04-23 22:17:31 UTC
523567 looks like the bug report with the most history and info on this issue.

*** This bug has been marked as a duplicate of 523567 ***
Comment 3 Andrew Conkling 2008-06-14 19:59:45 UTC
Not the same issue, that's an enhancement for Banshee grabbing the wrong cover.jpg from the folder.
Comment 4 Andrew Conkling 2008-06-14 20:00:19 UTC
*** Bug 535024 has been marked as a duplicate of this bug. ***
Comment 5 Andrew Conkling 2008-06-14 20:05:20 UTC
Is this working in 1.0?
Comment 6 James Mason 2008-06-19 21:34:22 UTC
Nope, this is still broken.  I've been copying cover.jpg's to ~/.cache/album-art/  as a kludge.
Comment 7 Andrew Conkling 2008-06-20 13:06:49 UTC
(In reply to comment #6)
> Nope, this is still broken.  I've been copying cover.jpg's to
> ~/.cache/album-art/  as a kludge.

Thanks for testing; I'd noticed the same. I had the correct art saved as cover.jpg but Banshee downloaded the incorrect art.
Comment 8 Bertrand Lorentz 2008-06-29 22:12:41 UTC
*** Bug 540716 has been marked as a duplicate of this bug. ***
Comment 9 Andrew Conkling 2008-07-03 20:35:43 UTC
Bumping target; 1.0 is out.
Comment 10 benjaoming 2008-07-07 10:55:39 UTC
Additionally Folder.jpg isn't discovered. I have no idea where this convention is from, but emusic uses it.
Comment 11 Andrew Conkling 2008-07-11 20:52:56 UTC
(In reply to comment #10)
> Additionally Folder.jpg isn't discovered. I have no idea where this convention
> is from, but emusic uses it.

I believe Windows XP uses it for folder thumbnails in Explorer, and from a quick search on Google, it looks like Winamp might respect those files too. Bug 336249 covers its inclusion in Banshee.

This bug is about a regression between 0.13.x and 1.x.
Comment 12 Gabriel Burt 2008-07-22 14:38:46 UTC
Fixed in trunk.  I have it scan the folder for all jpg/jpeg files and pick the largest (in file size) one to use.
Comment 13 Richard Venneman 2008-07-22 19:00:23 UTC
I tried it and it works like a charm, nice!
Comment 14 Andrew Conkling 2008-07-24 13:40:17 UTC
This still doesn't work for the Sigur Rós album effectively known as "( )", even though I have one cover.jpg in the folder ~/Music/Sigur Rós/( )/. Not sure if the album name is messing it up, but when I play a track from it in SVN, I do get the "Downloading Cover Art" progress bar for about 10 seconds (the same for other albums that have local art that wasn't detected), but it doesn't work.

Different bug or part of the same behavior?
Comment 15 Gabriel Burt 2008-07-24 18:22:40 UTC
Different bug, already filed ("not parenthesis friendly")
Comment 16 Andrew Conkling 2008-07-24 21:43:49 UTC
(In reply to comment #15)
> Different bug, already filed ("not parenthesis friendly")

I discussed this album on that bug (bug 520516), but that was more about Banshee searching the internet for the cover art. In this case, it's a cover.jpg I already have in the folder. Is the problem that it's not finding the folder or something? I'd think it would just look in the same folder where the track is located, regardless of special characters in the path or album field.
Comment 17 Andrew Conkling 2008-07-31 12:26:32 UTC
(In reply to comment #16)
> In this case, it's a
> cover.jpg I already have in the folder. Is the problem that it's not finding
> the folder or something? I'd think it would just look in the same folder where
> the track is located, regardless of special characters in the path or album
> field.

...and yet, that seems to be the case: bug 530690.
Comment 18 Andrew Conkling 2008-07-31 20:29:03 UTC
*** Bug 545744 has been marked as a duplicate of this bug. ***
Comment 19 gmathisz 2008-08-02 14:14:11 UTC
With version 1.2 covers are not picked up by banshee when importing the album. The cover is located in the same folder with the tracks. I have tried naming the cover cover.jpg and folder.jpg but it seems not to make any difference. According to the release notes this feature is available with Banshee 1.2
Comment 20 longhong 2008-08-03 05:13:21 UTC
I have the some problem with banshee1.2. I must mention that my albums are chinese albums and certainly the name of albums are chinese names. But I've tested English albums and find the some problem: banshee cannot import cover art in an album folder.
Comment 21 Andrew Conkling 2008-08-04 17:54:04 UTC
(In reply to comment #19)
(In reply to comment #20)

See comment #17; it's a separate bug.