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.