Sounds like iTunes is playing a pratical joke on you. :)

So if you move the image out of that directory, the cover art goes away?

I'm not sure how I feel about the proposal: I definitely have some albums with more than 30 tracks (I can think offhand of one with 40). Maybe instead of being track-based, it could see if the contents of that directory all match the same Album field?

Setting version at 0.13.x since SVN trunk doesn't have feature parity yet, but feel free to change it.

abock told me to file as trunk since he's actually thinking of doing some sort of cover art migration thing or something.

anyways, yea, if there are valid albums of 40 songs, then we can just bump the limit to 50.

from what I understand, in the future, abock wants to use a different means of storing cover art than just some file in the directory because it's really inefficient if the cover art image file can be named in any of 50+ ways.

*** Bug 528137 has been marked as a duplicate of this bug. ***

My observation is also that Banshee doesn't display the CD covers which are all named "cover.jpg" and located the directories of my albums, while 0.13.2 did this without problems.

What I'd like to add as useful information to this bug report is that apparently, 0.98.3 displays only the cover of one album for me, not the rest.

A possible way to avoid this could be:

When attempting to grab the cover art for an album, before checking online sources:
- Run a db query to make sure all tracks from the album are in the same local folder
- Run a second db query to make sure only tracks from this album are in this folder
- If so, check for cover.jpg, front.jpg, folder.jpg (etc) present in folder. If so, use it for cover art.
- If not, proceed to checking online sources

This way, if an album is scattered over a bunch of folders, or if a bunch of random tracks are all in the same folder, banshee wouldn't use a cover.jpg file. It would only use cover.jpg files if this album, and only this album, is all present in the one folder.

In pseudo code this could be something like:

if ("select count(distinct track_location_uri_field) from song_table where album_id=?" == 1)
{
   if ("select count(distinct album_id) from song_table where track_location_uri_field=?" == 1)
   {
      if (file_exists("cover.jpg","front.jpg","folder.jpg"))
      {
          // use file for album art
      }
   }
}

 

    

*** Bug 547794 has been marked as a duplicate of this bug. ***

(From bug 547794):
> When a folder (with a cover art file included) contains more than a certain
> amount of files, the cover art will not be shown.
> 
> Steps to reproduce:
> 1. Create a folder with about 30 music files and a cover.jpg file. Tag artist
> and album with a senseless name to make sure no cover art will be fetched from
> the internet. Delete ~/.cache/album-art/ to make sure no previously fetched
> cover will be used.
> 2. Import this folder into Banshee (without copying).
> 3. Play a song out of this folder and see if cover art is shown.
> 4. If not, remove one file from the folder.
> 5. Play the song again (or another song that is still in the folder) and see if
> cover art is shown now.
> 6. Repeat from step 4 until cover art is shown.
> 
> 
> Other information:
> Possibly my bug is someone else's feature (see Bug #523567). If music is not
> stored in a (IMHO) "natural" Artist/Album/Songs (or in some cases
> Compilations/Album/Songs) folder hierarchy, but in one single folder containing
> quite a lot of songs from different artists and/or albums, then every song
> would show up with the same cover art, which surely makes no sense and would be
> annoying.
> 
> So if the bug reported was intended as a feature, then it would be very helpful
> to provide an option in the preferences to define how many items a folder is
> allowed to contain until it is no longer considered a single album folder
> (where JPG/PNG files included are to be considered as cover art belonging to
> the album and therefore having to be shown). So the one with hierarchically
> filed music can set this number to "9999", and everybody else to about "20",
> and both are done.

Sounds like what I was afraid of in comment #1. :P This bug is still open, yet I seem to recall something like it landing in trunk. Can anyone verify that?

Banshee now uses the following criteria :
It will not use cover art files from a directory if "Number of items in directory" > Max (20, track.TrackCount + 8).
So if you have an album with 40 tracks, it will work as expected if the "Track Count" tag is set to 40 on those tracks.

This makes sense as long as you always count from the very first to the very last track of an album, even if it consists of more than one CD.

In that case - e.g. CD 1 = 12 tracks, CD 2 = 14 tracks - I have no TrackCount of 26, but one TrackCount of 12 (for tracks 1-12 of disc 1/2) and one of 14 (for tracks 1-14 of disc 2/2), both in the same folder and both concerning the same album. This is because I do not want to consider e.g. the third track of the second Disc as track no. 15 - it always remains track 3 of disc 2 for me, even if it is probably the 15th file in a folder.

Then in best case a track count of 14 is taken to calculate Max (=22, 14+8), which leads to not showing cover art, because 12 (CD 1) + 14 (CD 2) + cover.jpg = 27, and 27 > 22.

