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.
pristine___
_lucifer: one for normalizing input and other for normalizing score. Maybe merge both in one.
> 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?
Mr_Monkey
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.
pristine___
ishaanshah: did you get some recs of Lauren Jenkins in top artist playlist?
ishaanshah
Nope its mostlu Carly Rae Jespen
mostly*
pristine___
Link?
iliekcomputers
ishaanshah: didn't get a chance yet, can you post it again, I'll read it after work today
ishaanshah
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
_lucifer
pristine___: also what are your views on adding a fake user, which has a listen count of one for recording in mb?
pristine___
ishaanshah: maybe because she wasn't in the mapping, I will have a look
pristine___: no that may help in increasing diversity of recs
ishaanshah
just wanted to makes sure we are on the same page
pristine___
Can you explain how?
_lucifer
shivam-kapila: was just joking :)
bitmap
yvanzo: no response that I can see
yvanzo
is CSP worth a separate ticket?
iliekcomputers
ishaanshah: thanks
bitmap
yeah, let me finish creating that
_lucifer
pristine___: that would ensure that all recs in mb are present in the source dataset
ishaanshah
> 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,
pristine___
_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.
_lucifer
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
pristine___
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.
_lucifer
yup, that's the rough idea. we can sketch the implementation details later
pristine___
_lucifer: right. Can we fix a meeting this week (weekend maybe) or later to get a plan for this.
_lucifer
sure pristine___ , let me know what time/day works for you
_lucifer system is unable to handle android studio load any longer so he will work on other *brainz till he gets a new system
pristine___
_lucifer: weekend, preferably Saturday. I hope my fever goes away be then :(
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?
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.
yvanzo
reosarevok: tested and made comments
reosarevok
Thanks, will see
Oh damn, just saw it fails a test too :) Will fix in a bit
bitmap
yvanzo: maybe you can commit the change to hourly.sh to the PR too?
or if it only takes 4 days never mind
yvanzo
yup, it only takes 4 days
(or it keeps timing out forever ;)
bitmap
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
yvanzo
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
> 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.
yvanzo
bitmap: thanks, kept it as a separate commit since it seems worth noticing it.
pristine___
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
ruaok
remember my comment about not being to follow the flow of data through the system?
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:)
ruaok
:)
nelgin has quit
nelgin joined the channel
_lucifer
pristine___: couldn't find any old ticket. (maybe i had forgotten to open one) so i opened this LB-725