ruaok: Ig matchable should be only used for look up (join), but for getting distinct etc we should use mbids or some id which we know is distinct.
2020-10-22 29619, 2020
CatQuest joined the channel
2020-10-22 29633, 2020
ephemer0l_ joined the channel
2020-10-22 29638, 2020
pristine___
ruaok: we can fetch all the top artists listen to by the user in the last week, the user most probably likes these artists, we can then fetch the top artists similar to these artists and that will be the candidate set for a user.
2020-10-22 29634, 2020
pristine___
ruaok: where have you copied the recs? I forgot :( I just see mapping dump in my account on new leader.
2020-10-22 29618, 2020
pristine___
iliekcomputers: can you please have a look at #1115? I see you have requested changes in there. Let's merge it once you approve.
2020-10-22 29627, 2020
D4RK-PH0ENiX has quit
2020-10-22 29610, 2020
D4RK-PH0ENiX joined the channel
2020-10-22 29627, 2020
_lucifer
>pristine___: on lemmy in /home/pristine is recommendation.cf_recording.sql.bz2
We are first fetching all the recording mbids associated with a user. From those recording mbids we are looking for the ones which are supplied as an argument, the recording_list
2020-10-22 29656, 2020
ruaok
why is it more complex than `select * from recommendation_feedback where user_id = u and recording_mbid in (...)` ?
2020-10-22 29623, 2020
pristine___
Yeah, I used IN operator but there was an error, which seemed to me like a list/array issue.
2020-10-22 29638, 2020
pristine___
Thanks for the feedback will try to simplify :)
2020-10-22 29616, 2020
ruaok
yes, lets debug the IN issue -- this query is asking for trouble -- we should make it as easy as possible, which is likely to be the fastest way.
2020-10-22 29632, 2020
ruaok
reconstruct the query with in and then post the error, we'll sort it out.
I suspect that test will only help a bit and we will only get proper feedback from at the earliest beta, but
2020-10-22 29641, 2020
zas
yvanzo: ok I'll have a look. Does musicbrainz-docker instance contain solr too? For collecting metrics using telegraf access to port 8983 is needed (of course exposed port can be different, that's the internal solr one). Perhaps there's some access control too to take care of
2020-10-22 29643, 2020
yvanzo
reosarevok: feel free to edit the test db directly to test anything you want to.
2020-10-22 29658, 2020
yvanzo
zas: yes, it would be nice to use a different port. that would be for use on a dedicated cloud node.
2020-10-22 29644, 2020
yvanzo
ruaok, zas: about creating the musicbrainz-docker test node, we need 160GB disk space, would a dedicated CCX21 instance be ok?
2020-10-22 29652, 2020
zas
ccx21 is expensive, does it need dedicated vcpu? CX41 could do I think
2020-10-22 29629, 2020
zas
how much memory does it need?
2020-10-22 29642, 2020
yvanzo
16GB
2020-10-22 29656, 2020
yvanzo
the purpose is to test server load, if CX41 works for that purpose, go for it
2020-10-22 29629, 2020
zas
Imho we can try CX41 (4 non-dedicated vCPUs, 16gb ram, 160gb storage) for half the price of CCX21, at worse, we'll upgrade
2020-10-22 29609, 2020
yvanzo
works for me :)
2020-10-22 29656, 2020
yvanzo
(server load when reindexing)
2020-10-22 29615, 2020
alastairp
hi zas, I have a similar request to yvanzo, to add stats to granfa, remember our discussion from some months back about reading json stats over http from listenbrainz?
2020-10-22 29625, 2020
alastairp
if you have some time either this week or early next week could we test this?
2020-10-22 29614, 2020
zas
sure, we release a new version of Picard today, what about tomorrow around same time?
2020-10-22 29651, 2020
alastairp
perfect, thank you
2020-10-22 29611, 2020
alastairp
is there a repo with telegraf configuration that I can look at myself? (I had a look but didn't find anything obvious)
2020-10-22 29602, 2020
alastairp
iliekcomputers: hi, I guess you won't be around for LB this time tomorrow, but if you have time after work today we could release my LB PR on test so that stats are ready for capturing tomorrow
