aerozol: likely out of sync clocks. we allow listens upto 10mins in future to account for clock skew iirc.
2022-11-07 31127, 2022
aerozol
I thought that would be the case! I like that we have the text for it and everything :D
2022-11-07 31138, 2022
aerozol
If people get annoyed about it later we could lazily swap all the future text for ’now’ (but I don’t mind futurebrainz personally)
2022-11-07 31125, 2022
kaine2 has quit
2022-11-07 31142, 2022
kaine2 joined the channel
2022-11-07 31146, 2022
trolley joined the channel
2022-11-07 31105, 2022
trolley_ has quit
2022-11-07 31109, 2022
trolley has quit
2022-11-07 31126, 2022
trolley joined the channel
2022-11-07 31119, 2022
yvanzo
O’Moin
2022-11-07 31142, 2022
aerozol
Evening!
2022-11-07 31107, 2022
aerozol
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?
2022-11-07 31114, 2022
aerozol
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
2022-11-07 31105, 2022
aerozol
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
TOPIC: MetaBrainz Community and Development channel | MusicBrainz non-development: #musicbrainz | BookBrainz: #bookbrainz | Channel is logged; see https://musicbrainz.org/doc/IRC for details | Agenda: Reviews, RG cover guidelines / intent (reo/aerozol)
2022-11-07 31150, 2022
aerozol
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.
2022-11-07 31108, 2022
aerozol
I am off for the evening, but feel free to leave nice messages for me x o
[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-server/…
2022-11-07 31100, 2022
lucifer
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.
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_rel…
2022-11-07 31157, 2022
alastairp
lucifer: ah, great. nice catch
2022-11-07 31159, 2022
alastairp
morning
2022-11-07 31116, 2022
alastairp
interesting to see that it's so slow on wolf (although we understand that parts of this server are slow)
2022-11-07 31141, 2022
alastairp
I can do a full MB index on my dev machine in about 2.5h (although that's with old sir)
2022-11-07 31104, 2022
yvanzo
lucifer: When testing your commit for using selectinload, I inappropriately compared with v3.0.1; I’m retesting master HEAD to compare with.
2022-11-07 31111, 2022
CatQuest
oh! I thoguht it was "filmi sangeet"
2022-11-07 31110, 2022
lucifer
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?
2022-11-07 31135, 2022
lucifer
alastairp: makes sense, thanks
2022-11-07 31122, 2022
yvanzo
lucifer: ~1h on my test VM but it really depends on the resources you can dedicate to it: it's probably faster on wolf.
2022-11-07 31158, 2022
lucifer
i see. i'll do some more runs on wolf then.
2022-11-07 31101, 2022
param has quit
2022-11-07 31102, 2022
atj has quit
2022-11-07 31103, 2022
outsidecontext has quit
2022-11-07 31105, 2022
Pratha-Fish has quit
2022-11-07 31109, 2022
akshaaatt has quit
2022-11-07 31111, 2022
ansh has quit
2022-11-07 31112, 2022
atj joined the channel
2022-11-07 31128, 2022
KassOtsimine has quit
2022-11-07 31131, 2022
mayhem has quit
2022-11-07 31134, 2022
lucifer has quit
2022-11-07 31142, 2022
riksucks has quit
2022-11-07 31148, 2022
param joined the channel
2022-11-07 31113, 2022
Pratha-Fish joined the channel
2022-11-07 31132, 2022
KassOtsimine joined the channel
2022-11-07 31136, 2022
lucifer joined the channel
2022-11-07 31138, 2022
mayhem joined the channel
2022-11-07 31102, 2022
outsidecontext joined the channel
2022-11-07 31102, 2022
ansh joined the channel
2022-11-07 31109, 2022
akshaaatt joined the channel
2022-11-07 31120, 2022
riksucks joined the channel
2022-11-07 31118, 2022
alastairp
aerozol: thanks for the reminder on that link, I've replied saying we can't help
2022-11-07 31129, 2022
monkey
chinmay: yes!
2022-11-07 31133, 2022
monkey
Hi everyone
2022-11-07 31105, 2022
monkey
lucifer: that sounds ideal to me (re: release group CAA id)
2022-11-07 31134, 2022
monkey
With preference to release cover art if the release M ID is in the original liste.
2022-11-07 31136, 2022
monkey
N
2022-11-07 31156, 2022
monkey
Thanks for looking into that!
2022-11-07 31159, 2022
lucifer
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.
2022-11-07 31149, 2022
monkey
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.
2022-11-07 31128, 2022
lucifer
the existing mb_metadata_cache so the metadata lookup endpoints that the now playing viewer uses.
2022-11-07 31135, 2022
monkey
I see
2022-11-07 31117, 2022
BrainzGit
[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
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)
2022-11-07 31140, 2022
lucifer
hmm, i not sure what you mean.
2022-11-07 31151, 2022
monkey
Let me pull up the code
2022-11-07 31102, 2022
lucifer
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.
lucifer: one of my long term goals is to have BP not have to fetch data from third party sources.
2022-11-07 31126, 2022
mayhem
in an ideal world, we can provide all the data needed... eventually.
2022-11-07 31127, 2022
monkey
1. if listen is from spotify, load cover art from there 2. Same for youtube.
2022-11-07 31127, 2022
monkey
3. Query CAA with the release MBID (from original listen OR from mapping)
2022-11-07 31140, 2022
monkey
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
2022-11-07 31156, 2022
mayhem faces monday morning with a mountain of BS tasks. sigh.
2022-11-07 31117, 2022
monkey
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?
2022-11-07 31154, 2022
lucifer
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.
2022-11-07 31105, 2022
mayhem
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.
2022-11-07 31140, 2022
lucifer
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.
2022-11-07 31105, 2022
lucifer
fwiw, in my limited testing directly accessing MB tables was quite fast.
2022-11-07 31131, 2022
lucifer
so perf would probably not be a deal breaker. ofc more testing would be needed to confirm.
2022-11-07 31132, 2022
lucifer
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.
2022-11-07 31148, 2022
lucifer
the release group mbid should however be useful for writing CB reviews.
2022-11-07 31134, 2022
monkey
For 3., yep, that's what I had in mind. Mmm, good points for 4. though, thanks. I have doubts now :D
2022-11-07 31119, 2022
monkey
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?
2022-11-07 31104, 2022
monkey
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
2022-11-07 31132, 2022
lucifer
monkey: for 4, the cache will already do the resolving CAA API does at the backend so you wouldn't need.
But then what release MBID do I use to construct the URL?
2022-11-07 31141, 2022
monkey
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
2022-11-07 31118, 2022
monkey
(A potential difference, I mean. Most of the time I guess it'll probably be the same one?)
2022-11-07 31159, 2022
lucifer
yeah there'll likely be some differences.
2022-11-07 31159, 2022
lucifer
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.
2022-11-07 31106, 2022
monkey
So perhaps a `cover_art_release_mbid` field is in order ?
2022-11-07 31113, 2022
lucifer
yup
2022-11-07 31129, 2022
monkey
OK, that sounds good now, thanks :)
2022-11-07 31141, 2022
monkey
I was wondering if I was missing something about the use of CAA
2022-11-07 31104, 2022
monkey
like using RG MBID and the release CAA id for example, but that doesn't work
2022-11-07 31141, 2022
lucifer
yeah, sorry. i forgot the url includes release mbid as well! 😅
2022-11-07 31143, 2022
monkey
Oooh, I'm excited! This is going to improve our cover art coverage significantly !
2022-11-07 31105, 2022
monkey
all good :
2022-11-07 31158, 2022
lucifer
thanks yvanzo!
2022-11-07 31112, 2022
BrainzGit
[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
