Why does acoustID sometimes not show merged recordings?

More curiosity than anything I guess, but I’ve noticed sometimes a given acoustID does not reflect current recording status after a merge, I guess as if the original recordings were still present on MB? When you click through, you see the same recording repeatedly. Anyone know why?

Here’s an example of what I mean: Track "b1eb0783-f5f3-4428-9733-2fbfd8e30d93" | AcoustID

I think the AcoustID updates are done on a slower \ batch system. Click any of them and they link to the same recording on MB as the MBIDs all redirect.

1 Like

Thanks, I know they redirect appropriately. Still, these recordings were merged in July…

Resubmit the fingerprints if you can? You’ll also notice that for new recordings the metadata is often missing:

Which will unfortunately lead to standalone recordings results when using “scan”

Or that even after multiple years a submission is still “pending”.

Just for information, here’s another one Track "8f1a38dc-bbe0-486f-b005-3e1cbc66fb28" | AcoustID (and the second time today I’ve seen a track length not updated on acoustID after being fixed with a discID on MB). This one also has a bunch of “orphan” (really, merged I think) recording IDs instead of titles, which is something I guess more common (but also strange).

There seem to be definitely more cases of this coming up recently. I think that is also what caused Worse results in Picard 2.10 - #34 by outsidecontext

The AcoustID server has code to follow up on recording merges. To me it looks like this is no longer working right now. I opened a ticket:


Just bumped into this edit note from last year (2022-12-17)

This recording should have eight AcoustIDs after a merge. It still only has two a year later:

AcoustIDs were “lost” during a merge… and are still waiting to be reattached to the merged recording 12 months later.

In the edit note I had expected to loose the AcoustIDs attached to the various recordings. So I took notes of all the AcoustIDs that should have ended up on the target. I wanted to test the theory. And a year later this still has not happened.

Notice my note that lists six AcoustIDs that were associated to the various recordings. These should all have moved to the one Recording MBID.

You also get examples like this:

One AcoustID, listing many different old Recording MBIDs which now point to the same recording.

The more recording merges we do at MB, the more out of sync the AcoustID database gets.