#metabrainz

I'm not exactly sure what iliekcomputers had in mind in terms of text but at least we should make sure that we are calling the Spotify API with the 'right' arguments. I would recommend to start by reading the code for the `searchForSpotifyTrack` method and understanding what happens in it.

Then, you'll want to create a test that makes sure that if I call searchForSpotifyTrack with `("mySpotifyToken123", "a beautiful track name", "dope artist", null)`, the Spotify API in turn is called with the right arguments. You'll want to make sure a call is made to `https://api.spotify.com/v1/search?q=track:a%20beautiful%20track%20name%20artist:dope%20artist&type=track`, with the right spotify token passed in to the

Authorization header.

_lucifer: one for normalizing input and other for normalizing score. Maybe merge both in one.

searchForSpotifyTrack can be found here: https://github.com/metabrainz/listenbrainz-serv...

> ishaanshah: the best option is to use a bigger pool of data like mhld or something. People seldom want to search manually for tracks even if they have a recommend artist ig

Hmm, makes sense, thanks for clarifying my doubts and good job on the recs :tada:

iliekcomputers: did you have a look at the doc i posted yesterday?

abhinavohri: And anywhere you see a condition in the code (like `if (!spotifyToken)`), you'll want to add a spearate test to make sure eveything works as it should.

ishaanshah: did you get some recs of Lauren Jenkins in top artist playlist?

Nope its mostlu Carly Rae Jespen

mostly*

Link?

ishaanshah: didn't get a chance yet, can you post it again, I'll read it after work today

ishaanshah: the best option is to use a bigger pool of data like mhld or something. People seldom want to search manually for tracks even if they have a recommend artist ig

pristine___: also what are your views on adding a fake user, which has a listen count of one for recording in mb?

ishaanshah: maybe because she wasn't in the mapping, I will have a look

*all recordings

iliekcomputers: https://www.dropbox.com/scl/fi/qjwgayhyubn3rr1s...

_lucifer: that will help in normalization?

woah _lucifer. calm down

its just a rough guideline rn

Have a lot to flesh out yet

pristine___: no that may help in increasing diversity of recs

just wanted to makes sure we are on the same page

Can you explain how?

shivam-kapila: was just joking :)

yvanzo: no response that I can see

is CSP worth a separate ticket?

ishaanshah: thanks

yeah, let me finish creating that

pristine___: that would ensure that all recs in mb are present in the source dataset

> ishaanshah: maybe because she wasn't in the mapping, I will have a look

yeah maybe, the theres very less data abt her on MB,

_lucifer: I love this idea, maybe we have to tweak the listen count of fake user. I mean it will be similar to all or may be non, given listen count will be same for all recordings.

i am actually thinking once the data is normalized, the rating for all recordings of the fake user can be set to the mean value of the scale.

yeah pristine___ right

We will have to do some trick like the one you mentioned _lucifer because in any case we will have to use LB listens, because that's the aim, user listening history.

yup, that's the rough idea. we can sketch the implementation details later

_lucifer: right. Can we fix a meeting this week (weekend maybe) or later to get a plan for this.

sure pristine___ , let me know what time/day works for you

_lucifer: weekend, preferably Saturday. I hope my fever goes away be then :(

works for me. get well soon :)

ishaanshah: http://bono.metabrainz.org:8000/artist-mbid-loo...

Lauren not in the mapping :(

_lucifer: yeah, and it will great if you could have a basic idea of the general flow. You can ping me anytime for that

thanks!, i'll study the working of listenbrainz-spark before the weekend

pristine___: If you dont mind then I would also like to help with recs

join in shivam-kapila :D

shivam-kapila: hey

So do you know about missing musicbrainz data?

Endpoint

yep

that shows data in LB thats not in MB. Right?

Right. So it mostly (almost all the time) gives data which is in LB but not in the *mapping*

We initially thought it will give us data that is in LB and not in MB

But ishaanshah and I verified, that's not the case

The recs rn aren't diverse because of the restricted mapping and data source, if we improve the mapping, it will be a great thing

Every week the endpoint is updated with new data

hmm

That is in LB but maybe not in mapping or maybe not in MB

So I was thinking, if we could use it wisely to improve the mapping

I think here.

ruaok: knows in detail about it, but it is something I really want to do :)

