ruaok: if a user listens to same artists for more than one week, there is a great possibility that recs for that user will repeat in those weeks. We should find way to store recs for a user for a week so that we don't recommend the same playlist the next week.
Pragya has quit
alastairp
pristine___: hi, we talked about that a bit a few weeks ago
we thought that it'd be a good idea to add a metadata field to listens that says where the play came from, in this case BP (for example) could set that field, and we can use it to omit it from recommendations
good observation!
pristine___
alastairp: hmm... And we should also decide on after how many days/weeks we want to include that track to recs again, I mean we won't omit the track from recs forever.
alastairp
one option is to not count it when it's played directly from a recommendation. One would expect that if someone goes back and listens to it, that's because they like it, and that play should count as an include
that is, use the play counts as the _input_ to the model
I'm not sure about post-processing the output. Perhaps we could exclude tracks if they were recommended the week before, and that's it
pristine___
I liked the idea of excluding them if recommended a week before (or two or three). Even if a user like the recs, I think they won't prefer to have it recommended soon, people usually look for *new* or forgotten stuff in recs.
pristine___: are you sure about artists repeating? Can you confirm that?
Between, filtering out recently listened artists and the inherent nature of how we feed data to CF, I am not sure about this.
Also, we already have a way to keep track of what recordings have been recommended to a user -- we planned for this. If this is a confirmed problem, then let's start using that table.
TOPIC: MetaBrainz Community and Development channel | MusicBrainz non-development: #musicbrainz | Channel is logged; see https://musicbrainz.org/doc/IRC for details | Agenda: Reviews, GSoC changes (Freso), [no label] subscribers (reo), Heads up re: next meeting and DST (Freso)
Mr_Monkey
_lucifer: No, BP doesn't use Media Session, but I guess it should eventually !
ruaok: filtering about recently listened artist? I am not sure what you mean. We filter out (remove) the tracks listened to by the user in the last week from candidate set.
Out*
ruaok
Yes, that.
I think we should observe this, but not really plan to take action yet.
Let's collect more data.
pristine___
So why I say this? We train model on last six months, or x months, now let's say in listened to tame Impala for 2 consecutive weeks, the tracks of tame Impala in the listens of past x months with kinda remain constant, so the candidate set for me of the consecutive two weeks will most likely have same tracks of tame Impala and therefore making it to my recs.
But yeah, we need more data
I will prepare it
ishaanshah: hey, when will the increment dump for today get uploaded to HDFS I mean I want to listen to a track now and then I want it to be in spark cluster asap, so will it be there by tomorrow?
So I am listening to a song rn, it is shown as `playing_now` in `my listens` but not in `recent listens`, is this expected?
antlarr has quit
antlarr joined the channel
reosarevok
Is it already past 30 s or whatever it is that confirms it?
[listenbrainz-server] ishaanshah opened pull request #1147 (master…import-tracking-fix): [WIP] Fix bug in code for tracking imported data into spark cluster https://github.com/metabrainz/listenbrainz-serv...
ishaanshah
> ishaanshah: hey, when will the increment dump for today get uploaded to HDFS I mean I want to listen to a track now and then I want it to be in spark cluster asap, so will it be there by tomorrow?
yes it should be there tomorrow.
However we stopped the daily import temporarily as there was a bug in the code which lead to multiple imports
iliekcomputers ping
c1e0 joined the channel
c1e0_ has quit
yvanzo
bitmap, reosarevok: Draft blog post is ready for review :)
pristine___
ishaanshah: then how will it be there tomorrow? Full dump?