This bug is tracking upstream bug https://bugs.kde.org/show_bug.cgi?id=265567 What I reconstructed: Amarok's unique ids for tracks are recomputed as soon as you update to kde-4.6. The reason is somewhere in the hal -> udisks move. So the ids come out differently after the upgrade and the statistics becomes invisible (but not deleted). All the statistics for my songs are still present in the mysql database (external in my case), but they are not associated with the songs, all songs got fresh ids and appear as new songs. Reproducible: Always
Same issue with Ubuntu; the user managed to solve it by manually joining mysql databases... http://forum.kde.org/viewtopic.php?f=116&t=94868&p=195086
(In reply to comment #1) > Same issue with Ubuntu; the user managed to solve it by manually joining mysql > databases... > > http://forum.kde.org/viewtopic.php?f=116&t=94868&p=195086 I see, but for this you need a backup of the database before you upgrade. What shall we do with the stabilization? The minimal requirement: The upgrade guide should state clearly that you must take a backup of your amarok-db before upgrading, point to the forum post, and tell people that there might be nasty manual hacks involved. Then it's still bad ... mee, amarok is doomed. What's all the stats good for if you lose it once a year :( I wonder if I could solve this problem by downgrading, running amarok, taking a backup, upgrading again and merging... I don't feel like trying to be honest.
(In reply to comment #2) > (In reply to comment #1) > > Same issue with Ubuntu; the user managed to solve it by manually joining mysql > > databases... > > > > http://forum.kde.org/viewtopic.php?f=116&t=94868&p=195086 > > I see, but for this you need a backup of the database before you upgrade. > > What shall we do with the stabilization? The minimal requirement: The upgrade > guide should state clearly that you must take a backup of your amarok-db before > upgrading, point to the forum post, and tell people that there might be nasty > manual hacks involved. Then it's still bad ... mee, amarok is doomed. What's > all the stats good for if you lose it once a year :( > > I wonder if I could solve this problem by downgrading, running amarok, taking a > backup, upgrading again and merging... I don't feel like trying to be honest. I just wonder how much software is actually affected by this problem, since "new UUIDS for the filesystem" is a rather low-level change. Anyway, paragraph added to upgrade guide, will be on the webservers in a few minutes.
Upstream knows about the issue and does not care. Basically there's nothing that we can do except inform people about the problem. :(
After reading through the upstream bug report I got the impression that the bug might have been fixed, but they completely fail to communicate what users should do to handle it. I did not have any important data in Amarok yet, so I choose to try out what another reported to work. Starting with my KDE 4.4 system I did: 1) add amarok to package.keywords. 2) Set use for amarok to -upnp for now, to not pull other packages not stable. 3) emerge -v1a amarok to upgrade only amarok to 2.4.1 4) Started amarok and see if all was intact. As far as I could tell it was. 5) As I like to be on the safe side, exit kde and enter fluxbox to not upgrade a running complex environment (kde). 5) Follow the kde 4.4 -> 4.6 upgrade guide (http://www.gentoo.org/proj/en/desktop/kde/kde44-46-upgrade.xml) 6) Enter KDE again and start amarok - Playing right now with statistics intact. So maybe this process should noted on the upgrade guide?
The database is fine directly after the update, but if you have activated permanent file system observation of your collection, it is wiped as soon as Amarok scans the disk for the first time in the new environment looking for changes. What actually helps is, if you deactivate the active directory scanning before the update. After the update you have to rescan your complete collection manually (in this case Amarok will match the stats and the files) and then you can activate the observation again. Would be a good elog warning for the update ... ;-)
