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 :)
minimal has quit
Maxr1998_ has quit
Maxr1998 joined the channel
huhridge joined the channel
huhridge has quit
aerozol[m] has quit
yano1 joined the channel
yano has quit
huhridge joined the channel
Kladky joined the channel
yellowhatpro joined the channel
v6lur has quit
huhridge has quit
huhridge joined the channel
zerodogg
aerozol: I follow you on Mastodon for just this reason, to keep somewhat up to date (even for the small releases)
SigHunter has quit
SigHunter joined the channel
huhridge has quit
hydralica has quit
huhridge joined the channel
yvanzo
aerozol: Even a recap for the last two months (since LB 2023 recap) would probably be interesting 🙂
discordbrainz
<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.
lucifer
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?
mayhem
for me, there was a user complaining about it not updating.
glad that is "fixed".
:)
nobiz has quit
nobiz joined the channel
discordbrainz
<05rustynova> lucider: Done. In the meantime I guess I'll resort to my good old friend website scrapping.
yano1 is now known as yano
monkey[m] joined the channel
monkey[m]
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
ansh
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.
monkey[m]
Oooohhh, exciting !
monkey[m] uploaded an image: (52KiB) < https://matrix.moviebrainz.org/_matrix/media/v3/download/moviebrainz.org/yHnZllmZyQpdJmZrydAkbhuB/image.png >
Feels so good to navigate with playback uninterrupted !
Honestly. So good.
ansh
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.
monkey[m]
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.
ansh
Yep, once we merge LB#2822, we can atleast have ambient queue working on the dashboard.
Since this also converts dashboard component to functional component
monkey[m]
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
ansh
Meanwhile i'll try rewriting tests for BrainzPlayer and ReactQuery
huhridge
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'?
the release-group returns it as the first item tho
discordbrainz
<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 😛
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.
mayhem
yeah, probably needs the same treatment as the one above.
monkey[m]
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?
lucifer
can try.
monkey[m]
It did wonders for the fresh releases page to increase the range similarly
Thanks !
lucifer
mayhem: around to discuss oauth stuff?
monkey[m]
No rush on that
mayhem
yerp
lucifer
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.
the oauth researchers who audited MB have published their tools under, https://oauch.io/.
mayhem
that is very very very good.
lucifer
i ran the new implementation against the test suite, it mostly is fine.
mayhem
ship it!!!!
mayhem runs away
monkey[m]
!m lucifer
lucifer
there is an issue with MB redirects which i opened a PR for, once that is deployed. i'll rerun the test suite.
BrainzBot
You're doing good work, lucifer!
lucifer
some tests cannot be run until the redirects are fixed.
mayhem
reosarevok: any chance you could help fasttrack the deployment of this PR??
reosarevok
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?
lucifer
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.
reosarevok
test.mb? That doesn't use the real db, is that ok? If so, sure, I can certainly put it there
lucifer
yup that is totally fine.
mayhem
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?
lucifer
mayhem: i met with aerozol for 1, he is fine with shipping it as is and making the remaining changes later.
mayhem
O_O
getting soft in his old age, I see. :)
lucifer
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.
mayhem
k
lucifer
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.
mayhem
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.
lucifer
sure can do that.
mayhem
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.
lucifer
we can use spotify/apple music/google etc. as inspiration.
mayhem
where do we fall on this?
My gut feeling is that if we dont need this yet, lets skip it.
lucifer
i would start with just adding a listen scope.
mayhem
but making the doc is a good idea to capture your ideas while they are fresh.
lucifer
oauth support for submitting listens has been asked for before.
mayhem
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
mayhem nods
clear use case
lucifer
yes, makes sense.
3 is tricky too. migrating existing apps over, will surely need changes in MB code base.