#metabrainz

I saw the pr

chinmay, i think that ties in with the coverartgrid mayhem has been working on recently.

the problem as he mentioned in the summit is with hosting.

I'll be picking up the work on that later next week, trying for the client side version -- see if we can make it work.

all JS/CSS.

Hmm, the coverflow looks OK on mobile in landscape mode, but portrait not so much. There is support for configuration overrides per breakpoint so I'll look into that https://swiperjs.com/swiper-api#param-breakpoints

monkey: it looks awesome. the animations are smooth. I'd change release name font size to 1.5rem and change the artist name font color to #46433a a.k.a @asphalt

testing for mobilenow

lucifer: ^ I'm not quite done with the coverflow PR, so don't wait for me for the release :)

👍

[listenbrainz-server] release 03v-2022-10-14.0 has been published by 14github-actions[bot]: https://github.com/metabrainz/listenbrainz-serv...

monkey: yeah, portrait mode needs work

Understatement :p 💩

For those of you following at home: https://usercontent.irccloud-cdn.com/file/tYUNf...

😂

monkey: can you quickly check if test files aren't getting auto formatted for you as well?

How do you mean?

I'm seeing the yellow squiggly lines but the code doesn't auto-format like it does for non-test files

Hm, related to the ESLint PR I suppose

[listenbrainz-server] 14amCap1712 merged pull request #2203 (03master…amCap1712-patch-2): Update release_group_secondary_type_sort order https://github.com/metabrainz/listenbrainz-serv...

I'll put it on the list :)

like so^

okay

yeah, related to eslint pr

For me it auto-formats, but I think it's my code editor extension doing it on save

hmm.. let me check my extension

when i do Ctrl Shift I it uses it's own config

something wrong with my extension it looks like

mayhem: oh i remembered just now. we forgot to discuss the mapper metrics issue. do you want to discuss it now or later?

now works.

i checked the indiviudal counts for each match type are correct. but the percent calculation rate has some issue. not exactly sure what. i propose we calculate the match rate by doing (exact + high + med + low) / (exact + high + med + low + no) directly in influx.

we can use the spread() method of influx to only consider listens of a particular time period instead of the overall cumulative count if we want.

I like it, but...

this way is probably also more in line with how we have to do it when we move to prometheus.

we're migrating away from influx. (thank fuck)

i believe that prometheus will have same features available.

ahh, ok. shall we move this batch to prometheus to start with? we can move the metrics python code over.

sure.

i'll add a flask endpoint to metrics as we discussed in the summit and then work with zas/atj_mb so that prometheus starts querying it.

and yeah, the stats are deffo a lagging feature and when you have no idea what you're doing those tend to become a mess.

yeah makes sense

I was really hoping to avoid this endpoint and move the metrics writer to promethues and expose an HTTP endpoint from it.

yes right. isn't that what we are going to do?

my understanding was we finalized that during the summit but i might be misremembering?

my understanding "move the metrics writer to promethues and expose an HTTP endpoint from it." is what we decided.

right.

"I was really hoping to avoid this endpoint" <- which endpoint did you mean by this?

the parameters to the metrics writer will need to change, so that makes things a bit tricker. we may need a new method name, unless BU can isolate it from the codebase that expects the old format.

I'm really hoping to avoid adding another endpoint to LB.

i think that's fine. we won;t need to add another LB endpoint.

👍

the BU method can write 2 times, once for influx and one for prometheus. till we move all LB stuff to prometheus.

brilliant!

historical user counts, spotify connections is something i'd like to retain over long time and afaiu prometheus isn't currently configured for that.

so at least those 2 things will remain in influx for now.

mayhem: while you are around, quick comment on https://github.com/metabrainz/listenbrainz-serv... ? do you anticipate the need for using this field anytime soon?

the conclusion we reached in this case that for items we want stored longer, is that we should ask atj_mb or zas to update the retention rules for us accordingly.

(in prometheus)

ah i see. makes sense

not soon -- in JSONB is fine for now.

👍 thanks!

IIRC zas said he has configured Prometheus to retain stats for 5yrs by default

noice.

[listenbrainz-server] 14amCap1712 merged pull request #2198 (03master…spotify-cache): Add spotify metadata cache https://github.com/metabrainz/listenbrainz-serv...

thanks for the reviews, mayhem. doing another release.

spotify export feature on beta won't be available for a while till the index rebuilds with this PR.

k

[listenbrainz-server] release 03v-2022-10-14.1 has been published by 14github-actions[bot]: https://github.com/metabrainz/listenbrainz-serv...

hello. i set up a listenbrainz scrobbler (cmus-status-scrobbler), which claims to send musicbrainz ids if present. all of my music has musicbrainz ids, and i've verified by modifying the script to dump http requests to a file that it is in fact sending the ids...

...however, when i look at my recent listens, it often shows the wrong recording id (different recording with the same title by the same artist, etc)

am i doing something wrong, or is this expected behavior/a known bug?

