Bug 105577

Summary:	scores disappear when moving file
Product:	[Applications] amarok	Reporter:	Adeodato Simó <dato>
Component:	general	Assignee:	Amarok Developers <amarok-bugs-dist>
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	frido.roose
Priority:	NOR
Version:	1.2.3
Target Milestone:	---
Platform:	Debian testing
OS:	Linux
Latest Commit:		Version Fixed In:

Description Adeodato Simó 2005-05-13 03:07:23 UTC

This is Debian Bug #308197 (http://bugs.debian.org), reported by Bas Zoetekouw 
<bas@debian.org>: 
 
-----------------------------------------------8<-------------------------- 
When a directory with mp3s is moved around on disk, the scores 
disappear. 
 
In my case, my mp3 collection is layed out like 
/mp3/<genre>/<artist - album>/track.mp3.  If I move an album from a 
genre dir to another, the scoring info is lost.,  This is of course 
undesirable 
-----------------------------------------------8<--------------------------

Comment 1 Vincent Panel 2005-07-11 17:34:35 UTC

Yes, I got the same phenomenon. Maybe you should identify a specific song by its (trm, album, artist, title) rather than its path. This would also fix another minor bug : I have the same songs several times at different places (copies) and they get different scoring which is not what I'd like. I copied them at another place to keep track of my most important songs.

Comment 2 der Graph 2005-07-31 18:51:47 UTC

This is not really a bug, but a misconception(?) of the DB. The information about all the tracks in the collection is stored relative to the file. As a result, amaroK deletes a track from the DB and adds a new one if you just change a character in the filename.

A possible sollution would be to store the scores in a new DB table indexed by artist, album, track# and title. But then you'd have the same problem if you change the tags (unless all tag changes are done with amaroK, and amaroK updates the DB on all changes).

I'm not too sure, but it seems like the scores and play counters are also reset if the file is tagged with another application, or if the file timestamp is altered. That would be very ennerving. But I'm not sure there.

Comment 3 Frido Roose 2005-08-14 22:31:06 UTC

It seems this bug is a duplicate for bug repots http://bugs.kde.org/show_bug.cgi?id=99791 and http://bugs.kde.org/show_bug.cgi?id=110774

As I suggested in my bug report (#110774), maybe it's a solution to work with a checksum of the file, like they do in the xmms-imms project.  This way, it's no problem to have the same file on multiple places, are to move them around.

Comment 4 der Graph 2005-08-17 18:24:32 UTC

You should add this statement to bug 99791, as this bug report will surely soon be closed as a duplicate. Therefore, I don't want to discuss the downsides of your concept here.

Comment 5 Alexandre Oliveira 2005-08-17 21:35:32 UTC

der Graph, thanks, it's really a dup of bug #99791.

*** This bug has been marked as a duplicate of 99791 ***