Version: 2.1.1 (using 4.2.2 (KDE 4.2.2), Kubuntu packages) Compiler: cc OS: Linux (x86_64) release 2.6.28-13-generic I'm sorry if this is a duplicate of https://bugs.kde.org/show_bug.cgi?id=192027 i couldn't determine it Amarok is giving a song an incorrect album after TagLib reads it correctly. I don'k know how often this happens but it happened in at least 1 song here is the relevant portion of amarokcollectionscanner <tags compilation="checkforvarious" title="Underneath It All" album="Rock Steady" artist="No Doubt" genre="Ska Reggae" audioproperties="true" track="5" comment="Hilikus" filesize="4395136" trackgain="-7.3" filetype="0" samplerate="44100" bitrate="116" path="/media/Jukebox/Singles/(No Doubt) - Underneath It All.mp3" length="302" uniqueid="amarok-sqltrackuid://09c2a3bbfd5951caeb8a5bf7d4db60db" year="2001" trackpeakgain="2.17644" /> <tags title="Underneath It All" compilation="checkforvarious" bitrate="256" uniqueid="amarok-sqltrackuid://585f8cbd169eafa70bbac714014aeb47" filetype="0" track="5" artist="No Doubt" path="/media/Jukebox/Albums/No Doubt/Rock Steady/05-Underneath It All.mp3" filesize="9977579" length="302" samplerate="44100" album="Rock Steady" comment="" genre="Rock" year="2001" audioproperties="true" /> So as you can see they both have the same album because it's the same song, just two different files but amarok shows the second one to be of a different album of a completely different artist here is what the DB shows Amarok.Collection.query("SELECT Album FROM tracks, urls WHERE urls.rpath='./media/Jukebox/Singles/(No Doubt) - Underneath It All.mp3' AND urls.id = tracks.url"); 143 Amarok.Collection.query("SELECT Album FROM tracks, urls WHERE urls.rpath='./media/Jukebox/Albums/No Doubt/Rock Steady/05-Underneath It All.mp3' AND urls.id = tracks.url"); 400 and just to show that the rest of the album in the same dir is correctly inserted into the DB, this is a different song of the same album as the incorrectly classified song Amarok.Collection.query("SELECT Album FROM tracks, urls WHERE urls.rpath='./media/Jukebox/Albums/No Doubt/Rock Steady/01-Intro.mp3' AND urls.id = tracks.url"); 143 The correct Album is 143. Album 400 is not even the same artist
*** Bug 199739 has been marked as a duplicate of this bug. ***
not sure if this could be already fixed in 2.2, maybe Jeff knows..
I believe this to be a duplicate of bug 178973. It should be fixed in current SVN, which I encourage you to try so that if it's not we don't release 2.2 with such an issue. Please note that that bug deals with *database* corruption. There are still some issues with the collection browser showing things incorrectly. A good metric is, if things don't look right, and you close Amarok and restart it and things look right again, then it's not related to that bug. *** This bug has been marked as a duplicate of bug 178793 ***
Gug 178973 != bug 178793. ;) (The link is correct, but the duplication mark points to the wrong bug) I can't try SVN (this is my main music player, and messing up anything even further than it already is would cause chaos here), but I can confirm this in 2.1.1. (I would post the following in bug 178973, which describes the problem in more detail, but that bug is closed) The problem, as described in 178973, is triggered when I do a collection rescan. However, the usual reason for this rescan is that some albums have randomly disappeared from my collection, *without* a rescan. This probably happened during an automatic update after adding new albums. Some albums that were in the collection simply don't show up anymore. The only fix seems to be doing a rescan, which often ends up mixing up the album tags as described above. As far as I can see, nobody else has reported missing albums in association with the tag mixup. I've encountered disappearing albums since at least minor releases in the 2.0.x series.
(In reply to comment #4) > As far as I can see, nobody else has reported missing albums in association > with the tag mixup. I've encountered disappearing albums since at least minor > releases in the 2.0.x series. Oh yes, this has been reported, and still happens to me in 2.2-SVN, at least it was still there last week when I had access to my collection (currently traveling). But it all has to do with the database problems mentioned by Jeff in comment #3 and we are well aware of the problem. Don't worry, we are working hard to solve this.
*** This bug has been marked as a duplicate of bug 178973 ***
As I stated in my previous comment, I believe this problem is fixed in 2.2-SVN. I don't begin to imagine why you think upgrading when we say there is a fix in for this specific problem will "mess it up even futher". But upgrade or not, it's your choice.
For the past few months, I've been constantly switching between 1.4 and 2.x on my Kubuntu box (I would be sticking to 1.4 still if it hadn't developed its own share of severe problems over the course of those switches). I'm simply afraid that fetching the SVN version and manually installing it (and perhaps additional libs, too, if required) will make it even more difficult to go back to 1.4 if 2.x causes too many problems. I'm not saying I don't believe this bug is fixed, but with a development snapshot, I obviously can't count on there not being any other show stoppers.
I don't see how switching between 1.4 and any 2.x version should affect each other. They have different configuration files and different databases. (And if not, you should be yelling at your distribution.)
I'm not saying it's the switching that caused 1.4 to get problems, most of it is due to incompatible libs. And I'd never complain here about the Ubuntu packages (even less so the inofficial ones for 1.4). I don't know if the mutual exclusivity between 1.4 and 2.x is entirely Ubuntu's fault, but the fact that no official 1.4 packages are available obviously is. This whole situation is simply the reason why I'm very wary to bring a self-built third version into the already problematic mix, since I don't know how easy it will be to cleanly revert to the regular packages if necessary. (I'm really beginning to feel like spamming this bug entry with off-topic stuff though)
Not really sure what to tell you. You'll have to make your own choice. It is true that from time to time SVN users go through additional pain that users of released versions do not. However, all the devs run SVN constantly, so there are generally very few major problems (and those tend to get fixed quickly). Features that may cause major issues are generally developed in separate Git branches.
Jeff was right i tested the latest svn 995042 and the songs that were causing the problem before are now correctly grouped under the same album cheers, Alejandro
I've been trying SVN rev. 995129 for the past few days, and this problem really seems to be solved. I even just now did a complete re-scan of my collection and everything seems fine. However, this latest re-scan was necessitated by an extreme version of the "disappearing albums" problem I mentioned above: When I started Amarok, there suddenly were only 57 of my 19,997 tracks left. The collection listed 6 artists, of which one didn't contain any albums or tracks at all. The artists seemed to be randomly chosen from the full collection. After the re-scan, all 19,997 tracks are available again.