#metabrainz

aerozol: likely out of sync clocks. we allow listens upto 10mins in future to account for clock skew iirc.

I thought that would be the case! I like that we have the text for it and everything :D

If people get annoyed about it later we could lazily swap all the future text for ’now’ (but I don’t mind futurebrainz personally)

O’Moin

Evening!

monkey: I’ve been noodling about on the ListenBrainz redesign finally, if you want to have a look in the figma. Maybe we should chat about it sometime?

I’ll dump some stuff here, any feedback welcome. I’m still very curious about how we define our target audience and what’s most important

In particular, I expect some people will find this much too simplistic, which is at odds with how we want to aim LB at a more ‘general audience’. It would be good to really lock in who we’re aiming for, otherwise we end up with a average product for both

or a mix of light and dark

With that basic menu, we would still have complexity/all the cool features, but it would be very basic on the top. Someone entirely unfamiliar with what LB (or last.fm) is would be presented with some very simple options before it gets complex. If we are aiming for a different audience we wouldn’t stack it that way.

I am off for the evening, but feel free to leave nice messages for me x o

akshaaatt, lucifer and the gang: Is "filmi" really a genre? https://tickets.metabrainz.org/browse/STYLE-2182

STYLE-2182: Filmi

("soundtrack" certainly is not, but maybe this is specific enough)

reosarevok: "filmi" music is a thing but not sure if it qualifies to be a genre.

😂😂

I’m not sure if it’s a genre

Is it just "soundtrack for any Indian film"?

Or is it specifically the dancy-bollywoody-thing? :D

the latter

And if I was to make music that sounds like that, but was not part of a film, would you still say it's "filmi music"?

probably yeah

yvanzo: hi! can you please test this commit for any performance improvements? https://github.com/metabrainz/sir/commit/ee8ea2...

logically, i think the performance should improve but limited testing on wolf shows no meaningful performance difference.

hi lucifer: on which core specifically?

is it to address the issue with recording core?

yes to address with recording core but the change affects all cores.

recording core takes over 12 hours on wolf so i had tested artist fwiw.

let me see if i can find a core that takes shorter time but has similar queries

Ok, I will test on annotation which seems to take shorter time.

Nvm, it doesn’t make sense for testing this change.

lucifer: then it sounds like a genre, thanks :)

lucifer: Tested on label, it is 3 times slower.

oh! weird. i'll take a look. thanks for testing!

[sir] 14amCap1712 opened pull request #150 (03master…area-fix): Improve performance of area indexing https://github.com/metabrainz/sir/pull/150

[musicbrainz-server] 14yvanzo opened pull request #2717 (03core-data-layer…linkable-vs-relatable): MBS-12552 (III): Move Entity::Role::Linkable to Relatable https://github.com/metabrainz/musicbrainz-serve...

monkey, mayhem: i think for the cover art in mb metadata cache. it makes sense to always use the release group cover art because the canonical release is chosen by us and release mbid cannot be specified when querying the cache currently anyway. so the frontend can query CAA for cover art if there is a release mbid submitted by the user but the mbid_mapping section will contain the release group's caa id.

[sir] 14amCap1712 opened pull request #151 (03area-fix…place-fix): Eagerly load area attributes in place indexing https://github.com/metabrainz/sir/pull/151

moin!

are you available today monkey?

alastairp: i figured why sqlalchemy was emitting multiple query statements for some relationships. sir uses subqueryload in some case which works that way. https://docs.sqlalchemy.org/en/14/orm/loading_r...

lucifer: ah, great. nice catch

morning

interesting to see that it's so slow on wolf (although we understand that parts of this server are slow)

