Bug 258948

Summary:	Statistics lost after file replaced even though AFT UUID tag is kept
Product:	[Applications] amarok	Reporter:	Benedikt Waldvogel <kde-bugzilla>
Component:	Collections/Local	Assignee:	Amarok Developers <amarok-bugs-dist>
Status:	RESOLVED FIXED
Severity:	normal	CC:	mitchell, ralf-engels
Priority:	NOR
Version:	2.4-GIT
Target Milestone:	2.4.0
Platform:	Compiled Sources
OS:	Linux
Latest Commit:		Version Fixed In:	2.4.1
Sentry Crash Report:

Description Benedikt Waldvogel 2010-12-05 22:44:51 UTC

Version:           2.4-GIT (using KDE 4.4.5) 
OS:                Linux

The statistics (e.g. playcount, rating) are lost if a track is replaced by a different version (eg. MP3→FLAC) even if the AFT UUID tag and Musicbrainz ID was copied.

From time to time I replace MP3 albums by a FLAC version. Jeff Mitchell helped me to find a solution to keep the statistics. I've even written a blog post about it: http://blog.foosion.org/2009/07/29/what-the-flac-a-journey-from-mp3-to-flac/

This worked pretty well until recently.

Reproducible: Always

Steps to Reproduce:
See my blog post.

1) Use amarok_afttagger to embed identifiers into your MP3s.
2) Make sure that those files are scanned into Amarok (full rescan), so the UIDs in the tags overwrite the ones that were auto-generated before.
3) Use a script to transfer the identifiers into the FLACs.
4) Remove the MP3s from Amarok’s collection, add the FLACs, and do a full rescan.

Actual Results:  
statistics are lost (eg. playcount is 0)

Expected Results:  
playcount, rating etc. should be kept as before

I just started a git bisect to find the commit that breaks this feature.

Comment 1 Ralf Engels 2010-12-06 12:07:26 UTC

Hi,
I would guess that the musicbrainz uid might be the reason why this fails now.
Since two months Amarok is writing and reading Musicbrainz uids. Those take precedence over the amarok ids. 

Now if your new file contains both, then it will look for Amarok as if they were new files.

If you don't need the musicbrainz ids, then you could try to strip them from the files.

Comment 2 Benedikt Waldvogel 2010-12-06 21:55:06 UTC

Here's the bisect result:

79de13028d802611ff8bd78fa3dd4792929a986e is the first bad commit
commit 79de13028d802611ff8bd78fa3dd4792929a986e
Author: Ralf Engels <ralf-engels@gmx.de>
Date:   Wed Nov 3 01:25:45 2010 +0100

    Collectionscanner patch squashed


What is a workaround to keep the statistics? I don't want to strip the musicbrainz ids. If I remove all AFT uids and did a full rescan, would that do the trick?

Comment 3 Ralf Engels 2010-12-07 12:55:24 UTC

I discussed this yesterday with Jeff.
Musicbrainz IDs were read since quite a long time, however one of my changes removed the implicit preference of Amarok IDs over Musicbrainz tags.

Also the Musicbrainz tagging changes removed the implicit preference of Amarok IDs over Musicbrainz in the database.

I will restore the first issue. The second needs some further thinking.

Comment 4 Benedikt Waldvogel 2011-01-07 20:38:12 UTC

Unfortunately, I still have a "broken" behavior with the latest version from git.

Comment 5 Benedikt Waldvogel 2011-03-03 23:14:23 UTC

Ralf, any news for this ticket? I'm still able to reproduce the bug with the latest version from git.

Comment 6 Ralf Engels 2011-03-28 20:24:31 UTC

Two issues caused this problem:

1. the original files did not have AFT tags at all. Instead they hat musicbrainz tags. Using the afttagger solves this.

2. the input components did not prioritze the AFT tags (again)
bba5d6c73b1675742f3f5530fcb78c6e3bc4efc8 fixes this.

Bugfix is verified by Benedikt