Music Folder extension to extend musicFolderID support to more endpoints

[dweymouth]

Open questions

• What about playlists containing songs from different music folders? Should the getPlaylist (and getPlaylists) endpoints be scoped down by music folder as well, filtering the playlist by songs contained within a given music folder?
• Should the should language around song and album count on getGenres be changed to must? I didn't want to hold servers back from implementing the extension if it's too complicated to index genre song and album counts by music folder. For an online-first client at least, failing to do so is at worst a slightly confusing UX with the counts not matching what's actually browsable when scoping by music folder.

[netlify]

✅ Deploy Preview for opensubsonic ready!

Name	Link
🔨 Latest commit	374109a
🔍 Latest deploy log	https://app.netlify.com/projects/opensubsonic/deploys/6874448b7986d00008094b0b
😎 Deploy Preview	https://deploy-preview-162--opensubsonic.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[deluan]

I think getPlaylist/getPlaylists should receive the param as well.

So if I have a playlist with songs from 2 libraries, when passing a musicFolderId to getPlaylist, I should only receive songs from that library. Also would be used to calculate track counts relative to the given musicFolder, both for getPlaylist and getPlaylists

[kgarner7]

Required changes:

1. Fix build
2. Update OpenAPI Docs

Suggested endpoints to also extend:

1. getArtist: for servers which support artists across libraries (not OG subsonic), only return albums in that specific library (and proper albumCount)
2. getBookmarks: only show bookmarks for items in a given library
3. getShares: only show shares for a given library

Endpoints where it might make sense:

1. getScanStatus / startScan. If servers support per-library scanning. Maybe that's a separate extension?
2. getVideos (not sure this is relevant, since OS is mostly audio, but to be technically correct)

Endpoints that probably shouldn't:

1. getPlayQueue / savePlayQueue (and *Index): this is extremely complicated for maintaining current

[deluan]

3. getShares: only show shares for a given library

IMO, it doesn't makes sense for getShares to have the musicFolderId. AFAIK, shares are not saved per library.

[lachlan-00]

3. getShares: only show shares for a given library

IMO, it doesn't makes sense for getShares to have the musicFolderId. AFAIK, shares are not saved per library.

Shared content would come from a library / musicfolder so you should be able to list shares by folder id (The share isn't part of the folder)

• What about playlists containing songs from different music folders? Should the getPlaylist (and getPlaylists) endpoints be scoped down by music folder as well, filtering the playlist by songs contained within a given music folder?

It wouldn't happen often but you should be able to filter playlist content by folder id

• Should the should language around song and album count on getGenres be changed to must? I didn't want to hold servers back from implementing the extension if it's too complicated to index genre song and album counts by music folder. For an online-first client at least, failing to do so is at worst a slightly confusing UX with the counts not matching what's actually browsable when scoping by music folder.

Indexing per library could be slower for a lot of people so i would say should. But I would extend to support it myself.

[dmdeller]

+1 for this. My client (Radiccio) already sends musicFolderId to getArtist in hopes that it will be implemented someday, because this matches with my app's expected behavior.

Currently, when browsing a specific music folder, we have no choice but to display artist albums that don't belong to that folder, which is not the desired user experience.

If it were also implemented for getPlaylists we would use it for that too.

[paulijar]

My server currently has no support for multiple music folders but it might be added later. In that case, I wouldn't want to have the musicFolderId-filtering on getPlaylists since that could potentially be very costly, having to drill down to the contents of each playlist to be able to list them.

[dmdeller]

Could we perhaps use the versioning mechanism to include or exclude playlists? Version 1 excludes playlists, version 2 includes playlists? Then, servers could advertise whichever version they want to support.

Alternatively, we could have a separate extension just for playlists. That feels rather unnecessarily complex to me, but it could also solve the problem.