#metabrainz

Hi lucifer! I left a comment on https://github.com/metabrainz/listenbrainz-serv... if you could take a look :)

(Huh i'm not receiving irccloud ping notifications on mobile anymore?)

jasondk: i see. playable reviews are probably a good idea. but we want to store the data in CB, because its makes more sense, to promote it and MB can access it without any change on their side. plus, we get revisions for free when using CB. on LB, it'd either delete and write a new one or reimplement much of CB in LB.

maybe we could have CB api accept a metadata field to store mbid and stuff needed for making it playable in LB?

OK, that makes sense. I can look into doing that

We can modify CB api to include listen metadata for mini reviews.

lucifer: I have submitted a PR for LB-912 whenever free

LB-912: Add endpoints and UI to delete feed events https://tickets.metabrainz.org/browse/LB-912

yeah, that's the easiest way imo but lets wait for alastairp, ruaok and monkey and see what they think.

riksucks: will do

Thanks CatQuest, I am well aware of the previous community discussions :P I'm guessing the email address is support@musicbrainz.org, I'll flick one off. I really couldn't find it anywhere :/

[musicbrainz-android] 14akshaaatt opened pull request #94 (03master…dark-mode): Dark / Light Mode https://github.com/metabrainz/musicbrainz-andro...

Where my Light mode fans at?

lucifer up for an android release? 🥳

aerozol: the email is in the contact us link ;)

(but that's an older version that works too)

akshaaatt[m]: sure, will take a look soon.

[listenbrainz-server] 14hrik2001 closed pull request #1606 (03master…LB-912): added delete event functions and rudimentary API https://github.com/metabrainz/listenbrainz-serv...

lucifer, jasondk: Hi! Granted I only feel half awake, but after rereading the comment on PR #1605 and the messages here I still don't really understand what the question is. Is it the lack of MBID that is the issue?

Ah, looking at what the CB API returns, I guess we're missing some metadata to play reviews on LB, such as title/artist. Is that the issue?

morning

moooin!

ruaok is deff naturalised espania citisen. it's 30 minutes to middday and he's all "mooin!" :DD

hey, there's still 2 or 3 hours until midday!

moin is not an expression of "good morning". Moin is an expression for sailors, wishing you good wind for sailing. it is apporpriate to say moin at any time of day.

and then mafternoon starts in 4 minutes. afternoon in 2 hours 4 minutes.

mafternoon :D

not yet.

mafternoon!

now. :)

monkey: remind me, was it bookbrainz that had a fancy "data has been automatically imported but has not been verified by a user yet" data layer alongside "proper" content?

Yes, but it's more of a WIP not currently active

But indeed the idea is to have separate table for imported data, and after user validation gets moved to the appropriate table

Ok :) There's another discussion on the forums about label feeds and whatnot and it reminded me of this

So the idea is that it's basically a separate table, kinda like our CD Stubs in MusicBrainz, only that it's visible to everyone but marked somewhat differently on the author page and then the editors can be like "accept / fix / reject as dupe"?

Yes, that's it

Sounds neat. And hard, but neat

monkey: i'll need to check which fields are exactly needed for making something listenable on LB. my guess is artist name and track are enough. but when we fetch the review for recording we probably don't get the artist or something like that.

ruaok: alastairp: monkey: regarding #1605, jasondk suggested that we could makes mini-reviews listenable on LB. but the CB api is missing some metadata needed for it. see https://github.com/metabrainz/listenbrainz-serv... . my suggestion is that we add a metadata field to CB api to let LB put arbitarily what it wants there.

reosarevok: recordings took ~18 hrs on bono but is now done :D, currently doing url and work is the major one left. should be done today.

Neat!

do you have the changes needed to dump the json data from sir? we should gather it and write tests next methinks

I mean, the basic change I made is literally nothing else than

before the return in query_result_to_dict

repr() because it's a Set, but I guess for testing, testing it against a Set would work fine

lucifer: what metadata would you store?

and would you only allow the LB client to store it? Any protection to ensure that other clients can't randomly store other data (honestly, I guess this is no different to clients randomly submitting spam as a review)

regarding the comment about the cb uuid - a few things (though these are future improvements): 1) I'm sure the user uuid will be returned in the oauth query - can LB store this? 2) alternatively we should update all of these endpoints to support MB ids (also related to reosarevok's PR about adding links from MB admin to other sites)

