Here comes a wall of waffle that attempts to describe a weird bug undocumented feature in the database.
I was clearing up some old orphaned recordings and spotted a strange pattern. Orphans usually appear when someone re-associates a recording to a different or new recording. But this is different.
Something odd is lurking in the database. We have zombie orphan recordings with no home that are somehow linked to handfuls of random AcoustIDs.
https://musicbrainz.org/edit/44615910
Have a look at that edit. A big list of tracks that was added. The release was then deleted. This should have removed all the bogus recordings. But it didn’t. Over half of them remain.
Now this is where it gets weird. Click on any of those tracks in that list. You now have a Recording with no Release associated to it. Now for weirder. Click on the Fingerprints page. Why are there so many fingerprints linked? Look at the fingerprints and you will see they are random - yes, the track name will be (usually) correct, but often they are linked to Live versions or random Releases. ( Recording “November Rain” by Guns N’ Roses - Fingerprints - MusicBrainz or Recording “Another Brick in the Wall” by Pink Floyd - Fingerprints - MusicBrainz )
Why was this bogus recording not removed when the Release was? And how does an unlinked Recording like this get so many fingerprints?
Now the usual rule for an orphan recording is to merge it into another recording. These are so clearly a mess with that many AcoustIDs attached that they cannot be merged and have to be killed with fire. 
Do we have a Zombie invasion? 
Or is this something bugging out in the background? Is the code that deletes a Release not deleting Recordings if it sees AcoustIDs attached? (Actually that idea don’t work as I find some recordings with no AcoustIDs on that release)
Something odd. I can kinda guess some answers for the above, but I think a dev needs to look closer at the code that should have deleted the recordings here.
I was going to start deleting these manually - but have now found too many releases like this that I have stopped deleting and letting someone investigate this.
TL:DR - Deleting a Release does not delete all of the Recordings. It instead leaves lots of Orphan Recordings. These orphans then require manual deleting due to a confusion of AcoustID stopping merges.
3 Likes
They are linked to Works, so they are not orphaned.
5 Likes
Isn’t this a dead link? One can add a massive 500 track “Release”, hit up the “Guess Works” script, and then delete the bogus Release due to it not being a real Release.
Should a Recording only linked to a Work not get deleted if it was not created as a Standalone Recording?
2 Likes
Anyone is free to submit bad data to MusicBrainz via userscripts or otherwise. We don’t have an approval system like VGMdb that prevents the submission of duplicates and fake releases. (Open edits expire, after which you can’t use the voting system to reject bad data, and there was a conscious effort years ago to make more edits skip the voting system.)
3 Likes
Yeah, I get that. What I was curious about is this bad Release data was deleted. The Release delete removed most of the associated recordings. But thanks to those Works relationships we have left a heap of unwanted \ unconnected data. I would have expected that duff data to be removed with the duff Release.
Maybe I just look at things wanting them to be tidier 
Anything with a relationship remains behind - but if these are bad, just click Remove recording on the sidebar and get rid of them 
2 Likes
If you are aware you are intentionally creating these orphans by design I’ll go away. Trouble is there are too many there even in that one example to manually clear up. Almost certainly come from a mass “Guess Works” being used on that list of tracks. Thanks for your response. Puzzle solved. 
Well, “guess works” isn’t actually part of the server code It’s a script, and yes, as a small downside of allowing faster editing it also allows for things like this. I don’t think it’s very common though, because most people who use work scripts also make less mistakes than the average user (since both works and scripts are usually something only more experienced users look into).
I’d be more worried about “batch-create works” causing issues like this one, but thankfully I haven’t seen it too often, probably for the same reason that newer editors often ignore works (which is kinda bad in itself, but I guess good for this? ).
1 Like
I do realise that its not an official script, but I know I have used it on some new releases that I have seen appear in my Subscribed Edits. Or if I connect to a VA Release like that to update one track from a band I follow, I tend to update more that I recognise. I guess I need to be more wary about trusting validity of releases now I know this orphan potential.
I had started on my hunt of orphans as I had been seeing a lot of these in my corner of the DB. Most of those were legit from moving a track to different recording. Just like being tidy.
2 Likes