hi naom!

thanks for sending MBIDs, we <3 that!

lucifer: monkey : I forget -- where is the UI at in showing user submitted MBIDs?

we've been trying to get our mapper working well (its a looong task) and for that effect we decide to show the mapped MBIDs and ignore user MBIDs.

mayhem: not sure what you mean?

naom: what's your LB username.

we're planning on changing that before too long iirc

are we showing user submitted MBIDs over mapped MBIDs in the LB UI?

i mean not sure which UI you mean.

for listens page, we prefer user submitted mbids iirc.

a users personal listens page, for example. but any page where listens are shown, really.

everywhere else mapped ones.

i noticed in one case, the album art of an incorrect album is displayed, but if i hover it, the correct release title is the alt text

mayhem: we have three cases iirc, user listens page, prefer user submitted over mapped. stats prefer mapped over user submitted. everywhere else mapped.

naom: i see. can you also tell which listens are problematic?

"everywhere else mapped." should probably prefer user submitted now. what do you think?

sorry, i meant we use data from mapping every where else. like feedback stores recording mbid only, and need to fetch metadata from mapping.

we do use recording mbids from user submitted listens there if present afair. but that the metadata is still looked up from mapping in all those cases.

lucifer: for the track "FUCKMYLIFE666", i should have submitted 595e0a92-3fbe-493e-bd45-522c11ed576e but my user page links to 096eed95-18b9-4fe1-9c3a-6f49fb3d92c5. for "His Arm Was Her Leg", submitted 0e112194-f4cd-44ee-930a-f6f07c045872 and links to ef134fcd-1c21-439f-a7b2-e477b4b2e58d

naom: there are no user submitted mbids here. can you link me to the scrobbler you are using?

naom: oh i see, so this is using the last.fm compat api. we ignore mbids received on that because of dubious last.fm data historically.

we could accept those mbids but looking at the code, https://github.com/vjeranc/cmus-status-scrobble...

this is trying to send a track mbid not recording mbid probably. this is a guess from a brief look at the code so can be wrong.

mayhem, thoughts on whether we want to accpet mbids in the lfm api?

i see

please use our normal API for submissions, naom.

the old API was created for making old tools backwards compatible

but if people keep writing tools against this API, maybe we should just remove it.

this has historically been the case and this is a bad pattern, really.

we can reach out to the owner of the repo and help them use the new api. its python and looks simple enough for us to help port.

that's be much better.

removing the api altogether is probably fine but we should analyze how much traffic we have there and do a blog post offering to help port i guess and then sunset in some time.

and if the compat api gives us issues again, lets rip it out.

sounds good to rip out in any case i think, if we can help existing users switch over. would be one less thing to maintain.

yes, plz.

cool, i'll open a ticket for the analysis, blog post etc.

now that you mention it sending a track mbid and not a recording mbid, i'm looking at my music's metadata and it has MUSICBRAINZ_TRACKID but nothing explicitly mentioning recordings, is that abnormal? i use beets for tagging

i don't actually think i realized track ids were a thing per se

i am not sure how beets work but something might be falling back to recording mbid because the mbid you shared was indeed a recording mbid.

i'll try to reach out to the author and see if we can port it to the newer LB api.

wonderful

oh it appears the C* Music Player only supports track id not recording mbid.

in any case, porting the scrobbler would be a good idea.

keep in mind that back in the original lastfm days, trackid is what we now call recording id

due to schema changes, etc

oh.

anyway, having number of accesses to compat api via our new metrics monitor would be great ;)

yup makes sense

for that, yes, great use case. :)

naom, can you show what's the value of various mbid fields of the file in beets?

ah, right. lucifer: MUSICBRAINZ_TRACKID is recording id: https://picard-docs.musicbrainz.org/en/appendic...

in case you didn't know that

oh!

thanks, alastairp. didn't know it.

lucifer: https://bpa.st/raw/5FFQ

cool, then scrobbler changes are enough.

so RELEASETRACKID is a track id and TRACKID is a recording id?

ah, yeah that's what the page says

yes

so a track is like a single entry in a medium, then? i don't think i realized those had their own ids separate from recordings until now

yes right.

lucifer: I wondered why my battery was going down so quickly. fleet was stuck in a loop using 50% of an entire cpu core trying to ssh to the remote workspace

still a bit to improve...

oh. oops!!

indeed

8000 commits to LB!

lucifer: I recently wrote a longer explanation of the history of the musicbrainz_trackid tag on the Mp3 tag forums: https://community.mp3tag.de/t/logik-hinter-musi... . It's in German, but Google Translate can give a rather good translation if you're interested.

Thanks alastairp! Nice to be home. Hopefully the luggage is delivered soon, with your gifts D:

CatQuest: ex-battery chicken friendos :D

<3<3<3

i knew a lady that also did that. good humans!

They are very cute, and provide eggs for the neighbours as well (we only have 2, RIP Sunny Jim)