jasondk can confirm but i think some related mbids or names. eg: metadata for recording is artist mbid, for artist its recording mbid. which now i think we could get from MB WS anyways...

yeah, if we have the recording mbid, then we can look up that data anyway. If it's additional data (msid, youtube link, spotify link) then maybe we can store it

i think LB storing the CB uuid for user makes sense

I've not been following the project, but on the face of it I'm not completely against the idea of storing the CB review uuid in LB

regarding spam, yeah i thought the same.

good point about having to make multiple API queries to get the reviews - is this currently done in the backend or the frontend? does the CB API allow you to get multiple reviews by ID?

the initial proposal was to store review data in LB which ruaok and I though is not a good idea. storing just the review uuid in LB is probably doable.

yeah, I think that is an acceptable compromise.

alastairp, i see an endpoint to fetch a user's all reviews or to fetch reviews based on a filter not fetch all reviews with these uuids.

what does the LB timeline show? n items, or "all things between these two timestamps" ?

n times.

mmm, so if we stored in the timeline table "type: review, cb id: x" then we can still easily get n timeline items

then it's just a question of how do you get the review text from CB - either query 1 at a time, or do we add an endpoint to CB to allow many (I'm in favour of this), and do we do it in frontend or backend [if we do it in backend we can also do direct db connection if that's available]

direct db connection can be made available, we'll need to consider about the revisions though.

probably duplicate one or two queries from CB.

because we setup oauth, in the end we didn't do the direct connection?

yes

in that case, let's implement a bulk-get-review endpoint in CB

cool, sounds good.

talking about the hour in Spain. I just received this email 2 minutes ago:

> El pedido saldrá este mediodia

spain in the ass, as per usual.

when does mediodia finish?

also

"order today (wendesday) and you'll get it by friday!"

not so much

lucifer: btw, do you need any more feedback on riksucks' PR?

I draw the line at mediodia finishing at 2pm.

I think the questions about ids have been resolved?

alastairp: yes sure. riksucks has opened a new PR using ids but I am yet to review it.

bitmap: re: your question about whether rand makes edit searches faster - it feels in some cases it does, to some degree? Not sure if a big enough difference to keep it, but you could check what you think too :)

what does that mean? yes sure you want feedback, or yes sure questions are resolved? :)

ah sorry, i think yes questions are resolved now.

nice

alastairp: what's the status of the sentry upgrade btw?

reosarevok: ah sorry, i forgot to reply. once sir is done reindexing, i'll update it with the current master + this patch and obtain dump for various entities.

lucifer: I ran into weird issues with trying to get 10.0.1 merged into our repo

I got that working now, I'm just getting the docker-compose file set up to run on serge, then I'll try another final local migration

makes sense, thanks!

ok, this has gone a lot better than the previous attempt now that I know how everything fits together!

I have another call now, will try and get this deployed soonish

alastairp: tested #1601 on test, login still works as expected for both existing and new users with/without email. should i merge?

also, #1602

entire reindex for all entities completed on sir-test 🥳

yvanzo, yyoung[m]: https://tickets.metabrainz.org/browse/MBS-11951 - I'm afk, could either of you take a quick look and see if it's a trivial issue?

MBS-11951: New link editor doesn't appear to support multiple SoundCloud links

reosarevok : Judging from the React devtools, it seems the 2 links have the same URL

there is bugged data indeed

It seems there were multiple SoundCloud URLs for this artist in the past.

Some of these URLs might have been merged together, but the relationships have not been merged.

See http://musicbrainz.org/ws/2/artist/7740488b-2d3...

So the error message is correct, but it should not prevent editing other fields of the artist.

yvanzo - I've been running live indexing for a few days now and it seems to be running ok but I'm worried about the wear and tear on the disks. If it's constantly indexing and hardly ever finishing that they're going to die before thier time.

Morning! i'm catching myself up on the messages here

Regarding revisions, CB api returns the latest revision of the review, and we can also indicate on the frontend that it was revised and link to the full review on the cb website

With the review uuid stored in LB, these ‘events’ will be passed to the user feed, and then on the frontend we can finish fetching the review content from CB API.

I’ll work on adding the bulk-get-review endpoint to CB next. thank you :D