What is the best practice for this? Do they stay forever? Does it matter?
AFAIK AcoustID is supposed to pick up the merges, but it does not seem to work that well (or at all?). There is an issue about this on GitHub:
I only disable them if they redirect to the wrong recording or lead to an error page.
3 Likes
Are the old recording MBIDs of merged recordings intended to be disabled or left enabled?
I missed the actual question in the title. But as @Comrade_Mike said I’d advise to only disable them if they lead to the wrong recording. Otherwise the recording will redirect to the correct recording and hence is still useful for lookup.
Since Picard 2.11 it also handles such cases better. Before that those stale recording IDs could actually cause a problem, as they even could score higher then the proper recordings. Since Picard 2.11 Picard resolves the recordings IDs and also has improved comparison when metadata is missing.
2 Likes
You may notice when a Recording merge happens today you will loose AcoustIDs of those items merged into the target.
It is these old MBIDs you see on the AcoustID page that will eventually bring all the AcoustIDs back to a merged release. The sweep to pick them all up at AcoustID seems to have not happened for many years now, but while the numbers are still there then one day that script may be run.
I have been watching this in some tests lately as I was curious too… Edit #115576481 - MusicBrainz
Script not run since at least 2021… probably earlier: Edit #81215318 - MusicBrainz
4 Likes