Once again, Amarok has lost all metadata about a ton of songs in my collection.

Now, admittedly, I have spent time using an external tagging program to update genre tags in my collection, so technically the files have been touched, but following advice found on the forums, I made sure not to change any file names. I also didn't edit any other fields, such as artist, title etc.

All my edits were restricted to one of the top-level directories of my physical collection. The only changes in the other directories were additions of some newly ripped material.

As it happened, I had recently made a play list consisting of a couple thousand songs rated 3 stars or better. By loading this play list after rescanning my collection, I could conclude that 1/3 of the songs in this playlist had had their metadata go missing, and now show up with a zero rating, zero play count and last played 'never'.

I could also conclude that a lot of the songs now missing their metadata were not in the top-level directory I had been fiddling with genre-tags for.

So, as I've become somewhat accustomed to Amarok hanging while rescanning my collection and losing metadata that way, I had taken the precaution of copying the .kde/share/apps/amarok catalog before I started fiddling with the files. So I restored the old copy, but now Amarok got stuck at 100% on rescanning the collection, and after waiting an hour, I killed the process. Massive losses of metadata, of course.

So, I restore the .kde/share/apps/amarok catalog again, and retry. Hung again at 100%. So, restore once more, and now rescan top-level directory by directory. No hang, but after restarting Amarok, I still have the metadata losses I had initially.

I like a lot about Amarok, but I'm getting very frustrated with the way I keep losing my metadata. Having my ratings, scores, play counts, last played etc and being able to leverage them is one of the main reasons I use Amarok, so this really is a big issue for me.

I've tried to follow the advice I've found about how to work around the (in my experience, many) ways that Amarok can lose track of its collection, but I guess I'm just not succeeding. This despite always being careful not to change tags and file names/paths without rescanning the collection in between.

Plus, 98% of my collection is tagged using Picard, so have the MusicBrainz track identifiers embedded. Indeed, all files I modified today were files that were previously successfully identified, mapped to albums and tagged by Picard.

(I'm running 2.3.2 and KDE 4.4.5.)

Hi rocketsurgeon,
I am very sorry that Amarok lost your meta data.

The thing is that Amarok currently does not write back playcounts or ratings to the file.
When a rescan is done it will try to identify the tracks by a unique id computed from the meta tags.

So this is what can happen:
1. you change the tags from outside Amarok.
2. You rescan the collection and (because of the changed tags) Amarok thinks that it just found a whole batch of new songs. Expecially if you move them around in addition.

Now this is all quite stupid and very inconvinient.
It is also very bad if you want to keep your ratings while moving the songs from one computer to another.
Also the collection scanner was not that smart, e.g. it completely ignore embedded covers (now fixed in the current stable release), if it found one cover than it assigned it to all files in the directory and so on.

During the last two months I have rewritten a lot of this and the patch is almost ready to be integrated.
After that your problems should be a thing of the past.

For now I recommend to backup the amarok database directories before doing large changes to your collection. They can be found under ~/.kde/share/apps/amarok/mysqle

rengels wrote:So this is what can happen:
1. you change the tags from outside Amarok.
2. You rescan the collection and (because of the changed tags) Amarok thinks that it just found a whole batch of new songs. Expecially if you move them around in addition.

Yes, I'm always very careful not to move/rename files when I change their tags, and vice versa. This time around, I'm positive that not only were files that had only its tags modified stripped of their metadata, I lost metadata even for files thar were neither moved nor modified.

rengels wrote:For now I recommend to backup the amarok database directories before doing large changes to your collection. They can be found under ~/.kde/share/apps/amarok/mysqle

I did this, but restoring the backup and rescanning doesn't seem to work. If I do partial rescans it consistently loses data for a large subset of the files. Doing a full rescan ends up with Amarok hanging indefinitely after hitting 100%, not updating the screen, not responding, nothing. I have to force quit or kill the process even to get rid of the program.

So I tried running 'amarok -d', to get something to post in the bug report, but then it doesn't hang, yet I still have large, but smaller, losses of metadata. Which I supposed I'll have to settle for.

Glad to hear you're working on this, and that an improvement is in the pipeline. I'm sure I won't be the only user appreciating this.

Checking back on your issue.

During the last weeks several scanner related issues were fixed.
Specifically for your problem:
Long commit time with collections larger than 30000 files.
MusicBrainz ids prefered over Amarok ids
Several other cases where the scanner just stopped.

It would be nice if you could retest that.

I've tried to build Amarok myself, but not been able to, so I'm dependent on Fedora (13) binaries becoming available for me to test.

Checking Koji, binaries were built for Fedora 15 (which isn't even in alpha yet) earlier this week, but nothing beyond 2.3.2 is currently available for F13 (or F14).

have you tried this post for compiling ? http://blogs.fsfe.org/myriam/2009/09/co ... l-summary/

google01103 wrote:have you tried this post for compiling ? http://blogs.fsfe.org/myriam/2009/09/co ... l-summary/

I've tried installing the source RPMs and building that way, and tried following that post, but I crashed and burned both ways.

I experienced the same problem as the OP: recently Amarok wiped out the ratings for hundreds of my songs. The problem is that I didn't actually notice this for several days, and in the meantime had rated dozens more songs. I didn't want to lose all the work I'd done both pre- and post-metadata loss, so I discovered that another user had developed a technique for merging ratings from two Amarok databases. I used this technique to merge in the deleted ratings from a backup of my Amarok database I had made a few weeks ago.

I have the exact same issue, on Squeeze.

I did notice though there is an option under 'configure amarok' that allows you to use a MySQL DB instead. I am going to try that to see if the MySQL DB keeps the data, and is easier to backup & restore.

I will let you guys know what happens

[EDIT]
I just found another posting here http://www.pclinuxos.com/forum/index.ph ... #msg646471 the user writes:

I think the problem comes up when I open Amarok while the external partitions are not mounted as they are not set up for auto-mount. Even after mounting the drives with Amarok open it won't find the collection on rescan.
A small bug, not critical by any means but a little annoying.

Oh and I made an auto-mount script and put it in /etc/init.d I will paste it if it works and helps keep my collection in tact
[/EDIT]

Amarok's internal database is MySQL. The external database option is provided solely for sharing a database between multiple computers; there is no functional difference. You can back up the internal MySQL database, which is stored in ~/.kde/share/apps/amarok/mysqle, and launch a regular MySQL daemon on it, should you wish.


/etc/fstab is where you should put drives you want automounted.



Also, unless you're using the backports repository, the version in Squeeze is 2.3.1, which is ancient.