As in summary. To reproduce: 1. Clear "Album artist" tag in all tracks of an album ripped to wma. 2. Do full rescan. 3. Album is splitted into two in collection browser, some tracks and up in various artist, the rest under the artist - those have "Album artist" tag filled with "Artist" tag. Reproducible: Always
Actually it doesn't fill up anything. Amarok is using the track artist as album artist if it does not consider a track to be part of a compilation. Could you reformulate your complaint, e.g. Compilations (with empty album artist) are not detected. Can you also give examples of the afflicted albums.
(In reply to comment #1) > Actually it doesn't fill up anything. > Amarok is using the track artist as album artist if it does not consider a > track to be part of a compilation. > > Could you reformulate your complaint, e.g. > Compilations (with empty album artist) are not detected. The problem is, that this is not a compilation, so I guess the complaint is: Amarok incorrectly detects part of the album as a compilation? > Can you also give examples of the afflicted albums. It's this one http://musicbrainz.org/release/dfddb2cd-9e49-44b6-8a90-101707c35545
For me it seems that the album has only tracks with one artist. I fail to see how Amarok could get something wrong. You might attach the output of the amarok collection scanner for this directory.
Created attachment 76792 [details] amarokcollectionscanner console output
Attached.
Some of the tracks have the "compilation" flag and some don't. That's why Amarok is getting confused. Look at the <compilation/> Set it correctly and consistent for all the tracks and you should be good to go.
How can I remove those tags? Kid3 doesn't see those. Also, Amarok should set them correctly, when I mark an album not to show under various artists
(In reply to comment #7) > How can I remove those tags? Kid3 doesn't see those. Also, Amarok should set > them correctly, when I mark an album not to show under various artists Please don't change bug status and resolution once it is set by a developer. Once you mark an album "Don't show under Various Artists", it remains there even after a full rescan, right?
(In reply to comment #8) > Once you mark an album "Don't show under Various Artists", it remains there > even after a full rescan, right? Exactly.
Karaluh, that means that you are satisfied and as far as we both see the issue was caused by the inconsistent compilation flag of some of the tracks, right?
(In reply to comment #10) > Karaluh, > that means that you are satisfied and as far as we both see the issue was > caused by the inconsistent compilation flag of some of the tracks, right? No, that means I'm not satisfied, because I marked "Don't show under Various Artists" and this album is put in various artists every time full rescan is made. So the issue is not caused by inconsistent compilation flag.
In that case I need a new collection scanner output. Also make sure that the offending files are not write protected.
Created attachment 78779 [details] Another scaner output Files aren't write protected.
Track 7 still has <noCompilation/>, all the other tracks are in a compilation.
(In reply to comment #14) > Track 7 still has <noCompilation/>, all the other tracks are in a > compilation. Yes, I've seen that and that might be the Amarok bug. I clicked RMB on this album and choose "Don't show under Various Artists" from the context menu, yet not all tracks have the compilation flag removed.
The Compilation flag is not set by Amarok's Various Artist choice, but is a separate tag usually set by Musicbrainz/Picard. Use a tag editor to remove it.
(In reply to comment #16) > The Compilation flag is not set by Amarok's Various Artist choice, but is a > separate tag usually set by Musicbrainz/Picard. Use a tag editor to remove > it. I still believe it should be. Amarok is among other things a tag editor and this tag is pretty important. And as I already said Kid3 doesn't see this compilation tag. Which tag editor should I use?
Picard is the obvious choice as it is a Musicbrainz specific tag. And no, Amarok is not a full blown tag editor, this is a deliberate choice to avoid code blow and would make it even harder to maintain. There are enough powerful tag editors out there. @Devs: I though we wanted to avoid non-id3 tags, why do we use that one? AFAIK non-id3 tags only make things more complicated, not easier...
We are trying to avoid being the first to "invent" a new tag. However the "compilation" tag is already used by at least itunes. It's also mentioned in the standard (as non-standard itunes tag). Also, without that tag we are loosing the compilation information on every rescan. I think the correct title for the bug would be: "don't show under various artists does not set the <nocompilation> flag."
(In reply to comment #19) > We are trying to avoid being the first to "invent" a new tag. > However the "compilation" tag is already used by at least itunes. It's also > mentioned in the standard (as non-standard itunes tag). > > Also, without that tag we are loosing the compilation information on every > rescan. > > I think the correct title for the bug would be: "don't show under various > artists does not set the <nocompilation> flag." I agree completely.
*** Bug 318089 has been marked as a duplicate of this bug. ***
(In reply to comment #19) > We are trying to avoid being the first to "invent" a new tag. > However the "compilation" tag is already used by at least itunes. It's also > mentioned in the standard (as non-standard itunes tag). > > Also, without that tag we are loosing the compilation information on every > rescan. > > I think the correct title for the bug would be: "don't show under various > artists does not set the <nocompilation> flag." Ralf, do you think bug 318089 comment 6 would be a good approach to solve both problems?
(In reply to comment #22) > (In reply to comment #19) > > We are trying to avoid being the first to "invent" a new tag. > > However the "compilation" tag is already used by at least itunes. It's also > > mentioned in the standard (as non-standard itunes tag). > > > > Also, without that tag we are loosing the compilation information on every > > rescan. > > > > I think the correct title for the bug would be: "don't show under various > > artists does not set the <nocompilation> flag." > > Ralf, do you think bug 318089 comment 6 would be a good approach to solve > both problems? Sounds sane. I'm actually affected by both bugs. http://musicbrainz.org/release/7f7dc5db-2112-3641-b3fe-6825310cbda6 This album currently is shown under VA, but it should be shown under Air, which is set as "album artist". I would like to note though, that Matěj proposal would fix bug 318089, but only workaround this one. If Amarok depends on this non-standard tag, it should be able to set and unset the flag correctly.
(In reply to comment #23) > I would like to note though, that Matěj proposal would fix bug 318089, but > only workaround this one. If Amarok depends on this non-standard tag, it > should be able to set and unset the flag correctly. Please read the proposal again.
(In reply to comment #24) > (In reply to comment #23) > > I would like to note though, that Matěj proposal would fix bug 318089, but > > only workaround this one. If Amarok depends on this non-standard tag, it > > should be able to set and unset the flag correctly. > Please read the proposal again. I did and I still believe I'm right. If your proposal was implemented already, this album would be displayed correctly under "Hordak" (assuming I have <albumArtist> tag filled correctly for all files) but nine of the tracks would still have the <compilation/> tag. If in the future you decide to change "Various Artist" logic, or implement a feature that deals with compilations in some way this bug will reappear.
Matěj, your proposal inspired me and I noticed a mistake in our collection identification code. This is already fixed in git. However people should never have the problem once they select "show under various artists". This will add the compilation tag and everything should be all right from now on. At least it always worked for me, so I am at a loss why this does not seem to work here.
(In reply to comment #26) > Matěj, your proposal inspired me and I noticed a mistake in our collection > identification code. > This is already fixed in git. I don't know if the fix was reverted, but after upgrading to 2.8 the problematic album still keeps reappearing in VA after full rescans.
(In reply to comment #27) > (In reply to comment #26) > > Matěj, your proposal inspired me and I noticed a mistake in our collection > > identification code. > > This is already fixed in git. > > I don't know if the fix was reverted, but after upgrading to 2.8 the > problematic album still keeps reappearing in VA after full rescans. No, this was not yet fixed, at least from what I know. I wanted to look at this before 2.8, but it slipped to 2.9. :)
Bump version