Forgot to say: Version is 1.3.6 from Debian unstable package

So to be clear, you only have one "Worthless" file but it appears twice?

Yes. Dido's "Worthless" actually belongs to the Cafe del Mar compilation, which is marked as such and can be found under "Various" in the collection browser. I checked for the other songs in this compilation, they can't be found elsewhere. But as I said, Dido is the only artist, that is on Cafe del Mar and is present with another album on my hard disk.
Btw. there are a few more examples here, where the same happens. I have quite a big mp3 collection containing many compilations and albums. Whenever there is an artist which contributed to a compilation and has songs outside this compilation, the song of the compilation gets added also to the artist's name in the collection browser (under artist name -> compilation name; btw., i'm using the tree view with artist name on the first level and album name on the second). So they always appear twice.

I also see this, using amarok 1.4-beta2 (built from the tarball on amarok.kde.org) under KDE 3.5.2 (built using konstruct on Debian Sarge).  I'm attaching a screenshot to illustrate the error.

Created attachment 15488 [details]
Screenshot of compilation bug

I created a small collection to illustrate the point.  There are two top-level
folders in this collection: "Meat Beat Manifesto" and "Nine Inch Nails".  MBM's
album "99%" is in the Meat Beat Manifesto folder, and NIN's "The Perfect Drug
Versions" is in the Nine Inch Nails folder.  "The Perfect Drug Versions" is
auto-recognized as a compilation containing tracks by Meat Beat Manifesto,
Plug, Nine Inch Nails, Spacetime Continuum, and The Orb.  I have no stand-alone
albums by Plug, Nine Inch Nails, Spacetime Continuum, or The Orb in the
collection.

Fixed in SVN version 552135

Changed again in SVN 552311.

Compilations will be shown under both the artists concerned and Various Artists.

But also, the bug is fixed where if you had no non-compilation albums by an artist, they would not show up, even if you did have compilations with them on

 Andrew,

its little complicated to understand it all, but is it allright after your commit, that:

1) lets have album X which contain 20 songs from 20 different artists

2) lets have not any other song from any of 20 artists above

3) marking that album as compilation - album will appear in "Various Artists" + we will have also in collection grouped by Interpret/Album 20 artists, each with one song

4) unmarking as compilation - that album dissapear from "Various Artists" and we will have only 20 artists in collection, each with one song

Result: in this situation, marking and unmarking as compilation lead only to one difference - if album is presented in VA or isnt.

Can you imagine, if somebody have 15 compilation albums, what mess collection became?

radfoj, I completly agree... I have only a few of compilations, but my collection is an absolute mess new. Now there are not 20 artist, but about 100 with only one song each. Please change that, it's an horror...

> Yes please, makes me terribly unhappy as well.


Okay, let's be constructive instead. This is my opinion about the issue:

- the implementation in 1.4.0 was IMHO a very good one: given song S by
  artist A in compilation album B, always include it under "Various
  Artists", and show it again under "Artist A" __if and only if__ artist
  A has more songs in the collection which do not belong to a
  compilation album.

- the reason this is a very good implementation is that manages not to
  clutter the artist listing in the collection with "probably
  uninteresting" artists (IOW who one only knows through compilations),
  but (very importantly) at the same time helping the user notice that
  artist A, which they like, happens to have a song in compilation
  "Beatles versioned".

- given the reasoning above, it is my understanding that the bug, as
  explained by the submitter, is not a bug but a feature, one of those
  details that makes amaroK better than others, if you ask me.

- if the developers can't view the above as a feature and only as a bug,
  please consider not giving authors without non-compilation songs their
  own entry in the collection, in order not to clutter it.

Thanks in advance.

I also accepted this "bug" as an actual feature now. The behavior as ist was, is in my opinion now, the right one. Thus, I fully agree to comment #10. I should also emphasize that it is indeed not a good idea to add every single artist of the compilations to the collection. This would render the possibilty to mark albums as compilations pretty much useless (and I should say, that this bug report was NEVER aimed at supporting this way of managing the compilation.)
Hence, we should just revert to the initial behavior. It was just good and far better than anything else I've seen with other audio players.

I'll reopen this bug as we now want the old behavior back :-) (From the postings here I understand that there have been some changes in the wrong direction already). I don't use any cvs-version of amarok though, just the stable versions, so I can't confirm this. I just installed amarok 1.4.1 and everything is still as it was.

I would like to confirm this bug (I see it as one) for the Ubuntu Dapper package of 1.4.1-0ubuntu1.
The collection became a complete mess because each artist in a compilation now got its own entry in the collection browser even if he is only on compilation albums.

