I think the underlying bug is that an entry is made to the album database only for unique album titles. Two different albums that have the same name (most notably "Greatest Hits") reuse one album database record. For me, this manifests itself when I look at the total album count in my collection which is less than the actual album count. This lower count is the same number as entries in the album database.

Well this isn't a bug, but done by design, as Greg explained. The hash for each cover is "artist + album".

Well, if the hash for each cover were "artist + album", then there will be no problem, but I think the hash is actually "album" (remove "artist +").

Sorry for reopening the bug.

Mark, if the criteria for assigning covers to files is the hash produced from "artist + album", then "Queen + Greatest Hits"'s hash must be different to "Bob Seger + Greatest Hits"'s one, and this is not happening. If you say the hash is calculated only from "album", then the bug can be closed and I will open a new "wishlist" report.

Will this bug be fixed before Amarok 2 final release launch? 

@Victor: Unlikely, we already got our hands full with more important stuff. Very very busy times.

Not going to happen for 2.0, sorry.  This is not a new regression, and while it should be fixed, there is not enough time for everything.

Targetting it for down-the-road.

Hello.  I don't know if it is better to open a new bug for what I am experiencing but after reading this thread it seems that it is connected.
My problem is that I've got a collection of MP3's without Album tag set.  And when I try to set a cover for the file without such tag it is showed as some other cover in playlist (apparently last manually added cover for another track without album tag).  Though cover manger fetches and shows the right cover.  After learning that the hash for cover is only composed from the album tag I tried to remove cover from the track and fill in its album tag.  After this I fetched its cover again and saved it - now playlist shows the right cover.  Removing the cover and album tag and fetching cover again results in showing the wrong cover again.  I think it is not a correct behaviour.  
If there is no hope that it will be corrected soon, I'd try to do it myself.  Then please give me some guidance of where to look to implement the correct solution.

I'm just wondering why this bug is still marked as being 'unconfirmed'...

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

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

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

My experience is that this is a new bug in Amarok 2 :-) 

I have several albums called "Classics", Greatest Hits", "Best of" &c. In Amarok 1.4 all the covers were fine (here). But in Amarok 2.1 there is only one cover for each title.

Anyway, I guess it doesn't really matter whether the bug is old or new; it definitely exists.

Set target to 2.2

Changed importance to normal.

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

One month later... any news?

I haven't seen any resolution to this. I've seen various messages moving the status to "future release" or whatever. Did I miss a patch? I'd be happy to test something out.

-----Original Message-----
From: bugzilla_noreply@kde.org [mailto:bugzilla_noreply@kde.org]On
Behalf Of Myriam Schweingruber
Sent: Sunday, August 09, 2009 7:53 AM
To: iskimj@gmail.com
Subject: [Bug 170146] Albums with same title share cover (last added)


https://bugs.kde.org/show_bug.cgi?id=170146


Myriam Schweingruber <kde@pharma-traduction.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|2.0-SVN                     |2.2-GIT




--- Comment #17 from Myriam Schweingruber <kde pharma-traduction ch>  2009-08-09 15:53:03 ---
One month later... any news?

(In reply to comment #18)
> I haven't seen any resolution to this. I've seen various messages moving the
> status to "future release" or whatever. Did I miss a patch? I'd be happy to
> test something out.

Greg, I am also waiting for the developers to get into that, they are just very busy

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

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

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

So are you saying that the file names of the album covers are md5sums of the album title preceded by the dimensions of the image?

(In reply to comment #23)
> So are you saying that the file names of the album covers are md5sums of the
> album title preceded by the dimensions of the image?

Mark, whom are you talking to?

commit 4b2abed2810ec849ddb6ef80616e4e7fc44a778a
Author: Rick W. Chen <stuffcorpse@archlinux.us>
Date:   Fri Mar 19 17:09:34 2010 +1300

    meta: album: use image location as primary key for bordered pixmap cache
    
    BUG: 170146
    
    The name of the album can be ambiguous, especially for compilations such
    as "Greatest Hits", "Best of" etc. This causes the bordered pixmap cache
    to store only the first album's cover, and subsequent albums with the
    same name trying to retrieve their covers from the cache will use that
    for display. The name is now a fallback if location is empty.

diff --git a/ChangeLog b/ChangeLog
index e4c868b..7363350 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -36,6 +36,8 @@ VERSION 2.3.1-Beta 1
        some MySQL versions. (BR 225052)
 
   BUGFIXES:
+     * Fixed incorrectly displayed cover images for albums with the same name,
+       e.g. "Greatest Hits". (BR 170146)
      * Fix permission errors happening for each file copied to an iPhone via ifuse.
        Thank you to Colin Guthrie <cguthrie@mandriva.org> for the patch. (BR 231021)
      * Fix issues with using random navigators while filetering or searching The
diff --git a/src/meta/Meta.cpp b/src/meta/Meta.cpp
index 44bc626..b58296c 100644
--- a/src/meta/Meta.cpp
+++ b/src/meta/Meta.cpp
@@ -451,9 +451,10 @@ QPixmap
 Meta::Album::imageWithBorder( int size, int borderWidth )
 {
     const int imageSize = size - ( borderWidth * 2 );
+    const QString loc   = imageLocation( imageSize ).url();
+    const QString key   = !loc.isEmpty() ? loc : name();
     const QPixmap cover = image( imageSize );
-    const QString &nameForKey = name();
-    return The::svgHandler()->addBordersToPixmap( cover, borderWidth, nameForKey );
+    return The::svgHandler()->addBordersToPixmap( cover, borderWidth, key );
 }