How to deal with duplicate releasegroups?

Tags: #<Tag:0x00007f3427c97f90> #<Tag:0x00007f3427c97ba8> #<Tag:0x00007f3427c97478> #<Tag:0x00007f3427c96f78>



unfortunately there are duplicate releasegroups. The concrete cases are:


Both releasegroups are albums of the American band 3 Doors Down.

I know that this is not totally avoidable, but if this happens, how does MusicBrainz deal with that? Is the duplicate releasegroup removed or somehow marked as duplicate?

Thanks in advance.



Normally when we editors run across duplicate release groups, we merge them. There’s no flagging to be done; you can just dive in and enter the merge edit.


Here is a How to for Merging Releases.
I’m thinking that merging Release Groups will be similar.


Ok, thanks for the quick answers. If a remove takes place, the case is clear. But I couldn‘t get from the docs what happens after the merge with the old database record. Will it be removed or will something else happen?

The reason I ask this is that in my app users can add information linked to releasegroups in my database (in this case if they already have bought that particular release). If the release group id is lost, then my record also doesn‘t make any sense. In this case I could simply remove my db record.


Get confirmation on this, but as I understand it Merging keeps old IDs alive. That is the difference between Merging and Deleting and why Merging is usually the way forward.


Mhm, but this wouldn‘t solve the base problem, would it? Why merge when the merged object survives? How can I see which of the releasegroups is the „main“ one? Currently I have the problem that in the list of an artists media I have many times the same album :frowning:


After the merge, there’s only one Release Group object, but it now has two RG ID’s. Also, any relationships that reference either of the merged groups will now reference the resulting group.


A bit confused now. If I run|ep|single&limit=140&artist=

I only get release-group objects with one single ID. Do you have an example for the case you mention here? In the case of the band 3 Doors down, I get multiple releasegroups with each of them having one single ID. Are the RGs not merged, yet?


Both the old and new id’s still exist in the database and can be queried after you merge entries.
If you query the old entry it will return the same information as if you query the new id.
The output from the site and web service includes the current id of that entry and if you care you can compare the id returned is different to the id you queried the entries have been merged.


So do I understand correctly that running|ep|single&limit=140&artist=SOME_ARTIST_ID

I will also get the 2 release groups even after merging? This would in my opinion be a significant problem :frowning:


You can see which release group is the oldest one by clicking on each of the release groups’ “editing history” and comparing the dates of the oldest entries. Additionally, you can use a userscript called MERGE HELPOR 2 from @jesus2099 that will automatically highlight and select the oldest MBID and also provide this info automatically in an edit note which looks like this:


Mhm, the problem is that I need this info in the API :frowning: In addition I would need it in the method I posted before:|ep|single&limit=140&artist=SOME_ARTIST_ID

because I cannot call

on every single releasegroup since then I would quickly run into the rate limit.

I think, this is a major flaw :frowning:


If you query the api you will only get the new release group.
The old release group exists only as a pointer to the new entry and does not show up unless you specifically know it exists.
If you have tagged your music with the old entries the next time you tag them they will be changed to the new id’s.


Ah ok, I think now I understood :wink: So if someone marked some releasegroup in my app as “owned”, and this releasegroup gets merged, it doesn’t appear in the releasegroups anymore retrieved by the release-group endpoint using the GET parameter “artist”. So hence, all I would have to do is to remove the “orphans” in my database linking to a release group with an id not being output by the releasegroup endpoint used as described above.

The only thing that is unsolved is that (at least to my knowledge) there’s no flag or something in the data that I get from the api when I lookup some merged release group by id. There’s no way to see in this info that I’m currently looking at a merged record, right? If this info was there, I could migrate my data to the new record.

What I would need is:

  • record 1 and record 2 are duplicates
  • record 1 is merged into record 2 -> record 2 is the primary one that survives, record 1 is the “old” merged one
  • when looking up record 2 by id there’s a field called “isMergeOf” that contains the id of record 1

If this is not possible, would it be possible to add that functionality in the future?


So for cleanup of orphaned entries you just need to occasionally query each item to see if it has been merged.

So if you query the web service:
From the output you will see the following:
<release-group type="Album" id="d8eef621-14de-47c8-b749-7a3a4bb78530" type-id="f529b476-6e62-324f-b0aa-1f3e33d313fc">

Notice that it includes the release group id, so if this changes the id will no longer be the id you queried and this has been merged


At first thanks for your time ;)! Really appreciate it.

Just to sum it up: You say that, if a release group has been merged into another one, then the release group id in the api response is different from what‘s in the url?

Anyway querying all release groups occasionally is not an option because of the hard 1 request/second rate limit in musicbrainz db :frowning: I can only do it on demand if the request is done anyway.


You could always create a ticket for this. I don’t know what the database impact is for such a query, but being able to request merged IDs in a WS request sounds useful.
Not saying it would be high priority, of course.


Where do I create tickets like this (that are indeed read :wink: )? But in fact I would need the info in the search endpoint of releasegroup, else it’s useless (at least in my usecase).