|
Sort Order:
Ok, I'll wait, but... 1. Cancelled add release http://musicbrainz.org/edit/14466516 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... 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 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"? 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: http://musicbrainz.org/artist/78ce36c0-0447-4231-9d57-c6435c811aa9/recordings 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 Thanks Oliver for fixing the ones I mentioned, but I'm still finding orphaned recordings. Did these just fall through the gaps? http://musicbrainz.org/recording/44092b62-845b-4c90-a05c-25180ab68055 http://musicbrainz.org/recording/8e35eeba-4819-4739-a9a4-79b119acfb2a 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 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Bug
Closed
Major
Orphaned release group and recordings after rejecting or cancelling a release/medium
These were only closed a couple of hours ago, right? Worth waiting to see whether modbot will clean them up before logging such issues?