bitmap: I sent him another mail just about crediting in blog post (won't disclose otherwise).

pristine___: and how should the missing data to curate mapping

shivam-kapila: I have no idea about it rn, I was thinking to research on it this weekend but since you pinged I ......

:p

gotcha

[musicbrainz-server] reosarevok opened pull request #1705 (master…MBS-11094): MBS-11094: Don't block editing on pre-existing too early format https://github.com/metabrainz/musicbrainz-serve...

MBS-11094: Edit error message appears (and prevents update) unrelated to current edits https://tickets.metabrainz.org/browse/MBS-11094

^ this one is a recently introduced bug (aaand my fault)

bitmap, yvanzo: not sure if important enough to put it out today already

@Mr_Monkey ok thank you.

Let me know if you run into issues getting set up :)

Mr_Monkey: ok.

pristine___: do you have some examples to hand of things that are not in the mapping but should be?

if I had more concrete examples to work with I can take another stab at improving things

reosarevok: it doesn't show up at all, neither warning nor error

reosarevok: tested with setting release year to 1017 on http://localhost:5000/release/0ce274e3-3b89-4d1...

yvanzo: we currently lack a year for 12" vinyl

Set it to CD, or just Vinyl

(another step we need to work on is finding years for stuff we're missing, but :) )

Thanks but how do you test it actually since creating wrong releases is not allowed?

There's one example in the ticket

reosarevok: it's not in sample data

Oh

In that case, I'd just turn the error off, add the release, then readd it

or you could update it in the DB directly

There's also a report for releases released too long ago

If you have some in there, they might fulfill the requirements

yup, just wonder how you did test it then.

testing with another ticket: http://localhost:5000/release/6f1a307c-aa9a-42a...

ruaok: mbids corresponding to these msids should be in mapping

That's the only data I have rn, what kind of data/format will help you

Let me know, I will try to send it from spark

that's a pretty solid answer, thank you. :)

pristine___: I suspect a bug someplace

item #2 from https://beta-api.listenbrainz.org/1/missing/mus...

yvanzo: with pink :)

I can't submit edits, but I don't need to either

ruaok: is the mapping used by bono and on FTP same? I see the mapping ok FTP was last updated on 30 June 2020 and that is what we are using in the spark cluster?

On*

yvanzo: I requested a few minor changes https://github.com/metabrainz/musicbrainz-serve..., it seems okay otherwise

ishaanshah: left a few comments on your doc

ruaok: Also, the bono check mapping using artist and recording name, and the script uses recording msid and artist msid to check that, I am not sure if it can be one of the reason for mismatch. Just thinking out loud.

reosarevok: tested and made comments

Thanks, will see

Oh damn, just saw it fails a test too :) Will fix in a bit

yvanzo: maybe you can commit the change to hourly.sh to the PR too?

or if it only takes 4 days never mind

yup, it only takes 4 days

(or it keeps timing out forever ;)

was thinking in case we have to redeploy the container, but

the e.id thing seems to make some of the queries run orders of magnitude faster

well, we could run it on an old replicated database to get those 230K edits

that can be made any time later on though

> ruaok: mbids corresponding to these msids should be in mapping

ahhh, yes. I've been waiting for today.

pristine___: ^^

I've been trying to explain to you that you should NOT be using MSIDs for mapping.

but STRINGS. this is why I put MATCHABLE strings into the mapping.

I've tried to explain this to you a number of times, but have never succeeded.

bitmap: thanks, kept it as a separate commit since it seems worth noticing it.

ruaok: Yeah, but you didn't comment on the join when I opened the PR. That's more relatable. Things slip otherwise :(

Anyway, I will open a PR for this

remember my comment about not being to follow the flow of data through the system?

No.

this was the result of that comment https://github.com/metabrainz/listenbrainz-serv...

ruaok: Right. But things if not said for long are assumed I guess. My situation is also kinda similar. Things aren't that clear since lot of data is involved, everyday we find out new bugs. But yeah, I guess I troubled you a lot in understanding things. Will keep in mind:)

:)

pristine___: couldn't find any old ticket. (maybe i had forgotten to open one) so i opened this LB-725

LB-725: Normalize recordings of input recordings dataset https://tickets.metabrainz.org/browse/LB-725

_lucifer: oh! No problem :)

(title was incorrect, fixed now)

Thanks:) and thank you for that fake user idea <3

np :D

pristine___: one comment with some questions on community...

It’s International Monday of Peace!