Version: 2.4.0 (using KDE 4.6.0) OS: Linux When adding tracks via the 'Move to collection' feature, amarok will add AFT information as a url to the old file (i.e. before the renaming and moving to the collection directory) instead of a unique hash. This can cause problems with large paths, as the uniqueid column in the urls table is only 128 chars long, and thus can fail the INSERT query if tracks which have the same first 128 characters in their paths are being added to the collection. Reproducible: Always Steps to Reproduce: Add tracks with the 'move to folder' feature, then check the uniqueid column in the urls table of amarok's db. Actual Results: A value in the form of amarok-sqltrackuid://file:///path/to/track/before/adding/to/collection/cut/me/at/128/chars/track.mp3 Expected Results: A value such as amarok-sqltrackuid://b30f7b0ea771a044edc07f66984a45aa should appear in the uniqueid column. Manually removing the AFT data from the file and updating the collection seem to partially fix this problem. Tracks that were previously missing are in the db, but the AFT metadata is not rewritten to the file.
I have exactly the same problem. As a workaround I use the amarokcollectionscanner to find the files with malformed IDs (grep -A1 "<uniqueid>file") and then use amarok_afttagger to write new IDs into them. The problem with this is, that all statistics and labels of those files are lost in the process. This is manageable for new files, but I had to reset the IDs of a view older files, too and had to relabel them again.
The new collection scanner doesn't properly handle unique IDs and AFT in any sane fashion. If you like/rely on that functionality you should probably revert to 2.3.
Hi, that's not what's happening. Some linux taggers are adding the full path as a unique id to the file (which is a good ID because it's guaranteed to be unique) However 2.4 beta has a problem that it accepted all unique id tags and did not check the length of the ids. Both issues are fixed. Hagi, please check if you have 2.4 final. Last time I checked 2.4 final as tagged in git does not have this problem. It will only accept amarok and musicbrainz tags and verify the format of both (also the length) And Jeff, stop spreading FUD
(In reply to comment #3) > Hi, > that's not what's happening. > > Some linux taggers are adding the full path as a unique id to the file (which > is a good ID because it's guaranteed to be unique) That's a terrible "unique" ID. If they're not constantly updated with their current path values the moment that you access them, you can easily risk duplication. > However 2.4 beta has a problem that it accepted all unique id tags and did not > check the length of the ids. > Both issues are fixed. The poster stated that they are using 2.4.0. > And Jeff, > stop spreading FUD I don't think you know what that means.
(In reply to comment #3) > Hagi, > please check if you have 2.4 final. Last time I checked 2.4 final as tagged in > git does not have this problem. It will only accept amarok and musicbrainz tags > and verify the format of both (also the length) I too use 2.4.0 and this version definitely does write the file path as ID to the file. I'm not sure if it happens with the "Move to Collection" action (can't test it right now), but I could always reproduce the usage of the file path as ID upon tagging files in Amarok before adding them to the collection (using Amaroks file browser). The unique ID is written at the same time as the ID3 tags.
I just looked at the code and Hagi is right. We are really setting the file name as the uid internally. But only by chance. It happens when you use Amarok to move a file to the collection (via the file browser). I am just preparing a fix. For now you can use the amarok_afttagger to write the unique ids to the tracks.
Fixed by this commit: Git commit 4bc99da26f491ed2ae5c3a494abbaa2444813500 by Ralf Engels. Committed on 25/02/2011 at 18:48. Pushed by rengels into branch 'master'. Fix problem moving tracks from collections to SqlCollection