GNOME Bugzilla – Bug 401150
[artdisplay] improve heuristics for local cover art search
Last modified: 2018-05-24 12:17:39 UTC
looking on the Internet for cover art is slow and uses bandwith. Furthermore, 90% of my albums already have cover images in the same folder as the music. What should happen is this: 1- look in the album's folder for .jpg/.png files (or some other obscure formats?) 2- if there are multiple files in the folder, try finding one that has the "front" word in it, or the first one in alphabetical order if that fails? 3- if all fails, use the Internet Maybe I'm overlooking things/oversimplifying as a non-developper?
0.9.6 already has support for looking for cover art in directories it looks for image files in the album directory that start with the following: "cover", "album", "albumart", ".folder", "folder" e.g. cover.jpg or cover.png
hmm... so I guess my filenames did not match those criteria, why not look for *any* image filename when there is only one in the directory?
(In reply to comment #2) > hmm... so I guess my filenames did not match those criteria, why not look for > *any* image filename when there is only one in the directory? False positives are bad. I'm not sure I can think of a realistic scenario, but I'm sure it exists.
Retitling bug to reflect that the real issue is better local cover art heuristics (although it may not be desirable to go as far as comment #2 because of comment #3).
What about stuff like front*.jpg/png? Could this be added to the current lookups?
For bug 474914 I'm moving the list of image file prefixes into GConf, which would allow the user to specify what they want the list of prefixes to be. I'll look into supporting wildcards, like in comment #5, but I am personally not in favor of making the wildcards default. The first version of the patch should be posted against bug 474914 tonight, but won't include a preferences dialog initially.
I submitted a patch against bug 474914 to add the search terms to GConf, though there isn't a way within Rhythmbox to edit that list. Wasn't someone working on a Right-Click menu for the Cover Art? I looked at the prospect of allowing wildcards in the search terms, which would require us to use the re module anyway. At that point, it would be easiest to just set up Regular Expression matching, but I don't know if we should expect users to know how to use RE. Currently, the function only tests that the part before the extension is in the list (unlike comment #2, which suggests that front_whatever.jpg would be valid). I could have it search that the string must be contained in the filename, but then the order in which the strings are defined becomes very important, and back_cover.jpg and front_cover.jpg would both match against 'cover' but 'back_cover' would be the first match to hit, and thus the image displayed. So, really, I'm starting to think that wildcard matching may cause a lot of problems.
I would like to know what do you think about searching inside the music files also? almost all my mp3 songs already have my desired hi-res cover inside the metadata (iTunes uses this feature). FLAC files also support this feature. Banshee already searches inside the music files for cover before looking on the internet. This is a smart thing to do.
@comment 8: see bug 345975, which is linked from tracker bug 412853.
*** Bug 477565 has been marked as a duplicate of this bug. ***
+1 (the originally reported problem) There could be some criteria for configuring the search preferences.
(In reply to comment #8) > I would like to know what do you think about searching inside the music files > also? almost all my mp3 songs already have my desired hi-res cover inside the > metadata (iTunes uses this feature). FLAC files also support this feature. > > Banshee already searches inside the music files for cover before looking on the > internet. This is a smart thing to do. Good idea but looks like a separate ehancement to me.
-- 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/309.