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?
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...
jasje joined the channel
jasje has quit
piwu9 joined the channel
DjSlash has quit
piwu has quit
s1b1 has quit
piwu9 is now known as piwu
DjSlash joined the channel
jasje joined the channel
s1b1 joined the channel
jasje has quit
jivte joined the channel
jivte has quit
lucifer
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.
vibhoo_24 joined the channel
vibhoo_24
hi @lucifer...I tried exploring the listenbrainz website locally and I also tried learning docker basics.Should I start working on some bugs?
lucifer
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
vibhoo_24 has quit
tykling has quit
vibhoo_24 joined the channel
vibhoo_24 has quit
tykling joined the channel
Rishabh joined the channel
strider has quit
strider joined the channel
v6lur joined the channel
v6lur has quit
mayhem
lucifer: yes, I think that is right. lets try that.
Rishabh has quit
monkey
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…
Oh, quite interesting. I knew Twitter was the least likely to support svg..
monkey
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
On today's episode of "reosarevok tries something dumb, finds it's allowed"
monkey
lol
reosarevok
aerozol: is it vandalism if you respond to everything with the eggplant emoji? :p
monkey
An infinity of monkeys with an infinity of keyboards…
lucifer
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.
monkey
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
There are more, but none that we can act on right away I think.
So green light ! :)
lucifer
right makes sense
should i open a PR or are you on it?
monkey
Please do :)
lucifer
👍
thoughts on name the new folder `listenbrainz-frontend`?
monkey
What about just `frontend`? Not like we're likely to have other front-ends in there
lucifer
makes sense
monkey
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.
Maxr1998_ joined the channel
lucifer
if we take 0.5MB per image * 10k users at max, ~5 GB storage needed.
Maxr1998 has quit
alastairp
monkey: what does pngcrush do to that png?
(hi, good morning)
monkey brews
monkey
Hi!
mayhem
lucifer: yes, sounds right.
monkey
alastairp: Good call. 550 -> 400 Ko
alastairp
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
lucifer
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?
mayhem
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)
lucifer
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.
Horace Andy is a member of massive attack. He should not be in the results.
Elizabeth Fräser and Robert de nala too
lucifer
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.
monkey
> 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
alastairp
there's a meta tag for the card image, right?
lucifer
yes
yvanzo
lucifer: not really any effect, as mentioned yesterday.
lucifer
yvanzo: oh, crashed again?
yvanzo
after about the same time with about the same amount of memory
lucifer
i see. makes sense
monkey
alastairp: yes. Are you thinking of using the image URL to build on demand?
lucifer
yvanzo: thoughts on what to do then? since 3.0.1 also crashes with same amount of memory.
alastairp
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
monkey
Right.
alastairp
monkey: but I would only suggest that if we think it's infeasible to pre-generate and store for all users
monkey
I suppose image generation would be quick enough to actually serve the image the first time around?
alastairp
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
lucifer
how long would we want to keep this around? 1 year, forever?
monkey
I think a mechanism like that would make sense, especially if we want users to be able to generate images for other stats
lucifer
this image will always be needed or just the first time the social media site renders the card?
monkey
i.e. useful for the OG meta tags, but also for "share your top 10 albums" feature
alastairp
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
lucifer
i see, maybe there's something in the spec but will have to check.
yvanzo
lucifer: It’s weird indeed. It used to work with these settings though. It even used to work on less powerful development stations too.
lucifer
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?
yvanzo
lucifer: The most impacting change was about (recording/release/release-group) first release date.
monkey
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
yvanzo
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.
lucifer
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?
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?
alastairp
monkey: right, saving it is just an optimisation trick. if it's fast (<0.2s?) then we could generate on demand each time
monkey
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