Improving large playlist performance via deferred data fetching #386
Closed
ItsCynnamon
started this conversation in
Ideas
Replies: 2 comments
|
There are no other ways to fetch playlist songs. https://opensubsonic.netlify.app/docs/endpoints/getplaylist/ |
0 replies
|
Unfortunate. I imagined that might be a roadblock. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
I was doing some testing with larger playlists (~2000 tracks) and had a few thoughts that might help performance. This is just a quick observation and I may be missing context.
Right now it looks like the data fetching and rendering approach used for playlists differs from the one used on the "Songs" page. In the playlist tab, the entire songlist is queried and rendered at once via a single query, which I believe may contribute to a longer loading delay and related performance issues for larger playlists, especially when streaming remotely. I noticed that virtualization is already enabled on the playlist view, which helps, but the full dataset is still being fetched upfront.
Unlike the playlist tab, the "Songs" page fetches and renders items in batches of 100 using an infinite query, which significantly improves performance, but also leads to the behavior described in issue #142.
From a quick glance (and I may be missing context), one possible method to improve playlist performance might be to decouple the playlist data fetching and rendering from the full songlist. However, this would cause issue #142 to apply to playlists as well. If this solution were feasible to implement, would it also be possible to fetch a songlist with minimal track data - or even just track IDs - for the initial load of both playlists and the "Songs" page, and then resolve full track metadata lazily as tracks approach playback or come into view? This could help distribute network workload more evenly and would mean that bulk queuing and shuffling only requires the lightweight ID list upfront, potentially helping address issue #142 as well. I understand this would require a significant backend refactor, but it could substantially improve playlist performance and bulk queuing.
All reactions