Inconsistent presentation (storage?) of artist-memberof-group relations

If you look at the members of the group Manfred Mann’s Earth Band

the UI presentation seems to be inconsistent.

Why has Manfred Mann a kind of joined list of instruments and vocals and the other members not.

I entered several entries for another artist of another band within one commit and one relation but he got the presentation unjoined, too.

Is this a bug or feature?

2 Likes

Relationships with multiple instrument/vocal attributes are intentionally split. It’s for storage purposes.

Not everyone was happy with that change.

Unfortunately the combined display hasn’t been implemented yet.

As a voter I still see people trying to condense them afterwards. I don’t vote against such edits, instead I explain the split is done on purpose. Most of them cancel their edit(s) then.

But for some reason the edit adding attributes for Manfred Mann wasn’t split. I think it’s because dates were added too.

5 Likes

I see now why the relationships are always split even if I didn’t make them separate.

I don’t think it’s because of the dates. From memory, I think relationships are only split after an “Add relationship” edit, not after an “Edit relationship” edit.

2 Likes

That was it. Stupid me.

Related ticket:

2 Likes

This is now in beta. Give it a try. :slight_smile:

Please note that a few bugs were found and are already being fixed:
~~https://github.com/metabrainz/musicbrainz-server/pull/1376~~
New beta with fixes is out.

Edit:
This feature has landed in production version on 2020-02-18

5 Likes

Guilty as charged!

My reason for condensing them is the report " Recordings with possible duplicate relationships" https://musicbrainz.org/report/DuplicateRelationshipsRecordings?filter=0
This report gives a lot of false positives because of this.

3 Likes

Yeah, that report is basically useless right now. @chaban (IIRC?) made a ticket for that ages ago, but I’m not sure how to go forward with it. We could just only show relationships that have the same exact attributes, but this would also stop showing stuff such as “recording of” vs “live recording of”, which we would certainly want to keep in the report. We could maybe try and do something where instrument and vocal attributes only are ignored, or where the “performed” relationships are ignored. The first is probably complicated, the second is easier but might also get rid of a lot of cases we do care about.

1 Like

I didn’t check all of them but the first few I checked for my collection are all correct:

It’s either:

  • a recording which is the recording of the same work but at two different dates* or
  • a recording where one artist plays several instruments

@reosarevok
What mistake exactly is this report looking for?
Could we hide (unlink/disable) this Recordings with possible duplicate relationships report?

I have already seen in my collection editors editing solely from reports.
But I cannot watch for all edits, even limited to my collection.

* And it’s displayed nicely, I think:

Art of life (live, 1993-12: Tōkyō Dome)

recording of: ART OF LIFE (on 1993-12-30: live, partial, instrumental; on 1993-12-31: live, partial)

“X played piano (date 1), X played piano (date 2)”
“recording of X, live recording of X”

They can sometimes be correct, as in your examples, but more often they show data errors.

The problem is that when we started storing each performed instrument in one relationship it broke this by making everything effectively a duplicate.

1 Like

Ah OK, it’s a side-effect.
But reducing (grouping) the displayed relationships is still good, I think.
I hope we don’t throw the baby out with the bathwater. :wink:
Better disable the report than reverting relationship display.

We’re certainly not going to change the rel display :slight_smile: The main problem is just what to do with this report to stop people encouraging to do things like that without just removing the report completely either.

1 Like