<JuliaHusar[m]> "Quick question, is there a..." <- not yet. but before too long, I want to make that happen too.
d4rk-ph0enix has quit
d4rk joined the channel
d4rkie has quit
d4rkie joined the channel
Kladky joined the channel
Derailed has quit
Derailed joined the channel
GautamShorewala[
<jasje[m]> "There is some refactoring that..." <- jasje: the current implementation of sockets does not include the current song progress so when we need to show the listening now from sockets should we only show the mini player with the song details or can the current implementation of sockets be changed to also include the progress too?
jasje[m]
<GautamShorewala[> "jasje: akshaaatt i was looking..." <- As of now, we should only show the song without progress.
jasje[m]: Support for showing will cost more on the server side but that is up for debate
jasje[m]: Cc lucifer:
jasje[m]: Maybe we could send play pause events with utc timestamp but still up for debate
mayhem: LB was down for a few minutes. i didn't find any hung up queries in the database so weird and not sure what happened. but looking at the current listen fetch patterns, i am wondering if there are some new troi changes deployed or playlists being generated which might have contributed to it.
GautamShorewala[
<jasje[m]> "Support for showing will cost..." <- Since we are planning to integrate remote playback from Spotify and youtube the listening now may not be used as much.
The only places it will be used is when the user is listening to one device and want to switch to another device.
jasje[m]
GautamShorewala[: Gautam Shorewala: listening now will still be used
jasje[m]: We could have a short way to update listening now offline, but mostly it would be like this: Play song -> Listen Submission service picks it up -> LSS sends it to backend -> Backend updates us.
d4rk has quit
d4rk joined the channel
dseomn_ joined the channel
dseomn has quit
dseomn_ is now known as dseomn
d4rk has quit
d4rk joined the channel
d4rk has quit
d4rk joined the channel
monu8[m] joined the channel
monu8[m]
Hello everyone, I'm Monu, a CSE student and a passionate coder. Really excited to make meaningful contributions to MetaBrainz and other [(...)Brainz] projects. Would love any guidance or help by mentors : )
kepstin has quit
kepstin joined the channel
mayhem[m]
<lucifer[m]> "mayhem: LB was down for a few..." <- but the last release was v2025.01.29.0, so why would we find problems now? recent changes have not been merged, nor released.
d4rk has quit
d4rk joined the channel
d4rk has quit
d4rk joined the channel
MyNetAz has quit
MyNetAz joined the channel
d4rk has quit
d4rk joined the channel
\- joined the channel
d4rk has quit
d4rk joined the channel
JuliaHusar[m]
<mayhem[m]> "not yet. but before too long..." <- Ok gotcha, gotcha. Would it be collaborative filtering, content-based, or a mixture of both methods?
MyNetAz has quit
MyNetAz joined the channel
d4rk has quit
d4rk joined the channel
vardhan_ has quit
vardhan has quit
vardhan_ joined the channel
vardhan joined the channel
vardhan_ has quit
vardhan has quit
vardhan_ joined the channel
vardhan joined the channel
vardhan has quit
vardhan_ has quit
d4rk has quit
d4rk joined the channel
minimal joined the channel
lucifer[m]
mayhem: i see, yeah it was just a hunch. at least for LB radio on LB, i think we should switch away from API to direct db calls. its possible just a lot of people were using LB radio at the same time or just maybe just a few people but the queries were heavy.
the listen fetch pattern seemed as if it was trying to fetch all or lots of listens for 3-4 people and iirc there are LB radio queries or troi patches that can do that. ordinary troi usage would be ratelimited but our token is whitelisted so it could potentially overwhelm the app.
<JuliaHusar[m]> "Ok gotcha, gotcha. Would it be..." <- eventually a mixture of both i think but afair from past discussions, only collaborative filtering at first
JuliaHusar[m]
<lucifer[m]> "eventually a mixture of both i..." <- ooh ok cool! yeah collab filtering is def the simplest to setup
but semantic content based filtering could work so well in books omg
d4rk has quit
d4rk joined the channel
monkey[m] has quit
BrainzGit
[listenbrainz-server] 14Suvid-Singhal opened pull request #3226 (03master…lastfm-check-username): LB-1765 Check if user exists on last.fm while connecting last.fm username https://github.com/metabrainz/listenbrainz-serv...
<lucifer[m]> "the listen fetch pattern..." <- Interesting. I've been wanting to add some LB Radio logging and the time it takes to execute the requests. then we would at least have an inkling of use and a tool for debuggin
MyNetAz has quit
MyNetAz joined the channel
Kladky has quit
aerozol[m] has quit
salaxceitor[m] joined the channel
salaxceitor[m]
would the remote playback allow you to show in the brainz player what are you listening to in remote apps like spotify and youtube?
MyNetAz has quit
JuliaHusar[m]
Ok I have been doing some sketching for the purposes of data vis + recommendation.
JuliaHusar[m] uploaded an image: (3750KiB) < https://matrix.chatbrainz.org/_matrix/media/v3/download/matrix.org/yhuyAoYgYiBYbxzcAMdWnigv/Recommendation%20Visualization.jpeg >
JuliaHusar[m] uploaded an image: (2919KiB) < https://matrix.chatbrainz.org/_matrix/media/v3/download/matrix.org/FfsoQVpXDBMKafDwOdtuCbQA/Recommender%20Interaction.jpeg >
JuliaHusar[m] uploaded an image: (3841KiB) < https://matrix.chatbrainz.org/_matrix/media/v3/download/matrix.org/uhXNtNuPEDmTkZfEKIfKVXNk/Recommender%20Low%20Fidelity.jpeg >
The general ideas in these wireframes are that recommendation should be a user-centered process where users work with algorithms to find new music to listen to based on existing material they are familiar with. Essentially we are taking a user's taste, and allowing them to explore it further and make further connections.
The design on the bottom is a low fidelity wireframe of a recommendation system that allows users to filter through albums that users might like based on their listening history. One row could be this sort of obvious "similar" albums, but another could be "featured" and really tie into the whole community aspect of leaving reviews and writing thoughts about music. The interaction wireframe in the middle shows how this would link
with the existing album page that is built into ListenBrainz, allowing users to find more information about an album + streaming platforms
Finally, the top wireframe is a sort of visualization of sorts demonstrating relationships between albums using a hub and spoke model, not dissimilar to the existing genre mapping model. If we could present the user with a familiar album, and then show other albums and the correlations between those albums, we would provide a sort of implicit explanation to our algorithm that would be natural and allow for greater discoverability.