#metabrainz

bitmap: has anyone mentioned in the beta that if you add a new artist from the relationship editor the interface goes a bit fuzzy/eye-watering? I couldn’t find a note anywhere, shall I add a comment to MBS-11847? Or is it known somewhere else?

MBS-11847: Port the relationship editors to React https://tickets.metabrainz.org/browse/MBS-11847

Bit hard to see in this screenshot, but it’s being scaled or something weird in a just slight enough way to give me a bit of a headache on my screen :( https://usercontent.irccloud-cdn.com/file/7j7Vg...

mayhem: yes doing it currently on artist mbids instead of artist credit id. do you mean that we should instead calculate similarity of artist credit ids but filter out same artist using artist mbid? so find similarity between `A ft. B` and `B ft. C` but filter out A, B, C from similarity index.

hi @lucifer...I tried exploring the listenbrainz website locally and I also tried learning docker basics.Should I start working on some bugs?

vibhoo_24: yes. try to find a ticket to work on from tickets.metabrainz.org . if are unable to find one, let us know and we'll help

lucifer: yes, I think that is right. lets try that.

Mornin'. My Glob, jetlag is real.

mayhem: I'll have to see if a URL to an SVG would work for all the sharing stuff, I have no idea.

I assumed it would have to be a more common image format, but…

Looks SVGs would probably work according to this preview tool: https://usercontent.irccloud-cdn.com/file/W8KOf...

Not sure if it's loading the fonts

Oh, quite interesting. I knew Twitter was the least likely to support svg..

Not sure what's going on there to be honest. They might support SVG. I think it's just the tool I'm usign, will conduct more testing

Anything with cover art won't load, so that's out.

And I confirm it's the same for the custom fonts, it won't load them. So aerozol that's going to limit your range, the preview will only use default browser fonts

[musicbrainz-server] 14reosarevok opened pull request #2776 (03master…MBS-12781): MBS-12781: Avoid admin accidentally breaking options trees https://github.com/metabrainz/musicbrainz-serve...

On today's episode of "reosarevok tries something dumb, finds it's allowed"

lol

aerozol: is it vandalism if you respond to everything with the eggplant emoji? :p

An infinity of monkeys with an infinity of keyboards…

monkey: they don't support svg.

>A URL to a unique image representing the content of the page. You should not use a generic image such as your website logo, author photo, or other image that spans multiple pages. Images for this Card support an aspect ratio of 2:1 with minimum dimensions of 300x157 or maximum of 4096x4096 pixels. Images must be less than 5MB in size. JPG, PNG, WEBP and GIF formats are supported. Only the first frame of an animated GIF will be

used. SVG is not supported.

Bleh.

At this point, between the lack of custom font and the lack of SVG support I wonder if we should just generate an image for each user

[listenbrainz-server] 14MonkeyDo merged pull request #2244 (03master…babel-updates): Babel and Webpack updates https://github.com/metabrainz/listenbrainz-serv...

how large is one image in png/jpg?

yvanzo: hi! any updates on the recording index after the lru_cache patch?

[listenbrainz-server] 14dependabot[bot] closed pull request #2173 (03master…dependabot/npm_and_yarn/jsdom-and-jest--removed): Bump jsdom and jest https://github.com/metabrainz/listenbrainz-serv...

mayhem: but then we'll also need to query for similar artists using artist_credit_id instead of artist mbid

monkey: there's LB#2255 but i don't see any other JS PR. so right time to move the source i think.

css: Bump Bootstrap to 3.3.7: https://github.com/metabrainz/listenbrainz-serv...

There are more, but none that we can act on right away I think.

So green light ! :)

right makes sense

should i open a PR or are you on it?

Please do :)

👍

thoughts on name the new folder `listenbrainz-frontend`?

What about just `frontend`? Not like we're likely to have other front-ends in there

makes sense

Was doing a quick test of PNG size: Original SVG: 6Ko (of course), PNG: 550Ko, JPG 765Ko.

I'm expecting a 2:1 aspect ratio version to be roughly around half of those sizes.

if we take 0.5MB per image * 10k users at max, ~5 GB storage needed.

monkey: what does pngcrush do to that png?

(hi, good morning)

Hi!

lucifer: yes, sounds right.

alastairp: Good call. 550 -> 400 Ko

5gb is nothing, anyway - both for storage and data transfer

one trick would be to have a URL which builds it on demand if it doesn't exist and then save it - subsequent requests just serve the generated file (I'm unsure how long generation takes), so we'd only generate/store for users who actually use the card

