#metabrainz

most played artists on listenbrainz and their most played tracks:

alastairp: iliekcomputers ^^

nn all!

userbase is pretty english language biased, eh.

not complete tho, there's some european classical and japanese video game music in there heh

> I need help from someone who drinks chai

alastairp: Oh chai is love. I prefer all milk one due to its creamy taste. Ping me if you need detailed info

Also morning!!

[musicbrainz-server] reosarevok merged pull request #1515 (master…MBS-9516): MBS-9516: Support custom validation errors in URLCleanup https://github.com/metabrainz/musicbrainz-serve...

MBS-9516: Display specific error messages depending on URL validation rules https://tickets.metabrainz.org/browse/MBS-9516

ruaok: Hey. After the chat with alastairp yesterday. I was thinking if we rename the `lovehate` to `feedback`

`recording_feedback` looks better than `recording_lovehate`

also `/feedback?score=0` sounds better than `/lovehate?score=0` for api.

iliekcomputers: Why does it sound related to the doubt I asked above. lol

oh no, it's not. i think we do a pretty good job at this.

i also think `recording_feedback` is a better user facing term.

Also /love, /hate or /lovehate would be strange API

because it interfaces with spark, geddit

Wow. I certainly like that

nooooo, i was being sarcastic

but yeah, it's probably good not to have a /hate endpoint :D

Sounds tinderish.

ishaanshah[m]: the new dump seems to have fixed your artists

Yep, 🎉

Seems like dump was the issue

I will close the ticket

that's concerning. -_-

iliekcomputers how fast did the stats calculation takes place

request triggered at 06:28, all messages sent back at 06:36

the query took 390s.

Nice, thats really fast

Without any optimisation

i was talking to a friend who's been working with spark.

he said that a major source for optimization we might wanna look at is how we partition the dataframes between workers when they are loaded into memory

right now, it is possible that we have a lot of executors sitting idle because the data isn't partitioned minutely enough.

ruaok: perfect, that' looks great

anyways, i think we'll cross that bridge when we get to it, but something to investigate.

Hmm, but right now I think the bottleneck is time taken for full export

yeah.

that's a pita.

there's some real low hanging fruit there

We should optimize that or look into streaming listens as they come

But thats after gsoc ig😅

yeah. i would say let's build on the infrastructure we have right now, and then see what to do.

i've changed the cron jobs so that a new dump gets imported every week

so the weekly report thing should still work.

Yeah

did you see my comment about the API breaking if we change the code that gets the count before the new stats get written into the db?

Yeah I did

If it takes only six minutes to gen stats again

I think it would be ok if API is broken for six mins?

i guess, it's a question of tradeoff.

we've said that the endpoint is in beta, so it probably will be ok.

however, the profile page breaking for 6 min, i wouldn't want to take that downtime if we can avoid it

Or maybe I will just do try/except

And then do a further PR to remove it agin

so you'd have to write the try-except or if-else anyways.

i'd just put it in there for both of them and remove it later

yeah.

Yep, I will do that

also, i was thinking about something else

we've made schema changes to the json in the artist column. will the old data get overwritten when new data comes in? It won't linger around because the new data gets written to all_time while the old data was written to something_else.all_time?

I think it should get overwritten

But it would be better to drop the table and then recalculate

Once the new schema is in

It will definitely get overwritten

hmm, maybe truncating the table is a good idea.

but if it gets overwritten, that's cool

I believe the count was outside all_time before

So that will remain lingering

But other than that it should be fine

:/

yea, we probably should truncate it then

Can we truncate before deployment

why?

If we are gonna truncate anyways

It doesn't make sense to have try/except

true.

if the table doesn't have data, it'll give us a 204.

yeah, that sounds reasonable.

Yeah

and the profile page won't break.

I will have a look at the profile page to make sure it doesn't break

cool. can you write up a small script ala one of these: https://github.com/metabrainz/listenbrainz-serv...

Yeah, sure

cool, thanks. it's nice that we thought of deployment before the 500s :)

Yeah, threat averted😅

i was looking at jira, and it has some cool graphs (behind the mostly horrible UX): https://tickets.metabrainz.org/secure/RapidBoar...

UX is almost missing

shivam-kapila: cool, thanks. I normally drink plain black tea with only water, but I will try an all-milk chai masala today

iliekcomputers: one thing that we're missing in AB/LB is a local tool for checking flake8 errors (and an easy way to run it)

I'm not sure I want to go as far as a pre-commit hook, but we should have something as easy as tests for people to get feedback (maybe we even run it as part of tests?)

so that we can minimise these "fix pep8 errors" commits ;)

We have a lint.sh that runs prettier fixes. Something similar for Python would be nice, I agree

neat

one thing I don't like about pep8speaks is that it reads config from its own file :( would be nice to not have to duplicate this

otherwise, I was thinking of doing a single PR in AB soon which just cleans up all issues

then it'll be guaranteed that any message in a PR will be because of whoever wrote that PR

[20:42] <alastairp> I have a masala chai

[20:41] <alastairp> I need help from someone who drinks chai

alastairp: what I do is I boil water and milk and use about half'n'half

(granted I've also made it with assam-tea and all the spices from scratch :D)

thanks ZaphodBeeblebrox! It looks like it's "permitted" to try a bunch of variations and see what I like, then

The milk-water combo is all your prefs

I'm not really trying to enforce pep8 across the repository. A lot of the whitespace guidelines, for example, are nice to haves, but optional imo. a big PR doesn't really make sense in that context. The benefit of pep8 speaks for us is that it catches bugs sometimes too.

if that's the case, it might be nice to see if we can disable those warnings, then? I dunno... it seems like we should either go all-in, or get rid of what's not useful for us

otherwise we grow complacent

"oh, that's just one of the warnings that we're allowed to ignore"

ruaok> most played artists on listenbrainz and their most played tracks:

IRON MAIDEN! \m/ run to the hills \m/

Yeah, true.

I've not used autopep8 before, I'll look into it. I use pycharm to format all of my stuff anyway, so _most_ of the time I don't run into problems

But making a disable list is work :D

well, pep8speaks gives a list of codes

choose the ones you don't want, and add it...

alastairp: well I'm some norwegian cat doing it - granted I read on wikipedia about how it's "properly" done, but still :D

maybe I should try doing it all milk next time I make one 🤔

alastairp: I was joking, I'll start adding rules we ignore to our config next PR onwards.

ZaphodBeeblebrox: right. When I was with friends in India it was all milk, so I guess that's what they did in that specific area

iliekcomputers: great. do you mind coordinating about it? just to make sure we're consistent, and agree on what to ignore?

which one do you not like? Indent continuation?

bwahahaha 289181 Johann Sebastian Bach

The 2 lines after functions, but 1 line after methods

I think ours is the only time any classical - music things have been on such a list

I don't have any others rn

oh, I love that one

:(

<3 us

I mean, I guess I just got used to it after pycharm complained so much

bach above madonna! who would have though :D

...

...