[API Request] Album Collections

[certuna]

Proposal description

Playlists, but with album objects instead of song objects. Plex supports this, and there seems to be user demand for it.

If this is added, do we want to handle it 1:1 exactly like Playlists? Or do we like another structure?

Backward compatibility

• No backward compatibility impact.

API details

• new endpoints createAlbumCollection, deleteAlbumCollection, updateAlbumCollection, getAlbumCollection, getAlbumCollections
• new responses albumCollection, albumCollections, albumCollectionWithAlbums

[Tolriq]

We need to define first the proper API for http POST support. All APIs with large number of parameters via GET are dumb and reach limits easily.

[certuna]

Fair enough, we can revisit this topic when that part of the API is finalized.

[Tolriq]

A few server already have some support, just need to have them react :p #26

[jeffgt14]

Is the idea for Album Collections to also solve the age old "Box Set" problem? Would there be a way to tie an album collection back to an Artist so it's seen under the Artist view?

In the past, I've gotten by with folder browsing so that the Box Set shows up under the Artist and I can browse individual albums when I go into the Box Set.

Example below with the Iron Maiden 2017 - The Complete Albums Collection 1990-2015 Box Set

[deluan]

Box sets are simply albums with multiple discs. This is already supported in OpenSubsonic and some clients show them nicely. Disc covers were introduced this month and some servers (lms and navidrome at least) support them.

[ygabuev]

Hey! I've recently posted a similar proposal to the Navidrome board, and then found this discussion here. How can we move the discussion forward?

[deluan]

I really like the idea of collections (not boxsets, as these are simply multi-disc albums), but I won't be able to commit to implement it any time soon.

[ygabuev]

If someone wants to contribute, what would be the next steps, given the OP's proposal? Should it be a PR with the full functionality fleshed out, or do you see more things to discuss here?

On the surface, this feature seems very akin to track playlists, with the albumCollection* types in place of playlist* types. Can you see any potential difficulties or things to pay attention to?

[Tolriq]

The questions are always the same for those kind of additions, take a step back and think of the related things or not that help building the right API. Typically :

• Is this 100% identical to playlists in all it's completeness or not.
• Should this also work for artists (Plex and others have the tags concept everywhere)
• Should this support cross media type. (A collection could have songs, albums, artists and why not playlists or other collections. (Some providers support that).

[aweathe]

Apologies, just saw this discussion - I posted my initial thoughts in a separate comment.

The questions about the API are valid, but the scenarios may be slightly different. As an ex-API developer, I always followed the guiding principal of separation of concerns. Songs, albums and artists all have intrinsically different data. Combining any API call would cause chaos from a frontend perspective and likely hurt the legibility of the schema - everything now needs to handle IF/ELSE/ELSEIF/SWITCH scenarios. The best scenario is almost always separation.

Tags aren't aren't a bad idea, however again create massive overhead on the front-end. Tags would need to be separated by type at the very least to prevent the above-headaches. e.g tags/album, tags/artist, tags/songs. Think of a getAlbumListByTag, getArtistListByTag or getSongListByTag - any kind of getTag with embedded data would be a headache IMHO.

Artists. I don't see as much of a use-case for this, however would work well with tags.
Songs. Meh - playlists and favourites already provides this exact functionality and people are used to it.

Cross-media this really sounds like it adds massive complication to any frontend and API alike. Instead of a single endpoint with a single schema, you now have an endpoint with either a) A very large, very generic schema or b) and endpoint that now returns multiple schema types.

I'd be happy to attempt a draft a schema/PR for either option (or both lol)

[aweathe]

Followup thought on tags.

The problem ultimately is that from a frontend perspective, unless the client separates it, album collections will get buried in a generic Tags section. I know this isn't an API concern as such, but the up-take of the feature would be largely based on how much work it would take for the client team.

Albums - All albums
Collections - Collated lists of albums
Favourites - Favourite Tracks/Albums
Playlists - Mix-tapes of favourite tracks

In my opinion, all 4 are vastly different ways of viewing the data. Tags are usually a metadata concern and apply more to organisation traditionally - they could happily co-exist with the above.

[aweathe]

Ex-Senior-Software-Engineer here!

I just wanted to chime in on this and say this is something that's sorely missing. For my use-case, I want to browse my library via album collections - tracks are great, but my music collection is 100% album based. Things I'd love to achieve:

2025 CMA Winning Albums
2024 Triple J Hottest 100
50 Greatest Albums of All Time
Top 20 Jazz Albums
.. and about 50 more I can think of!

Does that differ from playlists? Yes and no. Playlists are entirely track based, I don't care about tracks in my library as I listen to it as I would to vinyl or CD. The favourites endpoint could be used for this, but would require client-side grouping. The group tag is somewhat useful, but requires albums to have tags added server-side. A hard pass with any large collection.

From the API perspective, I imagine this would more readily be integrated into the getAlbumListView endpoint. This is after all a list of albums. By extending this with a collection property, this would do exactly as requested.

createCollection
getCollection
getAlbumListView

I'm happy to draft a PR if that helps?

[certuna]

I think that would be good, always better to have a concrete proposal to discuss than bouncing relatively vague ideas around.

I think Plex provides a good template how this works from a functional pov: Album Collections can either be manually constructed Collections of album objects, as well as Smart Collections (like albumrating = 5 AND originalyear > 2020), so 1:1 analogous with playlists.

On the front end (Plexamp) it's displayed as simply another category: in its Library view you have sections Artists, Albums, Compilations, Tracks, Playlists, Album Collections, Record Labels, etc. Not too complex for most clients I'd say, and if they don't want to support album collections, simply don't request & display them.

examples here:
https://plexapi.dev/api-reference/collections/create-collection
https://plexapi.dev/api-reference/library/get-collections-in-a-section
https://plexapi.dev/api-reference/content/get-items-in-a-collection

[ygabuev]

I've made a proposal some time ago, please take a look and make comments!
#237