Bugzilla – Bug 17432
Random artwork chosen for album
Last modified: 2012-01-07 11:20:12 UTC
In 7.5.x, if SBS scanner couldn't find artwork with an expected name (or tagged), it would result in no artwork for the album. In 7.6.x, the scanner will now try to choose any artwork that it can find in the folder where the songs are located. I don't like this new approach - it means I get incorrect artwork scanned, and it's not obvious - at a glance (or DB query), I can't find albums that have missing artwork. I prefer to know when I haven't got cover artwork for an album, so I can then fetch the right artwork.
I agree.
"I don't like the new behaviour" is not a bug :-P. AFAIK this feature has been asked for many times.
I disagree, this change is fine. If you have other random artwork in your album dir but no cover.jpg, some artwork is better than no artwork.
I disagree - random, incorrect graphical images that are not cover images that the user didn't ask for are worse than no cover artwork. Note that I consider it a bug, because in the Advanced settings / Formatting page, the artwork setting has a note that says: "Images of album artwork, when available, are displayed when viewing an album or song information. Artwork images are found in the ID3 tags for individual songs or can reside in the same folder as song files. By default, images named "cover.jpg", "folder.jpg", "album.jpg", or "thumb.jpg" are used. You can specify an additional file name to use for album art images. You can specify different file names for thumbnail or full size images. Prefix the option with % and you can follow it with any string made up of the same elements available for Title Formats (eg %ARTIST - ALBUM, will look for Artist - Album.jpg to fit the artist and album information found)." This does not indicate that files that are not one of these names will be picked up by the scanner. If I forget to add an album tag, the scanner doesn't randomly use a different tag as the album name instead (it should default to "No Album"), so why should artwork scanning choose some other arbitrary file, instead of no artwork? It's just obscuring library faults. No other media player that I know of has this effect - what makes you think this is better? I'm guessing there's a reason why this was done, relating to LMS scanning that is to come in the future? Perhaps Artwork=* could be used to indicate "choose any file that is available", and if Artwork setting is left blank, it wouldn't find any.
There is another bug about artwork not using the % format, bug 17343, this one here is about the fact that you put other artwork in your album directory. Since we found no standard filenames, maybe you just typo'd the artwork filename or something, so we show the first other image we find.
Okay, bug 17343 definitely needs fixing. I also think that it's now even more important that the scanner is fixed such that when image files change on disk, the scanner finds the changed images and updates the DB accordingly. I'll test if this still happens in 7.6.1. i.e. there's a long running bug report somewhere that the scanner doesn't pick up changes in artwork files for albums. If the scanner now picks a random file as artwork that is wrong, and the user adds the correct artwork file, it will be really annoying if it's not corrected in DB, and a full rescan is required to correct the DB content. Even then, I still disagree that it's good to guess that any old image file that happens to be in the same source folder is what the user wants. BTW, what happens with artwork file searching if songs are in different source folders? Does it only search for artwork in the first song's source folder?
It's odd that some changes are consciously made to library scanning that force the user to be extra mindful of precise tagging and organization, while the change described here is aimed at exactly the opposite.
Different source folders?! I thought we stopped caring about that a while ago, or it was only an iTunes issue where the user won't have any local artwork files anyway. Anybody putting in their own art files would be crazy to store a single album across multiple folders.
Can you give me an example of an album where this happened to you, what other types of artwork were in the folder?
(In reply to comment #8) > Different source folders?! I thought we stopped caring about that a while ago, > or it was only an iTunes issue where the user won't have any local artwork > files anyway. Anybody putting in their own art files would be crazy to store a > single album across multiple folders. > It's not something I'd ever do, but I know there are some people that have libraries like this. This is because it is the default iTunes configuration. Compilation albums are stored religiously by artist/album/song. As a result, I think people use COMPILATION=0 and ALBUM ARTIST=Various Artists, to forcibly join the album back together again! I'm just wondering what happens with artwork scanning in this situation. I suppose with iTunes, there would be embedded artwork in each file, so it would choose the artwork in the first song that is scanned?
(In reply to comment #7) > It's odd that some changes are consciously made to library scanning that force > the user to be extra mindful of precise tagging and organization, while the > change described here is aimed at exactly the opposite. Yes, exactly. We've finally got diacritics and case differences in artist names to be seen as different things, and now album artwork has gone the other direction!
(In reply to comment #9) > Can you give me an example of an album where this happened to you, what other > types of artwork were in the folder? > I have several live concerts downloaded that have several artwork files, such as front+back cover, inside front+back, CD labels, concert ticket stubs, etc. I usually edit the front+back cover image, cropping out just the front cover, and storing as "cover.jpg". When I forget to do this in 7.5.x, I get no artwork, and it's obvious. I have a a DB query to show albums missing cover art too. Now in 7.6, I get one of the images from the folder, none of which is nice. Sometimes it's a front+back image, which is twice as wide as it is high, so it needs to be scaled into a square for display. I just tried fixing one of these, by adding a Cover.jpg, and scanning for new+changed files, and the scanner doesn't detect any new image files, so I am stuck with the incorrect image until the next time I do a full clean+rescan.
(In reply to comment #9) > Can you give me an example of an album where this happened to you, what other > types of artwork were in the folder? I have a folder in which a collection of different mp3s are present, for a number of different artists (various artists). For some mp3s I have matching artwork, for some I don't. The new behaviour causes (wrong) artwork to be found for tracks for which no artwork is actually present. I wrote about this on the forum a while ago. (http://forums.slimdevices.com/showthread.php?t=89870) People who want to change the behaviour can apply the patch found there.
(In reply to comment #13) > (In reply to comment #9) > > Can you give me an example of an album where this happened to you, what other > > types of artwork were in the folder? > > I have a folder in which a collection of different mp3s are present, for a > number of different artists (various artists). For some mp3s I have matching > artwork, for some I don't. The new behaviour causes (wrong) artwork to be found > for tracks for which no artwork is actually present. Your best bet there is to explicitly place a generic/placeholder image into folders that contain music from different albums.
(In reply to comment #14) > Your best bet there is to explicitly place a generic/placeholder image into > folders that contain music from different albums. Ok, I put a file cover.jpg in there, and that will indeed be used if no track specific artwork can be found. This would solve my problem. (I like my solution better though ;)