I really would like to see an option in the preferences to turn this off.

Until then I will split albums with more than one disc into subfolders (one for each disc) ;)

*** Bug 570155 has been marked as a duplicate of this bug. ***

I have a disagreement with the algorithm, based on my problems in the duplicate Bug 570155.

I appreciate the problem you're trying to solve -- I myself have folders with a ton of songs that shouldn't pick up a single "cover.jpg" file -- but by basing your algorithm on track count, Banshee is giving me a heck of a time trying to go back and fix a lot of albums that are very well tagged, except for total-tracks.

Your guess at "are these songs an album" by using your arbitrarily chosen "average number of songs" in an album is a rather inconvenient way to do it.  Especially coupled with Banshee (1.4.x) not noticing when I modify metadata in Musicbrainz Picard, this makes fixing my albums to work around this algorithm very annoying.  And truth be told, a "number of songs" is a poor criteria to heuristically figure out if songs are in the same album.

I have no idea about Banshee's database querying capability, but I would find an algorithm like like this much more sensible:

1.  Whenever Banshee retrieves a piece of cover art, it should check the folder it comes from.

2.  It should then query that folder (assuming the database keeps track of directory info for each song) to find the number of albums in that folder.

3.  If NUM_ALBUMS>1, then that cover art obviously cannot be applied to all those tracks, and should be ignored.

This method is simple, doesn't set an arbitrary album size for a poorly tagged album, and also fixes every case of "I've got a folder full of songs and don't want them all slapped with the same iTunes art file."  I don't know if it's possible, but a change like this would be most welcome.

It solves the problem with directly relevant logic (does this cover art 1:1 correspond with this folder as an album?) rather than dancing around the question using a quick MAX() call that, whenever a user has tried to organize his music into folders, is likely to cause as much confusion as it fixes.

Recap:

1. A particular user has too many files in a single directory (as well as, perhaps, an unknown number of other users may...)

2. iTunes usually uses a GUID to match album artwork to songs but also downloaded an album cover and gave it a generic name (bug in iTunes?)

3. A complicated algorithm is implemented in Banshee to do nothing more than remove a function (instead of wrong artwork, no artwork?).

4. A bug report (bug 570155) against this logic, is dismissed as a duplicate (it's not!) along with a patch that restores the original functionality.

What was fixed? What was resolved? 

There are lots of audio CDs with more than 30 tracks.

Equating the concept of "album" with "audio compact disc" is a fallacy.

There's no reason to think of the content limitations of a CD as the limitations of an album in a production era that incorporates multi-disc, audio-dvd, and web-only releases as "albums".

Here's a better idea, expanding on what Craft posted above (Comment 11):

0. Banshee needs to cache artwork. In the library database there should be a flag for each file showing the artwork status: "folder" or "cached" or "search" with "search" as the default. Somewhere in the users' menu, manual switches for "folder" and "search" would make things friendly and easy.

1. Banshee should always check the artwork flag of individual files on play. *

2. If the flag is "search", Banshee should use the file's metadata or tags and a site like musicbrainz or lastfm to acquire artwork. Unfortunately, there will be times when this doesn't work (ie, no internet connection, an obscure album or a down site). While the flag is "search", local folder artwork will be used if available.

3a. If a directory has artwork and Banshee can not acquire artwork: Do not change the artwork flag for those files. (Continue search on next play)
Users can select "Use local Album Art" from the menu to keep this cover and save bandwidth in the future.

3b. If a directory has artwork, and Banshee can acquire artwork: Apply the cached artwork to all files in the directory with the same album metadata and set the artwork flag to "cached" for those files.
Users can select "Use local Album Art" in case they aren't satisfied with the cached version, or "Search for new Album Art" if they aren't satisfied with either.

3c. If a directory has no artwork, but Banshee can acquire artwork: Save the cached artwork as folder artwork, and set the artwork flag to "cached" for all files in the directory with the same album metadata.
Users can select "Search for new Album Art" if they aren't satisfied with this version, or "Use local Album Art" if they like it enough to keep it.

3d. If a directory has no artwork, and banshee can not acquire artwork: Do not change the artwork flag for those files. (Continue search on next play)


After careful consideration, and about ten revisions of this post, I realised: It is not necessary to distinguish multiple-album directories from single-album directories. If Banshee has a cache, using the local folder artwork as a fallback and giving users a few optional choices is significantly more simple than designing another algorithm. With Banshee getting most of the artwork from cache, one album in a multi-album folder could use the local artwork while the rest use cache or they could all use cache. 

* Actually, it could stop checking once the files are set to "local" or "cached" to save a few i/o cycles but I'm too sleepy to think of how to make that work.