Aha, good to know. Thanks again.
1 Like
That is not the way to merge. You merge to the item with the most details, best quality details. Often this is the older ones. Please don’t just merge to the oldest without looking.
When you have two different recordings you need to look at them. Find the best quality one to use as the target. Or the one with the most releases associated to it. There is no rule that says “oldest is best”.
1 Like
There is no rule either to target the one with most details or the one that has the most releases.
The merged recording will contain all details and releases, in the end, whatever the direction.
There is a link in the OP to why I prefer merging to the oldest.
So the most important is to make sure that these recordings are indeed the same before merging them, add it is impossible to revert to previous situation.
A major reason I will check for the most used version as a merge target is due to how other people use the data on the outside world. If you have a recording with 100 tracks associated to it, and another recording that is older and only one track associated, then maintaining that most used MBID makes life easier for anyone else using the data.
I know that an old MBID is kept and redirected, but I still think of users of media centres like KODI that use the MBIDs to link the data. For then I will always target the more accurate and better used item.
To quote guidelines: How To Merge Recordings - MusicBrainz
you should choose the recording with the most correct information. If there is no real difference, the usual choice is the oldest entry.
And we do sometimes loose data. There has been a bug which I don’t think is yet fixed which means AcoustIDs are not currently merged.
2 Likes
It’s the exact reason why I target the oldest.
Check out my link in OP.
The one that has the most things is maybe due to a recent merge NOT in the correct direction, so, towards a brand new MBID, that cannot be already used outside.
I did read your OP. I just get bored of hearing “must be new to old” as that is a myth. I agree that is it usually the way, but not always. Better to take a quick check.
Hardest things I find to merge are VA releases. Often find myself double checking my edits after using Mass Merge and finding a couple of recordings that need to be flipped in direction due to more common use. Number of attached AcoustIDs is often a good hint. (Can’t remember which script it is that shows the AcoustIDs on the “current edits” page but that is REALLY handy for a quick check)
1 Like
Certainly, but I have some grip on how to check for best & most detail. The oldest ID then is a good point of favour between 2 equally detailed duplicates, but somewhat eluding to the eye.
True but maybe all these good things were linked to an MBID that recently disappeared in favour of a brand new MBID (into which it is no longer good to merge, benefit of age is already lost).
It very often happens that people adds duplicates then merge existing into their duplicates.
It’s why older row ID is more sure about which MBID is actually older, not amount of data.
Exactly this. If a quick look you don’t see any difference, then oldest wins.
Now you are off on an odd edge case. Constantly flipping MBIDs would not be good. In that rare example it would not really matter which one was chosen.
It’s often the case with the merged recordings I see.
Because people tend to merge to newer and more complete recordings. 
Not sure if it’s due to the same issue as the one @chaban wrote on the topic of the MASS MERGE RECORDINGS script, but this one stopped working for me yesterday. Searching through recent merge edits of others (and not just recording mergers) it seems like this may not be just me. 
1 Like
Basically same issue :
Remove [action*='/merge'] and it should work.
3 Likes
2 Likes
Not sure whether it’s just me but it looks like this script stopped generating the ‘‘Merging into oldest [MBID]’’ text that goes at the bottom of each note for merger edits. At first I thought it might be just me having recently re-installed my browser and there might be some default setting that I forgot changing. I even tried using it with all other userscripts disabled but it didn’t change anything.
On the other hand, I also noticed that no merging edits have been entered with this autogenerated bit in the notes for the last few hours, so maybe there’s some general issue instead.
2 Likes
Wow nice search!
It seems to work for some editors.
What are your OS, browser and userscript extension, names and versions?
Interestingly, it started working for me too again. Here are two very recent edits that I just entered:
Edit #101574543 - Merge recordings
Edit #101574769 - Merge recordings
Not sure if it’s any factor for things going back to normal, but the only thing I did in the meantime was re-enabling all my other userscripts.
Windows 10 Pro 22H2
Firefox 115.0.2 (64-bit)
Violentmonkey 2.14.0
1 Like
Same here, it stopped writing this note already long ago, didn’t bother to make noise about it til now.
So today it’s Ubuntu 20.04.6 LTS, Brave v1.56.11, Tampermonkey 4.19.0; tried also Chrome 115.0.5790.110 & Firefox 115.0.2, both with Violentmonkey 2.15 and only “mb. MERGE HELPOR 2” 2023.5.17 enabled. Similar story on Win10 which I rarely use. ¯\_(ツ)_/¯
1 Like
I tried it here and it worked.
I think it works on Windows also for me.
I’m wondering if it’s another React Hydrate problem, maybe.
Does the userscript work when you are still on merge page, before submitting (showing info and pre-selecting oldest MBID)?
Is it only an edit note problem?
I have reproduced this bug on a new PC with Edge 115!
It seems to be a problem with Chrome version 115.
I will hopefully fix that soon…