#metabrainz

the wiki site is looking odd, https://wiki.musicbrainz.org/Main_Page

It seems like it is treating my desktop browser as a mobile

[musicbrainz-server] reosarevok merged pull request #1707 (master…MBS-11033): MBS-11033: Update the Apple Music logo https://github.com/metabrainz/musicbrainz-serve...

MBS-11033: Update the Apple Music logo used in the sidebar https://tickets.metabrainz.org/browse/MBS-11033

[musicbrainz-server] reosarevok merged pull request #1713 (master…MBS-3116): MBS-3116: Warn when merging works with different ISWCs https://github.com/metabrainz/musicbrainz-serve...

MBS-3116: Warn when merging works with different ISWCs https://tickets.metabrainz.org/browse/MBS-3116

[musicbrainz-server] reosarevok merged pull request #1716 (master…MBS-6322): MBS-6322: Add report for releases with same barcodes in diff RGs https://github.com/metabrainz/musicbrainz-serve...

MBS-6322: New Report: Releases with identical barcodes in different Release Groups https://tickets.metabrainz.org/browse/MBS-6322

[musicbrainz-server] reosarevok merged pull request #1714 (master…MBS-4118): MBS-4118: Add full-icu to Node for locale strings https://github.com/metabrainz/musicbrainz-serve...

_lucifer: how odd?

I don't have any issue with it at least.

This is how it shows up on my PC yvanzo

probably it is some misconfigured setting then

on y end

*my

reset your zoom

Hi all. Seeing fairly regular OOM reports on my VM running MBserver under docker. Not generating search indexes. VM has 4 Gig of RAM and 2 processors.

Is this expected? 4 Gig is the recommended configuration I seem to recall?

moin adhawkins. 4gig seems rather paltry for a VM. Go for 8 and I think you'll see some problems go awa.

away even

If OOM occurs in db container, you can try increasing shared_buffers first.

yvanzo: How would I work that out?

ruaok: 8 Gig would be a quarter of the RAM in the host! :)

only a quarter? fin, 16G then!

:)

Wouldn't leave very much for the other VMs :)

This is only my home setup...

It's not happening a lot. These are since the VM was booted on 22nd Sept:

adhawkins: docker-compose config | grep shared_buffers

2048M

but it seems that OOM is invoked on perl, that is musicbrainz server itself, so it's not related to pg shared_buffers.

I think OOM killer just looks for a candidate process to kill, not necessarily the one that's causing the OOM?

I lol'd

3am is the time I run a local check of my entire library against the server. It usually finishes around an hour or so later.

adhawkins: try pushing it to 3GB, see https://github.com/metabrainz/musicbrainz-docke... (just ignore the "search" part)

So there will be lots of XML WS requests during the hour between 3am and around 4 ish

if the problem comes from musicbrainz server itself, there should be hints from `docker-compose logs musicbrainz`

adhawkins: does your replication cron job run at the same time?

yvanzo: It runs at around 15 minutes past the hour I think

every hour?

Yes

ok, so there is only one replication packet to be retrieved and applied, that’s better than 24.

Yes

I could exclude the hours between say 3 and 6 too, see if that helps?

You can check slave.log.X for potential errors related to OOM.

Yes, excluding it during that time could possibly help.

Mr_Monkey: around?

Hai !

Ok, I'll do that as well yvanzo and monitor.

If I change the replication crontab, what do I need to do to have it applied? Just restart the container?

Let me guess, wanna talk about dates reo?

[musicbrainz-server] reosarevok merged pull request #1710 (master…MBS-11121): MBS-11121: Normalize Apple Music beta links https://github.com/metabrainz/musicbrainz-serve...

MBS-11121: Update iTunes/Apple Music URL cleanup https://tickets.metabrainz.org/browse/MBS-11121

adhawkins: you should check it with crontab -l

ruaok: the travis build stops for some reason, can you have a look?

you can edit it directly in the container with crontab -e but if you modify it in docker compose config, you need to "up" it (which will stop, remove, recreate a container).

Mr_Monkey: I do!

heh. travis is being rate limited by github.

that's tricky

in any case, check with crontab -l

So, what do you do with year +0000 ?

Do you count that as -1 BCE -0001 is -2 BCE etc?

pristine___: other than retriggering the build, not sure what else to do.

