Empty release group http://test.musicbrainz.org/release-group/1193c3be-9fb7-45c1-a94d-06e6b7e0f732
and recordings http://test.musicbrainz.org/recording/6a1fbeed-53b3-48b6-83cf-583208078933 http://test.musicbrainz.org/recording/8d53e345-2816-40be-a742-7709ae3ba095 http://test.musicbrainz.org/recording/b8dac813-2142-454d-a4a5-30e89a02d35d
after cancelling http://test.musicbrainz.org/edit/14459942 http://test.musicbrainz.org/edit/14459943 & http://test.musicbrainz.org/edit/14459944
These were only closed a couple of hours ago, right? Worth waiting to see whether modbot will clean them up before logging such issues?
Ok, I'll wait, but...
1. Cancelled add release http://musicbrainz.org/edit/14466516 (2011-05-24)
2. Cancelled add medium http://musicbrainz.org/edit/14466518
3. Remove empty release group http://musicbrainz.org/edit/14512730 (2011-05-26)
4. Orphaned recordings http://musicbrainz.org/recording/4021d2e1-ca70-48b6-8ed7-3cc1d096090b http://musicbrainz.org/recording/0bc19b52-30d8-4128-8ef7-4cf9c1055702 ...
Fair enough. I guess I'd expect the RG to be cleaned up if there are no other pending edits against it; but the recordings might be an issue - since NATs are now just solo recordings - how would modbot know which were NATs and which were left over from a cancelled edit? :/ This could be creating a vast amount of dodgy data in the DB if this is indeed the case though!
> This could be creating a vast amount of dodgy data in the DB if this is indeed the case though!
Indeed, especially if the reason for the cancel/reject are a number of misspelled tracks and the release is added again with the correct titles (instead of changing the misspelled)
Marking as major for the recordings part.
This also happens when you reject a release:
An easy way to tell standalone recordings apart from ones created by a release:
A standalone recording will have an "add standalone recording" edit with a mandatory note (eg, http://musicbrainz.org/recording/1ba9fe0e-aab7-4151-bcf9-ce5b7fca7fd1/edits).
A recording created through the release editor will not have any history at all (eg, http://musicbrainz.org/recording/70fab960-184a-46de-9d0e-4559b573c3a0/edits).
So, ModBot should be set to purge recordings if...
1) There is no "add standalone recording" edit in the recording's history...
2) It is not attached to any releases/tracklists.
It'd be great if this could be added soon because I just realized how much of a mess this is causing. (I want to vote down someone's addrelease right now, actually, since spelling errors and no track lengths, and some pre-existing recordings should have been used. There are 32 recordings involved and 32 orphans will be painful.)
This is partly in review at http://codereview.musicbrainz.org/r/1340/.
Not really fixed, at least for release-group: http://musicbrainz.org/release-group/a625cffd-d61e-442c-9a9a-65af6bea7aa7 still exists whereas http://musicbrainz.org/edit/14781116 has been rejected.
Murdos, did you see my comment above? Would like feedback on that proposal.
OCharles, why are you closing tickets when they're not resolved?
I imagine my "shipit" script closed this when the review passed.
Decision required: Is it OK to delete a release group if deleting the last release in would leave it empty?
It's ok for me to "delete a release group if deleting the last release in would leave it empty"
Sure, assuming no pending edits to the RG, I guess?
However scripts should probably still clean empty RGs up periodically - otherwise a pending edit on the RG might prevent automatic removal at time of release deletion/cancel; and then there'd be nothing to clean up later?
What exactly is meant by "Is it OK to delete a release group if deleting the last release in would leave it empty"?
Does it mean you can delete a release group that has one release in it? I would oppose to that. Or does it mean that if the last release gets deleted from a release group, the release group automatically gets removed? That would be ok.
However, I think this wouldn't be needed if we just (like for artists) remove empty RGs (with no pending edits) periodically...
Of course it means the latter.
Reached enough of a decision to continue work
Should existing orphaned recordings be automatically deleted now, or do we have to do this manually? e.g. this recording has been orphaned for weeks now: http://musicbrainz.org/recording/b3defaa0-7c2a-4ceb-ab76-1e1fcca9b3ef
I'll run the script now and clean up remaining ones. Hopefully this will be enough to finally close this problem!
Ran the script, that recording is gone, along with a staggering 5171 other recordings
Note that the script does not remove recordings that have any information at all attached to them - even user ratings, so I imagine we still have orphans.
Thanks - I've noticed that one of the orphaned recordings from this release that never entered the database was not deleted because someone had added a PUID to it - despite it not being attached to any releases! Weird. http://musicbrainz.org/recording/c7ce6dad-7c0f-407d-bdc7-d9985d707ac5
One thing I've learnt in my 5 years at MusicBrainz is that people will tag and rename their entire collection, without manually verifying, against any ol' bunch of crap. And then submit the PUIDs, thinking they are helping. Welcome to the crowd!
Other relevant facts - Picard can tag standalone recordings, and taglookup was giving ridiculous results prior to most recent release. So it's possible this was the best match :-/
Going forward, what's the story here? There's still a chance of new orphaned recordings here if they have PUIDs or ratings attached and then the edit is rejected? Or that comment only applies to the cleanup script?
Would it be possible to run the script in spite of existing PUIDs or ratings or do we need a report for catching those empty recordings?
@Ross: That release probably existing once, but the edit was cancelled or rejected.
My thoughts with keeping this data around is that it should be merged, rather than deleted. A report is probably the best way to sort that out.
@Voice: that comment only applies to the cleanup script. From this point on, it shouldn't be created orphans (unless someone adds ARs to the recordings)
The release existed briefly with new recordings, by they were quickly swapped to existing recordings, leaving the new recordings orphaned. Looking at the edit history, the PUID was assigned at a time when the recording was orphaned, which means voiceinsideyou was right about Picard not giving the best possible matches and users not paying attention.
It would be good to merge in this case, but is it likely we will manage to merge all of these orphans before they get incorrectly integrated into people's collections via Picard?
I'm still finding orphaned recordings without any relationships, e.g. all these:
Any ideas why?
@Ross: This does seem to be a bug I think. The release edit was voted down only 12 hours ago (it's still in indexed search results at time of writing... search server indexes not updating again?) http://musicbrainz.org/edit/15289833
Recordings from http://musicbrainz.org/edit/15286443 have similar problem...
One more fix in 830991b
Thanks Oliver for fixing the ones I mentioned, but I'm still finding orphaned recordings. Did these just fall through the gaps?
Maybe the script needs to be run again to clean up orphans created from the more recent bug?
The script has been ran again. The recordings Ross mentioned were created on the 9th Oct, so I wonder if that was too early for the changes to catch this? Please continue to report any oddities you find!
I filed MBS-5035 for a similar issue which remains after this fix.