mayhem: ok. can try that. oh but just realised, i am not sure if it'll work though because band members don't usually occur in the same artist credit anyway?

That is the whole point of this change... We should be moving the similarity comparison to the artist credit level.

We want to find out which bands are similar, rather then which individual artists are similar. (Painting this with a very broad brush here)

i mean yes but bands and artists are both represented by artist mbids in MB

*individual artists

the artist credit in this case is only relevant to how their name appears on a track iiuc.

i think we'll need to export artist relationship data from MB to spark and add some filters to remove artists from same band from the similarity list.

but i am curious where you see artists from same band in the similarity. for instance, https://labs.api.listenbrainz.org/similar-artis...

no artist of the band here

(although i have to figure out how max martin got there given there's one 1 release in MB for him and that too a cover compilation)

Dataset hoster: similar-artists (https://labs.api.listenbrainz.org/similar-artis...)

Horace Andy is a member of massive attack. He should not be in the results.

Elizabeth Fräser and Robert de nala too

i see.

i'll add the artist credit level thing for testing. but i think we'll need to use MB relationships to do this filtering properly.

> one trick would be to have a URL which builds it on demand if it doesn't exist and then save it

I suppose that would be each user's YIM page itself

there's a meta tag for the card image, right?

yes

lucifer: not really any effect, as mentioned yesterday.

yvanzo: oh, crashed again?

after about the same time with about the same amount of memory

i see. makes sense

alastairp: yes. Are you thinking of using the image URL to build on demand?

yvanzo: thoughts on what to do then? since 3.0.1 also crashes with same amount of memory.

monkey: so I'm saying to have something like `<meta property="og:image" content="https://listenbrainz.org/yim-2022/...; />`, which is actually a flask route, which generates/saves the png, and serves it from cache if it's already generated

Right.

monkey: but I would only suggest that if we think it's infeasible to pre-generate and store for all users

I suppose image generation would be quick enough to actually serve the image the first time around?

yeah, exactly. in the case that it's 1-2 seconds max to generate the image then we could definitely generate/serve it the first request

how long would we want to keep this around? 1 year, forever?

I think a mechanism like that would make sense, especially if we want users to be able to generate images for other stats

this image will always be needed or just the first time the social media site renders the card?

i.e. useful for the OG meta tags, but also for "share your top 10 albums" feature

kind of why I put the year in the url... as long as we had the stats we could generate it at any time. I guess we plan on removing it after a year?

lucifer: I don't know if social sites just deep link to the image or if they cache it

i see, maybe there's something in the spec but will have to check.

lucifer: It’s weird indeed. It used to work with these settings though. It even used to work on less powerful development stations too.

yvanzo: maybe we should try with an even older release then. one prior to the schema change and see if that works? if that still fails maybe an issue in vm conf otherwise.

monkey: is there any reason to keep config files like webpack.config.js etc in root, or should those be moved to frotned dir as well?

lucifer: The most impacting change was about (recording/release/release-group) first release date.

I reckon it could all go into frontend, along with the package.json etc. Which means node_modules would also end up in there and need to be ignored

lucifer: I will try previous versions and see. But I wonder if there would be a way to make SIR freed its memory sooner after having built some index entries.

yvanzo: that was the intent of reducing query batch size. but that made it crash even faster. can you try with query batch size of say 1000?

we didn’t reduce it, we increased it

oh wasn't it 50000?

no, 5000 :D

oh its 50000 on wol

*wolf

yes lets try on 2500 then

🤦

lucifer: here is the reference for mirrors: https://github.com/metabrainz/musicbrainz-docke...

makes sense. thanks!

alastairp: Do we even need to save the generated image? We could use our regular art API routes with an extra image format option and just use a py library to generate a PNG on the spot and return that?

monkey: right, saving it is just an optimisation trick. if it's fast (<0.2s?) then we could generate on demand each time

I think those rotes would be very useful for embedding

routes

Currently embedding the SVGs is a tiny bit tricky

The text-based ones would be fast, the cover art based ones less so

But on the plus side, we wouldn't be storing any © material anywhere since they're generated on the fly and sent

lucifer: makes more sense :) hopefully not crashing yet, SIR memory usage seems to stay under 3GB :)

nice!

I’m logging docker stats every few seconds so will have more details once it stopped (on completion or crash).

my experience is that _always_ generating things on demand is a bit of a waste of resources, especially if it takes some time