Version: (using KDE 4.3.2) OS: Linux Installed from: Ubuntu Packages In the collection I have, there are two albums with the same name and by the same artist. They are different versions (having different sets of tracks), however, and they have different album years. In the collection view, these two albums are merged into a single entry. I would expect them to appear as two separate entries, represented as "1998 - Foo" and "2002 - Foo".
Which exact Amarok version are you talking about? You should use Amarok 2.2.1, available in the Kubuntu backports PPA, do a full collection rescan, then restart Amarok.
Originally, I used 2.2.0. I tried it with 2.2.1 from backports PPA, no difference: the files are still merged into a single album. See attached screenshot: even though track details show different year (1998), the song is still merged into "1994 - Foo". Moreover, in 2.2.1 such album is marked as "Various Artists" for some reason, even though the artists are set to the same value. To reproduce: - Take any MP3 file, copy it to /tmp/a/1/1.mp3. Ensure it has all relevant tags set (artist, album, year, track name). - Copy /tmp/a/1/1.mp3 to /tmp/a/2/1.mp3 - Use any tool (e.g. EasyTag) to edit /tmp/a/2/1.mp3; change only the year - In Amarok, scan /tmp/a as the top of the collection. Regards, Alexey. On Sunday 29 November 2009 11:48:36 pm Myriam Schweingruber wrote: > https://bugs.kde.org/show_bug.cgi?id=216759 > > > Myriam Schweingruber <myriam@kde.org> changed: > > What |Removed |Added > --------------------------------------------------------------------------- > - Status|UNCONFIRMED |NEEDSINFO > Resolution| |WAITINGFORINFO > > > > > --- Comment #1 from Myriam Schweingruber <myriam kde org> 2009-11-30 > 08:48:35 --- Which exact Amarok version are you talking about? You should > use Amarok 2.2.1, available in the Kubuntu backports PPA, do a full > collection rescan, then restart Amarok. >
Ah, right. This is just not implemented yet. Similar wish: bug 194349
*** Bug 232988 has been marked as a duplicate of this bug. ***
First off, could this bug at least be marked as confirmed - now that there is a duplicate of it and it has been reproduced by Myriam? Also, this (or similar) bug happens with tracks inside an album. If there are two tracks with the same title within same album, they are "merged" - only one of them is displayed, tracking number is missing and the sort order of the rest of the tracks is broken. E.g., 3rd and 4th movements in Beethoven's 6th symphony are "Allegro". This is how Amarok displays it: 5 - Allegretto Allegro 1 - Allegro ma non troppo 2 - Andante molto moto Thus, I think it's a bug, not a "wish".
We do not confirm wishes.
Did you bother to read the comment past the first paragraph? I specifically explained why this is a bug, not a wish.
Moreover, it's not just a bug, but a regression from Amarok 1.4.x - see the bug 232988 (which is marked as a duplicate of this one).
Well, you don't understand: Amarok 2.x is a complete rewrite with a totally different codebase, there is no regression since you can't compare the two versions. It is not yet implemented in Amarok 2.x, hence it is a wish.
*** Bug 247498 has been marked as a duplicate of this bug. ***
1. Just tested it. Tracks with same album and name are not merged in my version (2.4) 2. Albums currently have a unique key which consists of the album name and artist. It would be a lot of work to change that. Unless some more people want this feature I propose that you just add a "(2002)" to one of the albums.
@Ralf: sorry for asking, but I fail to understand your test. You refer to "album" and "name", but the bug here refers to same album titles, but different year. Do you mean that in version 2.4 beta they are shown as different albums, discriminated by the year? Also, please take a look at Bug 247498: do you mean that in that case albums would each have their own entry?
Hi Leonardo, Maybe you know the concept of a unique identifier. That is value or a combination of values that uniquely identifies a database entry. In case of an Amarok album this unique identifier is the album name and the album artist (where in the case of a compilation the album artist can be empty). No year! The result is that Amarok can't discriminate by year. There is just no way that Amarok will understand that your two albums are in any way different.
Hello, Ralf. Indeed, that is why I said I failed to understand your test. Point 1 in your previous comment read: "Just tested it. Tracks with same album and name are not merged in my version (2.4)". If by "same album and name" you meant that tracks I showed in Bug 247498 wouldn't have been merged in the version you're currently using, then it would clash with point 2 and everything that goes with it, would it not? Since I'm on Debian Squeeze, I only wanted to clearly understand if the upcoming 2.4 would actually implement this feature (like you seemed to imply in point 1) or not (like the rest seemed to contradict). Your second comment, however, already dismisses the feasibility of this implementation. Regarding your last comment, in fact, unfortunately I'm not a developer, but I noticed an interesting feature missing, and asked for it to be implemented (as a mere wishlist). In fact, I clearly understood that *currently* Amarok cannot discriminate by year but only by artist/album name back when I submitted my bug report. However, from your e-mail address I can guess you probably are a developer, so I value your explanation. So, if what you are saying is that there is no way for Amarok to discriminate by year *at the moment*, then this situation was well known at least two years ago, and that is why this bug report still is open. Conversely, if what you are saying is that there is no way for Amarok to *ever* discriminate by year, then I cannot see a reason for this wishlist to stay open, and my guess is that you or someone else can safely close it. Many thanks!
This bug got even worse with Amarok 2.5.0. In 2.2.1, Amarok at least discriminated by artist's name - so it was possible to rename one of the albums. Now it apparently uses just the album name and merges albums of different artists. For example, ABBA had an album called "The Album". Also, Chris Norman also had an album by exactly same name. Amarok merges them together. But I guess, Myriam Schweingruber will say again that 2.5.0 was a complete rewrite and thus it cannot be considered a regression. Thanks for getting it worse.
Moving to bugs list. Can somebody actually confirm that with Amarok 2.5? I can't with current 2.5 git
Alexey, Amarok doesn't magically know if two directories with a couple of songs contain the same album or different albums. But, you should now be able to set "no compilation" on the album and Amarok will split the album up again and save the "no compilation" status in the id3 tags. Next time Amarok will not longer be confused. I think that should solve your problem.
First, why was it marked "RESOLVED/INVALID"? The original problem (merge of two albums with different years) still exists. It may be classified as a wish, but it is not resolved yet. As to the 2.5.0 getting worse, I did some additional investigation: Amarok 2.2.1 used the following heuristics (from a comment in amarok-2.2.1/src/collection/sqlcollection/ScanResultProcessor.cpp): //using the following heuristics: //if more than one album is in the dir, use the artist of each track as albumartist //if all tracks have the same artist, use it as albumartist //try to find the albumartist A: tracks must have the artist A or A feat. B (and variants) //if no albumartist could be found, it's a compilation However, more recent Amarok versions started to merge different albums with different artist in separate directories together, as explained above. Amarok started to assume all albums with same name to be compilations (even if in separate directories) since the following commit: dfd8b457d7094144563c51b2528afdbe23ffc344 Ralf Engels Fix all collection scanner auto tests. Now, amarok first scans all directories (sorting albums by the name) and then tries to process *album names*, one at a time. If it finds more than one instance of an album name, it assumes it to be a compilation. Thus, it lost the heuristics in employed before ("if more than one album is in the dir..."). While it is still possible to force the right behavior by selecting "Do not show under Various Artists" for each of the erroneous albums, it would still be better to restore the original heuristics as there may be lots of albums merged this way. The attached patch restores the following logic: If any given directory contains tracks that were sorted into a single album and and that album was not created as a compilation (i.e. it has non-empty artists), this album is excluded from being merged with other albums to create a "compilation".
Created attachment 69633 [details] Patch to restore 2.2.1 heuristics to decide whether albums should be merged
Just found a workaround to get same named albums with different year displayed as different albums in collection. Initially I took a look at the two albums in my collection that where affected by this bug a long time ago – Lurker of Chalice – Lurker of Chalice released in 2002 and 2005 and noticed that this time a last track from 2002 album is displayed under its own album while all other tracks are displayed under 2005 album. That last track had an Album Artist tag set to "Lurker Of Chalice" (with a capital O) while other tracks including ones in 2005 album had it set to "Lurker of Chalice". After changing the Album Artist for the rest of the tracks in 2002 album to "Lurker Of Chalice" with a capital O (and renaming the album directory with rescanning the collection twice as otherwise nothing will happen) all tracks are displayed under correct albums now. However, as the Album Artist tag differs from the Artist, each track name is now followed by artist name when this album is loaded into the playlist.
*** Bug 297215 has been marked as a duplicate of this bug. ***
Albums with same name are merged since 2.4.x despite different artist (or album artist) and the bug is still present in 2.5.0. I have ~10 such clashes and one of my favorite albums is affected by this annoying bug. The tags of the files are properly set, all files have artist and album artist set and running amarokcollectionscanner shows that the tags are properly read. However, when I look in amarok itself at the metadata of the affected albums' tracks, the album artist is missing. It gets only lost for those tracks that belong to such an ambiguous album name, the album artist is present in the metadata for tracks of albums with unique name.
So you say that the scanner re-writes the tags? That is very unlikely. How did you write these tags and did you check with another application like kid3 if those are indeed written?
No, I said the scanner detects the tags, but their not taken over into the metadata. The tags in the files are perfectly OK.
Just to make sure I understood correctly: Those tracks have the album artist tag set but it shows empty when you check the track details in Amarok. The tag is visible with other tagging software though. Did I understand correctly?
Correct. Even the output of amarokcollectionscanner shows that the tags are present. If I modify the tags of those tracks (e.g. adding a comment), Amarok updates those fields - except the album artist. Tracks of albums with unique names do not have this problem, Amarok has the album artist in its metadata.
Created attachment 70832 [details] output of amarokcollectionscanner for album R.E.M./Up
Created attachment 70833 [details] screenshot of metadata dialog of first track of album R.E.M./Up
So apparently the Collection browser doesn't read the album artist tag correctly.
I don't know the Amarok codebase, but it looks more like there is an postprocessing mechanism to identify albums that erases this information internally again, because for albums with unique names the info is complete.
Jörg, regarding the REM album. Are you sure that your collection has exactly those 12 tracks. The "postprocessing" that could happen might be another track that belongs to the same album but has the "compilation" flag set. This would automatically remove all album artists intranally (since Amarok considers a compilation to be an album with "various artists") You can also see in Amarok if this is the case. Do a right click on the Album in the collection. Look if you have "show under various artists" entry in the context menu.
If I run the collection scanner for the folder with the REM album only *then* I have only 14 tracks. It was just made to demonstrate, that the album artist is actually part of the scanner data, but it's never imported/integrated in the database resp. the field in the dialog box is always empty - even if I update the ID3 tag e.g. with a useless comment (which will be updated). If I run the scanner over all 17.000 tracks, I have also 10 more for Peter Gabriel's Up. Again, I've set the correct album artist for both and they get merged. This should not happen according to the trouble shooting section in the manual. All 14 files have only *one* IP3v2 (no IP3v1). However, you're right, the context menu has the "show under various artists" entry and if I select it, the tags for my files are rewritten to ID3v1 (obviously now without an album artist), but the albums are now separated in Amarok's collection view. Original tag info: ================= %< ================ $ id3v2 -l R.E.M/Up/01.\ Airportman.mp3 id3v2 tag info for R.E.M/Up/01. Airportman.mp3: TIT2 (Title/songname/content description): Airportman TPE1 (Lead performer(s)/Soloist(s)): R.E.M. TPE2 (Band/orchestra/accompaniment): R.E.M. TALB (Album/Movie/Show title): Up TYER (Year): 1998 TRCK (Track number/Position in set): 01 TCON (Content type): Rock (17) R.E.M/Up/01. Airportman.mp3: No ID3v1 tag ================= %< ================ after using Amarok's "show under various artists": ================= %< ================ $ id3v2 -l R.E.M/Up/01.\ Airportman.mp3 id3v1 tag info for R.E.M/Up/01. Airportman.mp3: Title : Airportman Artist: R.E.M. Album : Up Year: 1998, Genre: Rock (17) Comment: Track: 1 R.E.M/Up/01. Airportman.mp3: No ID3v2 tag ================= %< ================ Note, that I avoid to edit my tags with Amarok, since my hardware devices understand ID3v2.3 only and Amarok normally writes ID3v2.4. It's also strange why it's suddenly replaceing my ID3v2 tag with a ID3v1 tag here. After restoring my original files with the ID3v2.3 tags I can update the collection, but Amarok now keeps the tracks of the two albums separate. A look into the Amarok DB tables reveals that there are now 3 entries for an album named Up. Two of them have unique ids for the artist and one has 'null'. For other albums that get merged I have only one entry in the album table, always with artist 'null'. See, most of my tracks originally had no album artist info, but I've completed the tag when I recognized the new behavior since Amarok 2.4. What I cannot understand is, that even after updating the tags of all affected tracks and Amarok obviously reread the complete tag info, it does not recognize that there are now no longer any tracks belonging to an album of that name without an album artist. It assigns all those tracks (even after a reimport of the complete data) to the one existing album entry in the DB with the artist set to 'null'. You cannot get rid of it. I suppose in the meanwhile, that if I delete my Amarok tables completely, I would get a proper collection info, but then I would also loose all my ratings, stats and tag info.
Hi, I can explain some of Amaroks behaviour. We tried to give the best experience for most cases. Of course there can be some hitches. In your case it is around 1%. I will try to get it better. For now: Amarok is using the normal taglib tag writing. That will fall back to id3v1 in your example because it can represent all tags in this. Now the incorrectly merged albums: Amarok is trying to find out if an album is a compilation or not. It can't do this by the folder all the songs are located in (since e.g. ITunes will happily split up an album with several artists). So it's using a couple of heuristics. The down side is that one track with a slightly misspelled artist (or a compilation flag) will lead Amarok to the impression that it's a compilation. Since we only store the album artist in the album (and not per track) Amarok will no longer display a single album artist. Up till now no tag is written back. Your data is kept. My proposal, since you seem to use a stand-alone tagger, set the ID3V2 tag TCMP to 0 This will indicate to Amarok that the song is definitely not a compilation.
Hi Ralf, I think I understand the problem. But although I organize my albums in folders, I never talked about such a limit/relation here. What I expect is, that for all tracks in a collection which share the album name and which have an album artist, this album artist is actually used as separation. And it should not matter if someone rebuild the complete collection database or if the collection is simply updated. This new condition is currently simply ignored after an update, the tracks and albums in the DB tables are not properly corrected. If for some reason an album with no artist has been added to the album table, all tracks for an album with same name will be assigned to it no matter of an album artist tag. That tag should always represent an album separation. I can even imagine an album (e.g. "Greatest Hits") representing a collection and another one with an individual album artist. Thanks for your attention though, Jörg
Setting status correctly.
Hi Ralf, just one additional note concerning the proposed workaround with the TCMP tag: None of my ID3v2 clients knows about it (Easytag, Kid3, id3v2 --list-frames) nor can I find it in the description of the standard: http://id3.org/id3v2.4.0-frames
*** Bug 314049 has been marked as a duplicate of this bug. ***
I ran into the same problem using Amarok 2.7 and mostly flac files. E.g. I have "Symphonies - Harnoncourt" with several AlbumArtists: Beethoven, Haydn, Mozart, Schubert, Schumann, they are in different folders, they have all both Artist and AlbumArtist tags set. Amarok is set to group music on the first level according to AlbumArtist, nevertheless all files with album name "Symphonies - Harnoncourt" appear together under Various Artists. So, although I set that the first level of grouping should be AlbumArtist, Amarok ignores it, and groups the music according to Album. If I tell Amarok not to treat them as compilations, it adds a "Compilation" tag with value "0". But I think Amarok should be able to deal with this without adding tags to my music. (The program Clementine handles such files correctly.)
(In reply to comment #38) > I ran into the same problem using Amarok 2.7 and mostly flac files. > E.g. I have "Symphonies - Harnoncourt" with several AlbumArtists: Beethoven, > Haydn, Mozart, Schubert, Schumann, they are in different folders, they have > all both Artist and AlbumArtist tags set. Amarok is set to group music on > the first level according to AlbumArtist, nevertheless all files with album > name "Symphonies - Harnoncourt" appear together under Various Artists. > So, although I set that the first level of grouping should be AlbumArtist, > Amarok ignores it, and groups the music according to Album. > If I tell Amarok not to treat them as compilations, it adds a "Compilation" > tag with value "0". But I think Amarok should be able to deal with this > without adding tags to my music. (The program Clementine handles such files > correctly.) Just to be precise: those Albums have different album names in the id3 tags, don't they? Because if the album name is identical the behavior is absolutely normal, not a bug
(In reply to comment #39) > (In reply to comment #38) > > > > Just to be precise: those Albums have different album names in the id3 tags, > don't they? Because if the album name is identical the behavior is > absolutely normal, not a bug I am definitely with imruska on this; my experience is the same, and in my view it is definitely a bug. As noted elsewhere prior Amarok versions and forks behave in the way one would logically expect. To take a radical example, if a user had 50 albums by different artists, all called "Greatest Hits", these are 50 albums. They are not one big album by "Various Artists". Other players get this right by default, it would be great to see Amarok do likewise. Furthermore, imruska is even more right that Amarok is great for its flexibility, so if a user says "Sort by AlbumArtist", that is definitely what they expect.
Guys, just because tracks are in different folders does not mean that they are different albums. Itunes splits them up, as does every user that sorts their tracks by artist and then by album. The collection scanner cannot know this. I needs to guess. In your example with "Symphonies - Harnoncourt" Amarok guesses that this is one album with different artists -> a compilation. Compilations don't have album artists -> the compilation appears under various artists. Amarok has a special handling for "Greatest Hits". "Best Of", "Anthology" and some others. You might also want to read this: http://userbase.kde.org/Amarok/Manual/Organization/CollectionScanning/en#About_Albums
(In reply to comment #41) > > > You might also want to read this: > http://userbase.kde.org/Amarok/Manual/Organization/CollectionScanning/ > en#About_Albums Thanks Ralf, [and please don't take the comments as anything more than gratitude for the efforts of all involved and a desire to see improvement]. I agree completely about not relying on folder structure, so I am definitely talking about interpreting tags. I have just read the 'About Albums' section, and reading the bullets in order this describes EXACTLY what imruska and I are saying SHOULD happen. Specifically " Tracks that have the compilation flag set or an album artist other than "various artists" will be placed in an album. " Our tracks do have AlbumArtist other than various artist tagged, so we would expect them placed in an Album, where the key is AlbumArtist+AlbumName. This is not happening -they are being treated as leftovers. I don't know if it's of any import, but if I 'Edit Track Details' within Amarok for an afflicted track, the AlbumArtist is shown blank, despite amarokcollectionscanner -r reporting albumArtist=Electric Light Orchestra. I have also checked the tag with metaflac and kid3 and they look fine here. If I ask Amarok to sort just by AlbumArtist, the tracks are sorted under the correct AlbumArtist, so Amarok does seem to be reading the tag. I fortunately can't comment on iTunes, but Squeezebox Server and Google Play Music (my other current sources) both work the way we describe: I get separate albums for Daft Punk+Discovery and ELO+Discovery. Thanks, Alex
Alex, I once had the case where the album artists were misspelled. When all else fails, just tell Amarok "show under various artists". That will solve the issue once and for all.
> (In reply to comment #43) > When all else fails, just tell Amarok "show under various artists". That > will solve the issue once and for all. This is not an option for me, because it will rewrite the ID3 to a format my physical MP3 devices no longer understand. My comment #34 sums this up: Once the tracks have been collected, Amarok will bluntly ignore any update to the AlbumArtist. I simply expect, that Amarok fixes/updates its data in its DB also.
> just because tracks are in different folders does not mean that they are different albums. > Itunes splits them up, as does every user that sorts their tracks by artist and then by album. > The collection scanner cannot know this. I needs to guess. Yes, the collection scanner can know this, it doesn't need to guess. I set the AlbumArtist tag for the collection scanner to know these files do not belong to the same album. >Compilations don't have album artists -> the compilation appears under various artists. But I have album artist, so these are not compilations. As I mentioned other software (Clementine and foobar2000 definitely) know they are not compilations and they behave as I expect. >Amarok has a special handling for "Greatest Hits". "Best Of", "Anthology" and some others. This shows that Amarok developers realised that the way the collection scanning is implemented is faulty, so exceptions have been made. However, the perfect solution (the solution of other software) would be if not only the above album names were treated in a special way, but all albums where an album artist is explicitly specified. This is important in Classical music.
Created attachment 77262 [details] AGT Test Collection after initial scan Albums with same name but different AlbumArtist grouped under Various
Created attachment 77263 [details] AGT Test Collection having told Amarok to Do Not Show Under Various Artists Albums are no longer under various, but still have the same artwork, and note Listing as Dot Allison which is NOT the Albumartist Tag
Created attachment 77264 [details] AGT Test Collection amarokcollectionscanner output Note all tracks have AlbumArtist tagged
(In reply to comment #43) > Alex, > I once had the case where the album artists were misspelled. > > When all else fails, just tell Amarok "show under various artists". That > will solve the issue once and for all. Thanks Ralf. I have tested telling Amarok to Do Not Show Under Various Artists for albums with the same name: -it does split the two albums up -it still ignores the Albumartist tag, and instead lists the album under the ARTIST, not the AlbumArtist. -This means it is still ignoring the behavior claimed in the manual (I know this as I tag Artist=FirstName LastName, and AlbumArtist= LastName, FirstName . Also helps keep Elvis Costello & The Attractions together with Elvis Costello & The Imposters, as they both have AlbumArtist=Costello, Elvis.) I have attached screenshots before and after I have told Amarok to Do Not Show Under Various Artists, along with amarokcollectionscanner output, which appears to be seeing the AlbumArtist tag correctly. You will see that prior to setting COMPILATION the album pairs are clustered under Various, afterwards they are listed by ARTIST (Dot Allison should be under AlbumArtist of Allison, Dot), plus the artwork is incorrect. I agree with imruska that the perfect solution is to just respect the albumartist tag, as done by other software -and I could swear by Amarok previously (the author of the Random Album script includes a comment and code about the behavior, noting it fixed in 2.0 vs 1.4 see below) function getAlbum(aid) { var artists = Amarok.Collection.query(ALBUM_ARTIST_COUNT.format(aid)); var ulist; var tlist; /* * In amarok 1.4, if two artists had an album with the same name, * they'd share the same entry in the albums table. This seems to * have changed in 2.0, but the code below tries to protect against * that "just in case" (tm). */
(In reply to comment #47) > AGT Test Collection having told Amarok to Do Not Show Under Various Artists > Albums are no longer under various Yes, this is achieved by adding the flac files a tag named "COMPILATION" with value "0". I asked if this could be achieved without writing tags into my files.
(In reply to comment #50) > (In reply to comment #47) > > > Yes, this is achieved by adding the flac files a tag named "COMPILATION" > with value "0". > I asked if this could be achieved without writing tags into my files. ...which as you point out above would be unnecessary if Amarok just read your AlbumArtist tag properly in the first place ;-)
Git commit 0aeb1fafb3469d772b601441b29cdc5cb20d3589 by Ralf Engels. Committed on 28/02/2013 at 16:45. Pushed by rengels into branch 'master'. Fix: amarok erroneously merges two albums We are now keeping the information that an album artist is set until the very end. So albums with an album artist and only a guessed album artist are not merged. Also add auto test for "Amarok collection scanner not handle correctly cross-renaming" Related: bug 272802 FIXED-IN: 2.8 M +6 -0 shared/collectionscanner/Album.cpp M +1 -0 shared/collectionscanner/Album.h M +60 -65 src/core-impl/collections/db/ScanResultProcessor.cpp M +1 -3 src/core-impl/collections/db/ScanResultProcessor.h M +1 -1 src/core-impl/collections/db/sql/SqlScanResultProcessor.cpp M +113 -5 tests/core-impl/collections/db/sql/TestSqlScanManager.cpp M +15 -1 tests/core-impl/collections/db/sql/TestSqlScanManager.h http://commits.kde.org/amarok/0aeb1fafb3469d772b601441b29cdc5cb20d3589
Can also year be added for the criteria to distinguish albums?
(In reply to comment #53) > Can also year be added for the criteria to distinguish albums? That is already the case, regardless of this bug which has another origin. Please do not address support questions to the bug tracker, especially not to an already solved bug. Please use the forum at http://forum.kde.org/amarok or #amarok on irc.freenode.net for such questions.
(In reply to comment #54) > (In reply to comment #53) > > Can also year be added for the criteria to distinguish albums? > > That is already the case, regardless of this bug which has another origin. Checked with new version 2.8. Two different albums with different years and in different folders with same album title and same artist -> Amarok merges into single album. Seems, year not used to distinguish albums. So this bug is not fixed, please reopen it.
(In reply to comment #55) > (In reply to comment #54) > > (In reply to comment #53) > > > Can also year be added for the criteria to distinguish albums? > > > > That is already the case, regardless of this bug which has another origin. > > Checked with new version 2.8. Two different albums with different years and > in different folders with same album title and same artist -> Amarok merges > into single album. Seems, year not used to distinguish albums. > So this bug is not fixed, please reopen it. Could you please check that all tags are correct for all tracks in these albums (ideally with an external tagger like kid3 or easytag), do a full collection rescan and see if that helps? I can't reproduce this here at all.
Finally! After so many years my albums with same name and different album artist are separated again in 2.8 after rescanning the collection. YEAH! I cannot tell about Nikita's issue, but I have albums with songs from more than one year (e.g. typically for Best-Of-Albums). Since directories have no meaning for Amarok, I'd certainly do not want to have such an album splitted into several ones depending on the year in the tracks ...