Add playlistFolders extension for organizing playlists in nested folders - #255
Add playlistFolders extension for organizing playlists in nested folders#255DahliaWitt wants to merge 1 commit into
Conversation
Adds a per-user, ordered playlist folder hierarchy as proposed in discussion opensubsonic#75: - New extension page: playlistFolders (v1) - New endpoints: getPlaylistFolders, createPlaylistFolder, updatePlaylistFolder, deletePlaylistFolder, movePlaylist - New responses: playlistFolder, playlistFolders - Adds optional playlistFolderId and playlistFolderSortOrder fields to the playlist response - OpenAPI schema and endpoint definitions with formPost variants
✅ Deploy Preview for opensubsonic ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Lovely to see this, and also funny timing. Over the last few months I've built out a similar implementation, first client side then into a personal fork of navidrome. I've been getting a submission ready as an open subsonic proposal when someone highlighted your work. Our approaches differ a bit and I'd like to take the time to align so we don't end up with two competing proposals, how do you want to proceed? |
|
you would want a folder element in https://opensubsonic.netlify.app/docs/endpoints/updateplaylist/ as well |
|
i am super interested in/excited for this feature. im hoping it gets added sometime soon! |
|
Just a small update here- I'm trying to reach out to the OP on a second draft (primarily to support many-folder membership, and it would address lachlan-00's issue implicitly). Keen not to sidestep Dahlia. |
Follow-up to #75 (and #14 before it). This adds a playlistFolders extension: nested, ordered playlist folders like iTunes, Spotify, and Rekordbox have.
TL;DR
Adds a per-user, ordered playlist folder hierarchy.
Design notes, mostly answering questions/topics raised in #75:
movePlaylistis its own endpoint because placement is an operation on the (user, playlist) pair, not on the playlist.updatePlaylistis owner-restricted, so a folder parameter there can't express filing someone else's playlist. One endpoint covers moving into a folder, moving to the root, and reordering. Batch moves pair repeated playlistId/sortOrder parameters the same way scrobble pairs id/time.getPlaylistFolders+getPlaylists, and a per-folder endpoint just invites N+1 loops.Backward compatibility
This is a no-op for existing users and clients. Nothing will break with this addition.
getPlaylistsreturns the same complete flat list it always has, so a legacy client talking to a folder-supporting server still sees every playlist. Folders are invisible to it.getOpenSubsonicExtensions.Server/implementer cost
Two small tables (folders and placements) and one LEFT JOIN on
getPlaylists, only for servers that advertise the extension. The cycle check is a walk up the parent chain.getPlaylistFoldersreturns folders only, and even heavy users have tens of folders, so I don't think pagination is needed (if I'm wrong happy to implement it).Out of scope
Can be added later or as a follow-up upon request.
createPlaylist. Creating into a folder takes two calls. I'd rather cost clients an extra request than grow a base Subsonic endpoint.Tags Debate
Tags came up in #75 as the alternative. I think they're a good feature, but a different one. What I need is to bring over folder hierarchies that already exist in iTunes exports, Rekordbox crates, and Koel, with their structure and ordering intact. The hierarchy is the data; a flat tag set can't carry a tree like these other apps have. I want to add support for an existing idiom in popular music software.
I don't think this is a one or the other situation. I see no reason why tags could not still be added later in addition to this.
Implementation/Clients
Koel ships nested playlist folders natively (one level since koel/koel#1499, arbitrary nesting in koel/koel#2612, which I wrote), and Koel implements OpenSubsonic. In #75 it was mentioned that no server had the feature, so there was nothing for clients to build against. Now a server has it and is missing the API surface.
I'll create a PR these endpoints into Koel's Subsonic layer as the reference implementation, and I'm willing to do a Navidrome implementation too (navidrome/navidrome#1858 is the request there).
Feedback
Client authors: feedback wanted, in particular on the flat list + parentId shape and on movePlaylist. This is a feature that I desperately need to fully move over from a proprietary ecosystem. Seeing the discussions around this on several different clients (such as (navidrome/navidrome#1858) demonstrates a clear need and demand for such a feature.
Note
AI Disclaimer: I used LLMs to assist with authoring these changes. All changes were manually reviewed and I am not wasting your time with clanker slop.