#musicbrainz

Anyone know why this edit shows up in the list of recent edits for Dire Straits? https://musicbrainz.org/artist/614e3804-7d34-41...

because "money for nothing" is track #6 on that medium

(it isn't one of the ones involved in the merge)

Ah, got it darwin. I assumed that merging two releases would merge all the recordings. Hadn't spotted that there were gaps in the track listing. Make sense now, cheers :)

Any (helpful) comments on https://community.metabrainz.org/t/artist-serie... would be appreciated

I just use the # attribute combined with year

see https://beta.musicbrainz.org/series/3dea0f6e-8e...

it's kinda like tracknumbers in tracklists

you can put what you want in there

I said on the post ;)

Hoping to start a discussion

alriiight

:)

looking for a couple of votes to get these fixed a bit quicker... https://musicbrainz.org/release-group/53e37a58-...

the arbitrary long lists of countries i find slightly odd, i've seen it on this release and a couple of other places.

They're not arbitrary though! They're totally correct lists of availability blah blah

At some time, which yes, might or might not be release time

People seem to love it

Well, some people at least

Emphasis on some

There doesn't seem to be a particular justification for them in the documentation

or rather, I can't imagine it being possible for a human to generate that list, or read it and understand what it means - for example ,I can't tell the difference between the list there with one date, and the longer list with the other date

Clicked Enter Edit on a release and got pages of red errors inserted, starting "Failed query: 'SELECT pg_advisory_xact_lock(?, id) FROM unnest(?::integer[]) AS id' (22 ARRAY(0xac505d0))". Full error AT https://pastebin.com/raw/eVhtanYg

Clicked Enter Edit from that page with the errors and it seems to have entered.

Looks like MBS-11345

MBS-11345: Error when submitting edit: deadlock detected https://tickets.metabrainz.org/browse/MBS-11345

deadlocks occur when two people are trying to modify the same database object at the same time...

though why a *SELECT* should result in a deadlock.......

I guess something else is doing an exclusive SELECT FOR UPDATE like query? or the SELECT that's failing is in a transaction with UPDATE/DELETE?

also, that backtrace... my eyes.. the goggles, they do nothing