Acoustids not transferring to targets in recording merges

acoustid
recording
merging
recordingmerge
Tags: #<Tag:0x00007f6d79b60e98> #<Tag:0x00007f6d79b60d08> #<Tag:0x00007f6d79b60b28> #<Tag:0x00007f6d79b608d0>
#1

if you have a recording merge, any acoustids found in any of the source recordings but not in the target will be lost once the edit applies. they do not get transferred to the target.

say, if you keep a record of the acoustid(s) you had used as a reference for the merge in the edit note, you can still access those acoustids at acoustid.org but what you’ll see listed there are either the recording(s) by titles or just their former mbids if they’d been merged (that will take you to the new target). but the acoustid(s) will not be listed in that recording unless they were already listed before the merge. so if you don’t know where to retrieve them, those acoustids are basically gone.

example #1: https://acoustid.org/track/55434799-4c88-46f1-a728-f4937aaba782
lists the same recording, once by name and once more by the mbid of a former source that was merged into it. it is still listed in the recording only because it was there all along.

example #2: https://acoustid.org/track/7e7f46e7-3ba0-4007-8642-f63547b78b64
the two mbids listed point to the same recording that no longer lists this acoustid, as the acoustid was not originally in that target recording.

i’m fairly certain it didn’t use to be this way; acoustids used to be aggregated upon merges. and that’s probably one reason you often see multiple acoustids in recordings.

but because acoustids are now lost if you inadvertently pick the ‘wrong’ target (despite relying on them as corroboration to help pick these recordings for the merge in the first place), i don’t think this is a good thing. so if this change was intended, what is the reason? or is this something controlled at the acoustid.org end?

2 Likes

#2

That seems to be by design and it should not make a difference.
When a recording is merged the old id still exists and now points to the new id.

acoustid.org is a separate project and I don’t believe it depends on a replicated database to work.
Having acoustid that point to the old id should not cause a problem to the average user as this will automatically be redirected to the new id.

1 Like

#3

It causes a problem if MB doesn’t realise that these acoustIDs are now for the new recording and does not list them in the fingerprints tab.

@lukz, has something changed in your end or is this all on us?

2 Likes

#4

The merge resolving should happen automatically, but for some reason it’s not working. I’ll check what’s wrong.

3 Likes

#5

I have released a new version to fix the problem.

6 Likes