is this for the simple logging changes?

yes

do the tests pass locally?

reosarevok: year 0 after covid spread? ;)

So +0000 is year zero AD. The year before that is 1 BCE, which is equal to "-0001" if I remember correctly. There was some complications around year 0, I do remember that, but not the solution. Give me a moment to look that up again

Mr_Monkey: 0 AD doesn't exist though?

Ah, that's the one.

yvanzo: 'up' doesn't appear to have recreated the container.

I'll manually down and up it.

An expanded year representation [±YYYYY] must have an agreed-upon number of extra year digits beyond the four-digit minimum, and it must be prefixed with a + or − sign[21] instead of the more common AD/BC (or CE/BCE) notation; by convention 1 BC is labelled +0000, 2 BC is labeled −0001, and so on.[22]

Right. Ideally, you'll ignore year 0.

To represent years before 0000 or after 9999, the standard also permits the expansion of the year representation but only by prior agreement between the sender and the receiver.[20]

Which container's crontab should I be checking? musicbrainz-docker_musicbrainz?

adhawkins: yes: docker-compose exec musicbrainz crontab -l

The library we use does support years BCE but in this way, so I'm wondering whether to just give the user a BCE vs CE option (defaulting to CE) that on entering massages the year to the appropriate expanded year convention

(so if they enter 1 BCE it will store as 0000)

We do date calculations (age and such) so in that sense just skipping 0 would be complicated too

adhawkins: it recreates container if config changed, but if it is just the content of a bind mount maybe it does not need to recreate the container indeed.

Ok, crontab hasn't updated, even after docker-compose restart musicbrainz

bitmap: IIRC your change that caused MBS-10976 was intentional, but what should be done in a case like that edit? :)

MBS-10976: Unicode Private Use Area characters are stripped during edit process https://tickets.metabrainz.org/browse/MBS-10976

You suggestion seems ideal. BCE/AD checkbox or select, and a proper library to massage it in and out of the DB

I went the other route for BB but I think it will need refactoring

Ah, now it has. I recall there's a job that runs at startup that applies the new crontab

Cool!

reosarevok: Also, if it's relevant, I settled for this format (note the 6 digits for year) ±YYYYYY-MM-DD

Ok, I've stuck a cron job in the host that'll do the dmesg -T | grep oom and email it to me daily. WIll monitor. Thanks yvanzo

Mr_Monkey: heh, I think that's more relevant for books than music

For now I'm planning to stick to 4 digits (+ or -)

And also possibly relevant (?), I opted for CE / BCE in order to leave christ out of all that.

Granted, it does say christian, but…

Yeah, I was going to do that for sure

Depending on how you read it :p

or "Common"

For the diehards who don't wanna let it go, i mean :p

For the rest of us commoners it'll be a step forward.

I swear if I ever get a time machine I'll go back and find the dummy who decided there would be no year 0 and give him a talking to.

ruaok: yeah, tests pass on dev

then I'm fine to merge and push to newleader.

shall I do that?

Yeah, there are only log changes. I think you can push to newleader

[listenbrainz-server] mayhem merged pull request #1113 (master…mapping-count): log listen count and mapped listen count https://github.com/metabrainz/listenbrainz-serv...

pristine___: done.

ruaok: ^

it increased 19 fold? O_O

listen count increases joining with mapping. i didn't expect that

writing few more log statements to understand what's happening.

yes, please. this sounds like a query mistake; some join going bad.

it should be less than the original amount, best case equal, no?

> it should be less than the original amount, best case equal, no?

yes!

[musicbrainz-server] reosarevok opened pull request #1718 (master…MBS-7219): MBS-7219: Hide links to empty ArtistRecording subsets https://github.com/metabrainz/musicbrainz-serve...

MBS-7219: "Show only standalone recordings instead" text should only appear when there actually are any standalone recordings https://tickets.metabrainz.org/browse/MBS-7219

this is apparently causing that 19 fold increase! We should first filter all the distinct rows from the mapping and then perform the join.

ruaok: ^

yep, that would do it. :)

removing `msb_recording_msid| msb_recording_name_matchable| msb_release_msid| msb_release_name_matchable`from the mapping before the join will do

`msb_recording_msid|msb_release_msid|msb_release_name_matchable`