lucifer: that seems like dodgy data in Spotify, but it should still be matched I guess
bitmap
kellnerd: thanks for the updates, I'm glad things are mostly working! I'm traveling back atm but I've seen your message about the attributes issue, I just might be a bit slow to respond until I get home
will have plenty of time to look into it on the flight though
reosarevok
Have a good flight home!
bitmap
thank you!
reosarevok
bitmap: the comment under CREATE TABLE artist_release suggests we sort by catnos, but AFAICT we do not? MBS-6796 is still open and find_fast doesn't seem to use them
Wait, no, I'm being an idiot, that's _release, we don't store catnos for _release_group
We could consider storing the alphabetical first catno for all releases in the RG, I guess, if we find that's useful, but that'd be a schema change
rdswift has quit
rdswift joined the channel
Marked that ticket schema change at least
Oooh, thanks for the knockout flow
(that sounds like you're a great battle rapper now)
bitmap
lol
right, we'd need to materialize first_release_catno I guess. dunno how useful that'd be outside of this case
darkstardev13 has quit
darkstardev13 joined the channel
akshaaatt
Thanks yvanzo
akshaaatt is back in India
darkstardev13 has quit
darkstardev13 joined the channel
darkstardev13 has quit
darkstardev13 joined the channel
darkstardev13 has quit
darkstardev13 joined the channel
darkstardev13 has quit
darkstardev13 joined the channel
darkstardev13 has quit
darkstardev13 joined the channel
lucifer
reosarevok: yeah, could be dogdy data or just how they manage data internally. i think we should probably try to match if possible. fwiw, i did some counts and there are 30k such instances (having ft, feat or featuring in name) out of overall 3.3M artists.
"Among other things, it recommends using the Authorization Code flow with the PKCE extension instead of using the Implicit flow."
well, if that works, I don't see much problem with suggesting that we use it
lucifer
yup agreed.
tykling
fwiw django-oauth-toolkit most recent release changes authorization code flows to have pkce to be enabled by default, we've had no problems getting various clients to adapt to it
(we = $dayjob, nothing to do with meb)
alastairp
tykling: thanks. atj_mb suggested that we make it required, which we're going to do. we're using https://authlib.org/ + their flask library
it's currently optional in musicbrainz.or
tykling
right. it protects against some scenarios that are relevant when the auth server and the resource server are not the same, not relevant everywhere but a good thing to get standardized
alastairp
that's great actually, because this will be the case for us (I believe - resouce server: musicbrainz.org, auth server: metabrainz.org)
tykling
oh right of course, well great :D
alastairp
tykling: it sounds like you might know a bit about oauth ;) do you mind if we run some documentation/plans past you to get your feedback on it?
tykling
not at all, though I may take a few days to find time to look at it, my schedule is crazy at the moment
happy to help if I can :)
alastairp
great, thanks. we finished most of our planning doc and made a start on a test implementation last week, I'll clean up the doc and send it your way
I think I caught monkey's sniffles :(
tykling
is that like monkeypox lite
monkey
Awww, don't call it that !
:p
mayhem snickers
kellnerd joined the channel
zas
gooood moooorniiiing
I'm still astonished that cocktail bot is a legal weapon.
mayhem
legal or lethal?
zas
lethal, yes, that too.
mayhem
lucifer: have you started making troi changes yet? if not, I think I will take a stab at those later today, to get into some coding after a week of madness
lucifer
mayhem: which changes?
mayhem
click and how to load patches
or should I go check the PR list? heh
lucifer
ah yes, i did make small changes but not all. i'll open a PR later today, you can complete the rest if you prefer.
mayhem
ok, I'll wait for the PR then see.
lucifer
yes getting the spotify cache PRs merged would be nice. currently, the containers are running on custom branches.
also https://github.com/metabrainz/troi-recommendati... is open, the only missing piece for getting the minimal spotify playlist export feature in LB is adding new permission scopes and frontend changes.
the cache is more or less stable now, should we revert to spotipy main instead of the fork?
mayhem
lucifer: what is the purpose of the raw table? why can't we just insert into the normalized tables directly?
if you think that will work, then by all means, less for us to look after
lucifer
mayhem: we insert directly to main tables and as well raw. raw is only there 1) in case we discover some bug in the migration script that ported the initial 13.5M albums data 2) we want to change the normalized schema.
mayhem
but we should remove that at some point soonish, yes?
lucifer
yes makes sense. once we are satisfied with the normalized schema and seen it work in prod for some time, sounds good to drop raw data table then.
mayhem
personally, if you are already resolving playlists correctly, then I think we can nuke this, honestly.
and the data migration tools too, not need to keep that around, methinks.
*no
lucifer
so the first prototype of schema didn't have a position column in rel_track_artist so when retrieving the artist name, the names got unordered and there were some mismatches. i added the column in the second prototype to improve matches. i wonder if there are more such bugs lurking which only come up after testing on a wider array of recordings.
mayhem
ok, if you prefer that
lucifer
i'll open a ticket to remove the raw data tables so that we don't forget about it.
mayhem
k
lucifer
mayhem: oh also, when you have time later, please generate these keys: https://help.apple.com/developer-account/#/devc... . i'd like to setup apple music scraper soon so that we can start building the cache which take awhile to become usuable. meantime can work on adding listening history support.