#metabrainz

Ooh, a personal note to me in the LB release notes :P

Happy to skip posting about it. But when it comes to X/Mastodon/Bluesky I don’t think it matters if it’s a small release, it’s just letting people know we’re active. If anyone thinks I should skip posting negligible updates let me know, otherwise I’ll probably post this one tomorrow :)

aerozol: I follow you on Mastodon for just this reason, to keep somewhat up to date (even for the small releases)

aerozol: Even a recap for the last two months (since LB 2023 recap) would probably be interesting 🙂

<05rustynova> Hi. Is there an API endpoint I can use to get the sitewide listen count of a specific recording MBID? I looked through the API docs and I can't find anything that would work. I thought I could at least use the same API as the Album pages, but it use server side data.

rustynova: we don't have an api for that yet but we can add that. feel free to open a ticket.

monkey, mayhem: i checked the spark cluster and user similarity seems to have fixed itself. it ran fine yesterday at least. what was the issue you were facing?

for me, there was a user complaining about it not updating.

glad that is "fixed".

:)

<05rustynova> lucider: Done. In the meantime I guess I'll resort to my good old friend website scrapping.

lucifer (IRC): Hi! The issue I was seeing with the user similarity is that huhridge and I have exactly one artist in common in our top 100 yet according to the API endpoint we just don't have a similarity calculated, not even a very low score: https://api.listenbrainz.org/1/user/mr_monkey/s...

I was wondering if there was a time range against which we calculate user similarity or something like that to explain that

monkey[m]: The BrainzPlayer SPA branch is live on test.LB The playback is working smoothly. Do give it a try and lemme know if you encounter any bugs.

Oooohhh, exciting !

Feels so good to navigate with playback uninterrupted !

Honestly. So good.

Once we have the class components to functional components, the Ambient Queue will be usable accross all the pages. Currently you can just set those using music neighbourhood page.

I see, that makes sense

Honestly still very much usable at this stage. The ambient queue not updating on all pages feels like a minor issue

Mm, it does break the functionality of automatic playback on those pages. For example on a playlist I can only play one track, at the end I have to manually play the next one.

Yep, once we merge LB#2822, we can atleast have ambient queue working on the dashboard.

Integrating React Query to improve performance: https://github.com/metabrainz/listenbrainz-serv...

Since this also converts dashboard component to functional component

Ooohhh, and the ability to add tracks to a queue and keep moving along <3

Yes, let's focus on that.

I started working on refactoring the UserFeed

With the apple stuff behind me I can continue focusing on that

Meanwhile i'll try rewriting tests for BrainzPlayer and ReactQuery

monkey: i added the whole similar artist list thing on hover, take a look whenever

also i was starting work on LB-1401, and since there is no labs endpoint for searching albums, i'm using the mb search api, should i search for 'release-group' or 'release'?

LB-1401: Manually add album listens https://tickets.metabrainz.org/browse/LB-1401

i tried searching for frank ocean's blonde and it seems that the release-group works better

It'll probably have to be release huhridge (IRC)

are there any drawbacks for using it?

Ah?

Well, you'll need a release to go with it in order to get the recordings to sibmit

submit*

like for example, http://musicbrainz.org/ws/2/release/?query=blon...

this doesn't have the album in the first 25 items

the release-group returns it as the first item tho

<12Aerozol> Releases within release groups can have very different tracklists. You could search release-group and then let the user pick which release, if more than 1?

<12Aerozol> p.s. Nobody @ me, I should be sleeping 😛

I was surprised to see your name !

huhridge (IRC): For an omnisearch kind of thing it's true, but if we do a separate field for artist anme you can do this: https://musicbrainz.org/ws/2/release/?query=blo...

aerozol: interesting, that can be done, we'll have to include like the number of tracks or something in the preview ig?

yeah that is the other option, but it's inconsistent with the track search

but yes it can be done

more work for the user tho

Yeah. I think aero zol's idea is better UX

and a release-group search also consolidates results imo

the one above returns exactly the same thing (with minor format changes) for the first 5 results, it'd be v confusing i think

Mon key, you are a scholar and a gentlesimian

:D

I can do dis too!

Jamon da Mayo!!!

may hem, I'm afraid to tell you the delete listens test is still randomly failing 😢 https://github.com/metabrainz/listenbrainz-serv...

its not the *same* test. its the following test.

No way...

Damn

I see it now

monkey[m]: i think we use a year's data for similarity, the not similar thing can be explained by the fact that we only keep top 25 similar users.

yeah, probably needs the same treatment as the one above.

Ahaa, thanks lucifer that could be part of it. Do you think it would be feasable to increase the range to say 2-3 years with the resources we have?

can try.

It did wonders for the fresh releases page to increase the range similarly

mayhem: around to discuss oauth stuff?

No rush on that

yerp

so the test oauth branch is up for testing on test.mb.org

you can modify a couple of configuration variables and LB will work with it seamlessly.

i can update test.lb.org to start using that but we'll need to create a separate database for that. and that may make it difficult to deploy other PRs on test.lb for a while.

maybe a separate VM for this purpose?

don't need a VM i think, can just use dev.listenbrainz.org on wolf then.

or that.

the oauth researchers who audited MB have published their tools under, https://oauch.io/.

that is very very very good.

i ran the new implementation against the test suite, it mostly is fine.

ship it!!!!

!m lucifer

there is an issue with MB redirects which i opened a PR for, once that is deployed. i'll rerun the test suite.

You're doing good work, lucifer!

some tests cannot be run until the redirects are fixed.

reosarevok: any chance you could help fasttrack the deployment of this PR??

How fast should the fast-tracking be?

It could be on beta today, does it need to be on prod or can you work with beta?

but other than that, there are three things pending: 1. beautifying the oauth related pages. 2. deciding new scopes to create. 3. figuring out migration of existing oauth apps.

reosarevok: only test.mb is needed.

test.mb? That doesn't use the real db, is that ok? If so, sure, I can certainly put it there

yup that is totally fine.

lucifer: for 1: there is a PR of the login page for meb.org. But I trust you need more than that?

2. new scopes. what does that entail?

mayhem: i met with aerozol for 1, he is fine with shipping it as is and making the remaining changes later.

O_O

getting soft in his old age, I see. :)

the login page is not coming yet, that needs user migration and will happen after the MB schema change.

only requirement from his side is a smooth redirection flow that does not drop off users, i'll ensure that works.

k

2. for scopes, basically we need to list stuff like: listen scope to submit listens, playlist scope to modify playlists so on.

this is new functionality fwiw. if we just wanted to move OAuth from MB.org to MeB.org for our projects, we could postpone this.

I think for this it would a good idea for you to make a google doc that outlines what you see and explains what needs doing. and then we need to get more people to read that to see what we need or are missing.

scopes are tricky, for sure.

sure can do that.

I am not sure what concept to apply here....

in other realms it is best to not over-plan. and in others over-planning is a must.

we can use spotify/apple music/google etc. as inspiration.

where do we fall on this?

My gut feeling is that if we dont need this yet, lets skip it.

i would start with just adding a listen scope.

but making the doc is a good idea to capture your ideas while they are fresh.

oauth support for submitting listens has been asked for before.

I think that is sensible. we should add scopes as we need them, but we need an overarching plan for scopes, otherwise they get messy

clear use case

yes, makes sense.

3 is tricky too. migrating existing apps over, will surely need changes in MB code base.

like what?