btw did we have further discussions on the manual mapping for the missing musicbrainz data at lb? Once discussed I can start working on it (since I have already opened a PR for missing musicbrainz page and its being reviewed). I believe we roughly discussed how to go about it, but we went over the implementation detail vaguely
lucifer ruaok alastairp
ruaok
I'll have to think more about this; I have nothing yet.
riksucks: the last time ruaok and i discussed, we concluded to not do manual mapping for now. therfore, i think the best way forward would be letting users hide tracks they know exist in MB.
ruaok
well, part of that discussion was motivated by us having too much on our plate already. but if riksucks wants to work on it, then maybe we should think about it.
I kinda want to see the missing MB data inaction before going much further, though.
lucifer
if we decide to go ahead with letting user's hide tracks from missing mb data then i have a few implementation ideas in mind.
i agree but think we do need a way to let users delete stuff from missing mb data stuff.
ruaok
yeah. messy though.
lucifer
waiting for the next week for that to happen (if they add stuff) might be annoying and letting the delete stuff can help in avoiding them to add dupes.
yeah its messy indeed.
ruaok
or perhaps we never show anything to the user, except when we can identify an album that can be added...
lucifer
hmm sounds interesting but how do we identify it?
ruaok
ohh.
the album mapper work that I've put on hold until the year-end stuff is done could help.
because it can find all sorts of albums in the stream of a user.
yvanzo
reosarevok: That would probably be helpful toI thought it could be possibly worse.
ruaok
maybe that should be the source of this data.
yvanzo
reosarevok: That would probably be helpful. I thought it could be possibly worse than that.
riksucks
hmm interesting
lucifer
interesting thought. will need to look more into how it works and produces to decide that.
reosarevok
Ok, will do
ruaok
well, it finds loads of clusters and most get discarded because its tuned very tightly.
but we could examine the middle ground of matches -- the things that cannot be looked up, but appear more of less to be a complete album.
but in general I dont feel like I have the bandwitdh to think about this project until the year end stuff is done.
lucifer
agreed. let's regroup on this once that is done.
riksucks
Fair point, till then I would implement the part 2 of LB-912, since I am now familiar with frontend work, I will implement the frontend of the endpoints I created.
Also, I feel like, understandings how mappers work is a pre-requisite when going about solving this problem later on in future. So I might study the mappers so that I can help once we come up with a solution?
but for pre 2018 listens, it looks like created is set to epoch 0 and so the where clause excludes it.
yvanzo
alastairp: indeed :D
alastairp
yvanzo: to add to this, we've been talking about adding more documentation to LB, and we decided to host it on https://listenbrainz.readthedocs.io/ in a specific "information for maintainers" section
lucifer
hmm, my recollection was that we decided to order full dumps on listened_at and incremental dumps on created but i may be wrong ...
alastairp
so we'll have "info for API users", "info for people who want to develop on LB", "info for MeB team but which can be public"
yvanzo
and in syswiki "info for MeB team but which must stay private"
aerozol has quit
lucifer
uh ok, this method is used by both full and inc dumps. need to fix that too.
[musicbrainz-server] 14reosarevok merged pull request #2311 (03master…MBS-12001): MBS-12001: Use allowNew for recording links when adding a new track https://github.com/metabrainz/musicbrainz-serve...
reosarevok
Agreed :)
ruaok
lucifer: oh shit, yes. totally forgot that we added created in 2018 and thus we're missing that data.
lucifer
ah! makes sense.
ruaok
what is we copy listened_at > created for all pre-2018 listens?
*if
lucifer
i think doing full dumps on listened at and inc dumps on created as we intended to do anyways should fix this.
ruaok
because created doesn't really matter for things in the past.
do you have specific AB features that you think you might want to use?
BPM and Key are big ones
lucifer
dont have specific ones in mind currently. was thinking to look into the AB ipynb labs stuff and find something interesting
alastairp
as part of the dumps (but perhaps not directly integrated into the code) we should be able to dump `mbid, offset, submission date, bpm` into a single file. No need for incremental, just do a full dump each time
this is a long pending task anyway, so if you want to take that on in order to get the data that'd be great!
lucifer
sounds good. i'll take a look into the PR and get back to you.
alastairp
don't worry about spending too much time reviewing the PR - if you can do the single-feature dump easily without getting bogged down in the existing code, that might be good
maybe run some tests on bono to see how feasible it is to dump all features for 20m rows in a single query, or if we should split it up
(I'm just unsure about how much postgres will care digging into a json document. I guess we're already doing similar queries in the LB listens table and it doesn't care, perhaps I'm over-thinking this)
tandy1000
would musicbrainz ever incorporate AB to do genre guessing?
that way people who tag music with MB have the option to use guesses when there isnt any info
alastairp
tandy1000: yeah, if we can get our genre models to work better that'd be great
tandy1000
niceee
alastairp
I believe that picard also has this option to use AB data, but it's .... not good
well, some of it's not awful, but much of it is terrible
tandy1000
dam lol
CatQuest
monkey: eh. my vertical screen estate is minimal. my horizontal one is LARGE (re brainzplayer)
in general i'd liek if we could chose to have botom or sidepanel?
monkey
That's something we might think about in the future, the problem being that some pages just aren't made to have a player in them, but we still want to be able to play music$
