ruaok, monkey, alastairp: ^. i got my spotify data using export. unimpressed to say the least. the listened at timestamps have been rounded to minutes, the times are in timezone specifc but the timezone is not mentioned. 😞
hmm, spotify says these times should be in UTC but I am unsure.
although not as good as expected, i guess we could still make it work. accuracy to minutes is probably better than not having the data at all.
ruaok
mooin!
lucifer: inaccurate timestamps lead to duplicates later on if anything changes. not very good at all.
lucifer
ruaok: yeah, timestamps in minutes are not good. and its hypocritical that they round it off to minutes because their apis offer the same info for the recent listens in millisecond precision.
ruaok
ding.
lucifer
for now, i have mailed them and asked for the "extended streaming history" option. not hopeful, but let's see what they provide this time.
ruaok: i was looking into integrating more players in BP. apple music, soundcloud and deezer come to mind. soundcloud is currently not accepting new applications. i am unsure how many users deezer has. since meb alredy has a dev account with apple, i am thinking of integrating it next. one part would be using it as a play source and the other recording listens. thoughts?
ruaok
agreed 100%
lucifer
👍, i'll look into apple docs and find out what creds we need for it.
ruaok
if you're looking for new things to do, I'm still very much in the market for the artist_similarity.... that could help a number of things...
lucifer
i was thinking of doing that last week. i was stuck at how to make recording and artist similarity coexist. because lb side creates and destroys tables. either we generate both at the same time and send as a part of the same message. or we add the start and end marker messages to create/replace tables.
ruaok
what if we stored them in a different table and had different messages?
lucifer
yup that's also possible.
ruaok
seems like the less invasive way of doing it
lucifer
agreed. will add a separate table
ruaok
sweet. that Is the only thing that might get the annoy indexes to produce anything useful. genre/year won't do it.
:crazy: "Let me reveal with MusicBrainz identifiers"
also, the similarities are higher. in the recording case for you, those fall steeply after the first user. here, those are still high.
ruaok
very intersting. let me listen to this new top user
lucifer: I dont think I like it. Listened to 5-6 tracks of the top users tracks and I had to skip most so far.
yeah, not good. I feel the recording one is better
lucifer
ruaok: i see. note that this user is in recording similarity too, but lower in the list ~15 rank.
ruaok
where I would expect this user to be, so that feels right. there are some things this user listens to I like, but rather fewer.
lucifer
maybe try some other users also?
ruaok
I know the other users. let me try 93andresen, new to me
lucifer
yeah makes sense. recordings are a more granular match imo. but i wouldn't mind having artist similarity around too especially for users that have low recording similarity matches.
ruaok
I pondered that.
if we have both, we could also play with combining them. or letter users give us feedback on which they prefer.
ruaok closes tab
yeah, no. really not feeling the artist based list.
the query used to select listens for this similarity.
ruaok
clever!
ok, I just wanna listen to the top tracks of JAnguita, but I'll move on and look at others.
lucifer: this is pretty good. I think we should deffo keep both
lucifer
both as in recording and top artist similarity?
ruaok
also, I wonder if we should try interweave both types based on local or global similarity
yes
lucifer
sure that's possible. i guess we could combine both lists keep the row with higher global similarity if a user is in both lists. order on local similarity or global similarity? we don't assign ranks on similarity so either way should be fine.
ruaok
I think we should try both and see how they shake out.
lucifer
sure, i'll work on getting this in LB and then we can work on combining both.
ruaok: monkey: i think even if we don't use it for playing stuff, having the recording mbids around would be a good idea. because everything else in LB has a recording mbid or a msid that is linked to a mbid.
monkey
One issue I can think of is that some of the front-end functionality detects the presence of a recording_mbid, such as pins, recommendations, "open in MB", (soon) love/hate feeback, etc.
Which might lead to some unintended side-effects
lucifer
i see that can be a issue indeed. we can keep recording mbid and work around that but not worth the trouble imo. i'll remove recording mbids.
monkey
I'd say if you do think of a use for the rec_mbids on other entities we can think about how to go around that. A simple field prop on the listenCard (an "artist","recording","release" enum for example) could be an easy way.
lucifer
yeah agreed. the issue i do not have a use case for recording mbid :) just adding it in case we need it in future.