The former behavior was perfect (artist entry only if he also had non-compilation albums), please revert.

SVN commit 558731 by seb:

Don't show compilations under individual artists.  I think we have reached consensus that this is both the most popular and most natural way of displaying the data
BUG: 116127


 M  +7 -1      collectionbrowser.cpp  


--- trunk/extragear/multimedia/amarok/src/collectionbrowser.cpp #558730:558731
@@ -673,6 +673,9 @@
         qb.sortBy( q_cat1, QueryBuilder::valName );
         qb.setOptions( QueryBuilder::optRemoveDuplicates );
 
+        if( q_cat1 == QueryBuilder::tabArtist )
+            qb.setOptions( QueryBuilder::optNoCompilations );
+
         // ensure we don't get empty genres/albums/etc due to tag changes
         qb.addFilter( QueryBuilder::tabSong, QString::null );
 
@@ -939,6 +942,7 @@
             isUnknown = tmptext.isEmpty();
             if ( !static_cast<CollectionItem*>( item )->isSampler() )
             {
+                qb.setOptions( QueryBuilder::optNoCompilations );
                 if( VisYearAlbum == 1 )
                 {
                     tmptext = item->text( 0 );
@@ -996,6 +1000,7 @@
 
             if( !static_cast<CollectionItem*>( item->parent() )->isSampler() )
             {
+                qb.setOptions( QueryBuilder::optNoCompilations );
                 if( VisYearAlbum == 1 )
                 {
                     tmptext = item->parent()->text( 0 );
@@ -1068,7 +1073,8 @@
 
             if ( !static_cast<CollectionItem*>( item->parent()->parent() )->isSampler() )
             {
-                if (VisYearAlbum==1)
+                qb.setOptions( QueryBuilder::optNoCompilations );
+                if( VisYearAlbum == 1 )
                 {
                     tmptext = item->parent()->parent()->text( 0 );
                     QString year = tmptext.left( tmptext.find( i18n(" - ") ) );

* Seb Ruiz [Wed, 05 Jul 2006 22:14:02 -0000]:

> Don't show compilations under individual artists.  I think we have
> reached consensus that this is both the most popular and most natural
> way of displaying the data


I think the complains were all about this bit:

> +        if( q_cat1 == QueryBuilder::tabArtist )
> +            qb.setOptions( QueryBuilder::optNoCompilations );
> +


So thanks for reverting it. But not about these:

> +                qb.setOptions( QueryBuilder::optNoCompilations );
> +                qb.setOptions( QueryBuilder::optNoCompilations );
> +                qb.setOptions( QueryBuilder::optNoCompilations );


Thanks,

I liked the old behaviour (every song which appears under Various Artists also appears somewhere else (under the artist's name) in the collection browser) the best.
The reason why I don't like the new behaviour:
When looking for a song by artist XXX, I now first have to look whether there is  a "XXX" entry in the collection browser. If not, I additionally have to look under "Various Artists". I now have to look at to places instead of one to see wheter I have a song by XXX.

However, I also understand the concerns about the collection browser getting cluttered.

IMHO the best solution would be to make this behaviour configureable:
	Option 1: Show compilation songs both under
		  "Various Artists" and under the respective artist.
	Option 2: Show compilation songs only under the 
		  respective artist if there are other, non-compilation songs
		  by that artist. Also show all compilation songs under 
		  "Various Artists"
	Option 3: Show compilation songs only under "Various Artists"

What "Option" is used right now? I really hope it is not Option 3...

It is Option 3.
While I would prefer Option 2 (we had this behavior before), while Option 3 is still OK.

In my option it is not option 3, it is option 1 ;-)

My collection includes about 58000 files, which are from 1360 albums (including 250 compilations) and a bunch of single files.

I'm often digging through the collection, look at an artist, and see which songs of that there are in the collection. There are also some duplicate songs, or different versions of one song, e.g. on a compilation and on a special album from that artist. If all the tracks from the compilations are also listed under the individual artists this is more clearly arranged for me than if I had to look under the artist entry, and additionally in the compilations section.

Since others on this topic disagree with my opinion I'd really appreciate if this would be made configurable, either in
Settings->Configure Amarok->Collection
or "on the fly" in the upper left corner of the collection browser.
It could be implemented either using 2 checkboxes, or a selection box which offers the 3 options as listed above.

The code should not be too hard to implement in either way, but every user could have it the way he prefers.

Martin