Enhance the radio queue generation

petitminion

Now if we generate a 1000 tracks queryset for a radio, the tracks wont be load into the queue directly, they will be added one by one.

Adding a tracks to the queue is a process that takes time so :

we can't skip the tracks from a radio rapidly
we can't have a preview of how a radio looks like

Solutions :

Add 10 tracks at the radio launch to the queue and them add them one by one. Or add them if the user is scrolling down the queue when a radio is launched

what do you think ?

gcrk

We should involve @wvffle here for the frontend side considerations.

I jump into the problem that I cannot skip tracks fast enough from time to time, so this is for sure something I'd like to have tackled. I think increasing the look ahead is a good idea:

At the beginning, add 10 tracks.
Make sure there are always 5 tracks ahead available.

I don't think its a good idea to add new tracks while scrolling, though. The queue is supposed to be a playback list. If people want to scroll though list of tracks, we probably need to find another solution then the queue. In my case, I wouldn't want to add dozens of tracks just because I am scrolling down a bit by accident 😃

wvffle

I have nearly 19k tracks in my radio and I run into this issue multiple times a day, trust me. However I think that the real issue is not adding tracks one by one (as suggested in the post) but rather the absurd time it takes to fetch next radio track. It can range anywhere from a tolerable 1s to even a minute in some extreme cases. I haven't checked the implementation of the radio algorithm but from my experience I can say that there is space for improvements there.

Having that said, I think that the proposed solutions are just workarounds for the real problem however if we dump the fetching time to something below 2s, those proposals would be something that would enhance the UX so overall I think they're good ideas.

Adding tracks when scrolling is not a good idea in my opinion. Not only we'd have issues with current autoscroll or resizing but it would be just irritating to some people. What gcrk proposed seems like much better option.

What we could do to give users ability to fetch like 10 next tracks, is to redesign this notice
[upl-image-preview url=https://forum.funkwhale.audio/assets/files/2023-05-08/1683539730-662814-image.png]

into something like that, that would be fixed at the bottom of the queue view rather than having it at the bottom of the scroll container:
[upl-image-preview url=https://forum.funkwhale.audio/assets/files/2023-05-08/1683539966-521865-image.png]

petitminion

gcrk At the beginning, add 10 tracks.
Make sure there are always 5 tracks ahead available.

I also agrees this is the best approach

wvffle However I think that the real issue is not adding tracks one by one (as suggested in the post) but rather the absurd time it takes to fetch next radio track

I also agrees this need to be resolve in the backend side by implementing a way to save the queryset in redis has suggested by @gcrk in our private discussion

ClarksonPowell use machine learning algorithms to suggest new and appropriate tracks

I would rather work with listenbrainz to generate such recommendation algorithms than creates our own. We are actually working on implementing this. But I don't think funkwhale will have the resources to develop such things because we are speaking of a whole new infrastructure needs, with important amounts of processing times, that needs to be centralized anyway... I understand some people might not want to share their data with listenbrainz, that's why there will other options too (genre, tag based recommendations, similar track recommendation) but the ML would still happend in metabrainz side.
Also I don't thing slipping the working effort betwenn various project is usefull. If you want to work on music recommendation, you can work with metabrainz and them this will be implemented into funkwhale thank to the troi recommendation system we are implementing into fw

ClarksonPowell

I would like to share my thoughts on improving the radio queue generation in Funkwhale. I am an active user of this platform and I often listen to the radio to discover new music and enjoy familiar tracks. One aspect that I believe could be improved is the radio queue generation process. Currently, it seems a bit random, and it often happens that several tracks from the same artist or genre play in a row in the queue. I think this could be made more varied and interesting for listeners. My idea is to add an algorithm that will take into account different factors when forming the radio queue. For example, you could take into account the user's preferences, their listening history, and use machine learning algorithms to suggest new and appropriate tracks. In addition, it would be great if users could customize the parameters of radio queue generation. For example, one could specify a preferred genre, the length of the queue, or even specific artists whose tracks should be included in the radio. I think these improvements would make listening to radio in Funkwhale even more fun and personalized. I would love it if the Funkwhale community would consider this idea and implement it in future updates.
Thank you for your consideration, and I hope we can improve Funkwhale's radio queue generation together!

wvffle

ClarksonPowell Thanks for your input!

The true randomness gives you some slight chance, that if you play a radio of an artist, the queue would be still sorted. This is an issue for some, as on big radios, you can hear the same artist a couple of times in a row but the other artist can be not chosen for dozens of songs.

I've been researching the topic some time ago and I see two ways of implementing it:

Use ML algorithms as you've suggested
Use a simple algorithm that distributes songs from an artist evenly

The second option seems much easier especially if we analyze Spotify's approach:
I'm speaking from memory, so I might've messed something up

Create a line of length L
Iterate over a list of objects:
1. Create a random offset variable
2. Iterate over a list of object's children:
  1. Place the i-th object on the L / len(objects) * i + offset point
Collect randomly sorted and evenly distributed objects in order from 0 to L

This is so easy to implement and so generic that it can be applied twice, to first shuffle artists and then shuffle their albums

wvffle

There is an article from 2014 that explains the algorithm in a visual way: https://engineering.atspotify.com/2014/02/how-to-shuffle-songs/

gcrk

Just a quick side note: If we really add ML things, this needs to be optional. We have people running Funkwhale on a RPi and hosting Funkwhale on cheap/weak/energy efficient devices is a feature I don't want to break.

petitminion

backend is ready for review : https://dev.funkwhale.audio/funkwhale/funkwhale/-/merge_requests/2430

to do in the frontend :

At the beginning, add 10 tracks
Make sure there are always 5 tracks ahead available

I don't think we need a spec for this, do we ?