Created attachment 59995 [details] backtrace after first start of update (till no more updates are written) to debug output Version: 2.4-GIT (using KDE 4.6.2) OS: Linux updated to current git (May 13) and started amarok. After a few seconds i the progress bar for collection scan is shown and the ui does no more updates (so white screen in windowmanager decoration) - no change for 8h. After i killed and restart amark (when it starts fine) the collection was empty. After a full rescan everything seems to be back but no statistics (ratings gone) It might be related to #272061 or #258948 as i updated kde from 4.4 to 4.6.2 (gentoo) with change from hal to pure udev. Reproducible: Always Steps to Reproduce: restore old database start current git. Actual Results: amarok hangs after deleting some ids in db (see attachment debug_output.txt) after kill and restart collection is empty and rescan won't restore stats. Expected Results: amaroks starts and does necessary database updates (if any) without losing statistics. If any further data is needed (more stuff with debug symbols etc) let me know.
Created attachment 59996 [details] debug output the corresponding debug output
Ralf, could you please have a look at this?
Created attachment 61580 [details] some selected output of my database. I could fix my tables today by following the istructions on http://forum.kde.org/viewtopic.php?f=116&t=94868&p=195086#p195086 Although i deviated in the main SQL-statement by using UNIQUEID instead of RPATH as my RPATH also seemed to deviate (see example_of_db_diff.txt). As is still don't understand why this happened I'd like to know if this was introduced by some KDE change or by a update from amarok itself. Am i right that amarok relies on the directory,RPATH etc for statistics to have different statistics for the same file in different places? Or is the UNIQUEID actually used as single selector? Regards, simon
If possible we try to identify the file by it's UNIQUEID. Else we try to identify the file by it's known path. The problems start to happen if we do not correctly update the unique ids (or they get changed while Amarok is not running) and at the same time the files are moved. That can happen if you use an external tagging program to organize your collection. The unique ids are a hash over a couple of tags. Your tagging program will change them and afterwards move the files. I will try to fix the Amarok design with 2.4.3.
Ralf: is this still valid with Amarok 2.5?
Patch exists, see bug this is a duplicate of. *** This bug has been marked as a duplicate of bug 298275 ***