I can do a full MB index on my dev machine in about 2.5h (although that's with old sir)

lucifer: When testing your commit for using selectinload, I inappropriately compared with v3.0.1; I’m retesting master HEAD to compare with.

oh! I thoguht it was "filmi sangeet"

yvanzo: i see. but label being 3x slow than 3.0.1 also indicates something wrong. one more thing, could you remind me how long it takes to index release group core?

alastairp: makes sense, thanks

lucifer: ~1h on my test VM but it really depends on the resources you can dedicate to it: it's probably faster on wolf.

i see. i'll do some more runs on wolf then.

aerozol: thanks for the reminder on that link, I've replied saying we can't help

chinmay: yes!

Hi everyone

lucifer: that sounds ideal to me (re: release group CAA id)

With preference to release cover art if the release M ID is in the original liste.

N

Thanks for looking into that!

monkey: yes so the cache will always have the rg cover art but the frontend can check the original listen before querying the cache so should be fine.

Which cache is that? I assume we'll have that info (RG MBID + CAA id) as part of the listen the front-end gets? Let me know when you want to do that change, I'll take care of the front-end bits.

the existing mb_metadata_cache so the metadata lookup endpoints that the now playing viewer uses.

I see

[sir] 14amCap1712 opened pull request #152 (03place-fix…release-group-fix): Improve loading release-group, release and recording https://github.com/metabrainz/sir/pull/152

monkey: https://github.com/chinmaykunkikar/listenbrainz...

Yes, that'll be the first step. I'm keen on passing the RG info to the listens on the front-end too (in the same way we add `mbid_mapping`) for easy access (it would remove a call to CAA for each listencard)

hmm, i not sure what you mean.

Let me pull up the code

the cache can directly pass the rg cover art's caa id in the mbid_mapping section. if there is a release mbid in the additional info of the listen, frontend could query CAA with it. if that comes up empty, just use the caa id from the mbid_mapping section.

Yes, that's exactly it :)

Here is how we load cover art for listens on the front-end (our regular pages, not the metadata viewer): https://github.com/metabrainz/listenbrainz-serv...

lucifer: one of my long term goals is to have BP not have to fetch data from third party sources.

in an ideal world, we can provide all the data needed... eventually.

1. if listen is from spotify, load cover art from there 2. Same for youtube.

3. Query CAA with the release MBID (from original listen OR from mapping)

We're changing 3. so that we check if original listen has release mbid (in which case do as before) but add a 4. if there is no release MBID in the original listen, use the RG MBID and CAA id from the `mbid_mapping ` in the listen

I assume as well that there will never be a case where we have a release MBID in the mapping, but no release group MBID?

mayhem: the issue with that comes back to providing the most accurate data. the mb_metadata_cache stores canonical release data only so it cannot provide the data for exact release.

I hear ya -- I am trying to describe an ideal case. may not always be possible, but we should be thinking about ways to make it possible.

i don't think it'd be possible 1 table, but we could have 2-3 more tables to serve that use case. split the release_data from mb_metadata_cache to a separate cache or just directly access MB's table.

fwiw, in my limited testing directly accessing MB tables was quite fast.

so perf would probably not be a deal breaker. ofc more testing would be needed to confirm.

monkey: for 3, instead of using `getReleaseMBID`, need to directly access `additional_info.release_mbid` but otherwise yes. for 4, you can always use the caa id. the release group mbid would be redundant for cover art purposes. as querying caa with that mbid will only get the same caa id.

the release group mbid should however be useful for writing CB reviews.

For 3., yep, that's what I had in mind. Mmm, good points for 4. though, thanks. I have doubts now :D

When you say "the mbid_mapping section will contain the release group's caa id", how does that work? Will the matched release in the mbid_mapping be the canonical release, or the release that the RG has selected for cover art?

What I had in mind was to query the CAA using the release-group MBID, and from the CAA API response get the image URL

monkey: for 4, the cache will already do the resolving CAA API does at the backend so you wouldn't need.

lucifer: I created https://tickets.metabrainz.org/browse/SEARCH-689 to track SQLAlchemy 1.4 upgrade (and related regression fixes)

SEARCH-689: Upgrade to SQLAlchemy 1.4

But then what release MBID do I use to construct the URL?

I see a difference between the MBID mapper's canonical release (which is what I expect to be in mbid_mapper in the listen) and the release that has been selected as the RG's cover art

(A potential difference, I mean. Most of the time I guess it'll probably be the same one?)

yeah there'll likely be some differences.

oh right, about the url. i had forgotten, i'll add the release mbid of the cover as well. so that the url can be constructed.

So perhaps a `cover_art_release_mbid` field is in order ?

yup

OK, that sounds good now, thanks :)

I was wondering if I was missing something about the use of CAA

like using RG MBID and the release CAA id for example, but that doesn't work

yeah, sorry. i forgot the url includes release mbid as well! 😅

Oooh, I'm excited! This is going to improve our cover art coverage significantly !

all good :

thanks yvanzo!

[sir] 14amCap1712 opened pull request #153 (03release-group-fix…artist-fix): Eagerly load area_type related attributes for artist core https://github.com/metabrainz/sir/pull/153