Hi, if I understand correctly, it's best not to use an external program to move or rename music files, as Amarok will lose its metadata (e.g. playcount). So, I should move/rename files from within Amarok.

1) Is it possible to move individual files? I noticed a typo in the title of a track, so I wish to rename the corresponding file.

2) I had a look at the bulk "organize tracks" function. I set up the filing format to be consistent to my existing scheme, so that only incorrectly-named files would be moved. Unfortunately, Amarok complained that "There is a filename conflict, existing files will not be changed." for many files (that should be a semicolon, not a comma, but anyway. ). This seemed to occur for all files whose filename would be unchanged. Does this mean Amarok is not useful for maintenance of music libraries, but only the initial categorisation?

3) In an attempt to sidestep this problem, I thought I could move my library from ~/Music/Library/ to ~/Music/Collection. This would also have the added advantage of me being able to see if there were any tracks that Amarok was unaware of. I could use the regex replace to replace "\/Library\/" with "/Collection/", but I was fearful that Amarok would get confused and lose all my metadata, since my Collection folder would be temporarily undefined. Similarly, this workaround is not good for maintenance of music libraries, only the initial categorisation.

Kubuntu 13.10
KDE 4.11.2
Amarok 2.8.0

Just renaming a file you don't need Amarok for, you can do that in Dolphin as well, it should not affect the metadata. If you store the playcount in the id3 tags this should not get lost.

Please check that first. Then if you only want to rename tracks, you shouldn't use the Organize function, doing this is a mass-tagger like kid3 or easytag is certainly better suited. The Organize function is when you want to change the physical location of tracks mostly.

Ah yes, sorry. I should have mentioned that I don't save playcounts in the files' id3 metadata, because that would increase the time it takes for my incremental (rsync-based) backups.

Backups run in the background, why do you care? Mine runs in the middle of the night when I sleep, so time of a backup is really irrelevant.

What filename-scheme do you use?

Mamarok wrote:Backups run in the background, why do you care? Mine runs in the middle of the night when I sleep, so time of a backup is really irrelevant.

My laptop is off overnight, so it's runs when I get home from work. Also, my off-site backups at work run onto an LUKS-encrypted partition hosted on a network drive via wifi. As is, it takes about 3–5 hours for an incremental backup. Finally, I use backintime, which (like some other backup programs) saves previous images of the filesystem as well. If files don't differ between images, then hardlinks mean that they don't take up any more room. If they do, then the new file is copied. This would mean that every time I listen to a track, an additional copy would reside on the backup media, reducing the amount of images I could keep.

Mamarok wrote:What filename-scheme do you use?

<album_artist>/<album_title>/<track_number> <track_name>.<extension>
<track_number> is actually always two digits. Amarok doesn't let you define this, but I'm not that fussed about it.

Bump. I'm still looking for a way to move music files without losing centrally-stored Amarok metadata.

I'm thinking about recoding some of my music library from mp3 to ogg.

I had a bit more of a look, and it seems like the config file at `~/.kde4/share/apps/amarok/mysqle/amarok/urls.MYD` might be relevant. However I don't really want to start changing it by hand and messing up the database as a whole. There's also `urls.MYI` too, which may be relevant.

Another possible lead is "Synchronise Statistics", which appears to match tracks by "Title, Artist, Album, Composer, Year, Track Number, Disc Number", and notably, not path. I couldn't find any kind of direct "export/import statistics" function.

Did you try the latest git master version? There has been quite some work since 2.8.0

Mamarok wrote:Did you try the latest git master version? There has been quite some work since 2.8.0

No, I didn't, but unless I know specifically that this feature has been added, I'm a bit loathe to test it out until it's out as a stable release.

TBH, current 2.8.90 is way more stable than 2.8.0 has ever been, so there is strictly no risk in trying.

Hmm… okay… that makes it more tempting. Do you know if it's a one-way upgrade? i.e. are the irreversible changes made to the database/settings, or can I revert if needed? I guess I could just back up the database and settings from somewhere?

You should definitely backup your database before updating, as there were changes made to the database handling. I don't think you can just revert back once these changes are made, but since those are improvements and bugfixes, there really is no reason to downgrade. So far I have not heard of things going wrong with an upgrade to 2.8.90, quite the contrary.