[API Request] Discussion and clarification for how track-only artists should be handled in legacy endpoints

[dweymouth]

Type of change

API Clarification

Proposal description

We currently have a divergence between Gonic and LMS on how track-only artists are handled. Gonic does not assign IDs to track-only artists or return them in the getArtists response. This is also the behavior of Navidrome and Airsonic-Advanced (which have not implemented OpenSubsonic). This presents the problem that track-only artists are not navigable, but this is how original Subsonic handled it. LMS on the other hand assigns IDs to all artists and includes all the artists's album appearances as part of their discography. This has the problem of not distinguishing an artists's albums (that they are credited as an album artist on) from the albums that they just appear on.

This can all be handled with additional APIs or API extensions, but that is a separate discussion. This is just to discuss what the behavior with the existing APIs should be - I'd suggest going with Gonic's approach as it's closest to original Subsonic and is thererfore not a breaking change for existing clients.

Backward compatibility impact

No response

Backward compatibility

• No backward compatibility impact.

API details

Only album artists by default should be included in the getArtists response, and only the albums that the artist has an Album Artist credit for should be included in the albums list from the getArtist API. We can discuss further extensions to these APIs in other discussions, eg including a new section in the getArtist response to list the appearances, and new arguments to getArtists to include track-only artists or not.

Security impacts

No response

Potential issues

No response

Alternative solutions

No response

[Tolriq]

Gonic does not assign IDs to track-only

It does now that's the whole point of the issue ....

Since it returns "artists" [] to songs they must have ids if they have ids they exist, if they exist they must be returned in getArtist / Search and be accessible via getArtistInfo.

If he only want to returns albumArtists then he only return that field https://opensubsonic.netlify.app/docs/responses/child/

But now he is in violation of OpenSubsonic.

I really don't understand why and how you both conclude that this is a breaking change and that hiding data that would break other servers and clients is not breaking.
When a server does only support and handle albumArtist then it returns what it have, if a server support track Artists then it returns what it have the API was designed like that and OpenSubsonic definition with the roles support this.

There's not only track artists, there's Composers, musicians, and all the possible roles.

So again IMO, not returning all artists in the endpoints for artists is the breaking change.

If an artist exist and have an ID it must be accessible via the endpoints. I don't even understand why there's a discussion here.

If an artist does not have an ID and is only used as display value then it's something else, but unlike your first statement this is no more the case now.

And this is what happens in Navidrome too, any artist that is returned with an ArtistID is accessible via the artist endpoints and the search3 and get the getArtistInfo as it should.

[Tolriq]

They will do it when the API have added the filter to onlyShowAlbumArtist? Or they will offer a toggle in their server setting?

Why are you trying now to invoke future potential things? Do you think you can justify breaking things by making supposition that other servers will break things too and not find a proper solution and accept the API for that it is?

So the honest question is: Why do you absolutely want to justify your changes by saying the others breaks the API I do it right, instead of just saying it's my server I do what I want ....

This discussion will always be present whatever API improvement we make it would be based on the current status quo not what you want it to be, so if the improvement is adding a onlyAlbumArtist filter, you will be against because it's a breaking change for you ...

So no we are not going in circles we are going in opposite directions, that's what I try to explain, by diverging you create future breaking change that won't be possible to fix without breaking the others. Others that are already in prod ....

[sentriz]

Why are you trying now to invoke future potential things? Do you think you can justify breaking things by making supposition that other servers will break things too and not find a proper solution and accept the API for that it is?

So the honest question is: Why do you absolutely want to justify your changes by saying the others breaks the API I do it right, instead of just saying it's my server I do what I want ....

because it's important that servers have an easy path forward to be opensubsonic compatible, and changing getArtists/search3 is a huge breaking change for existing servers. we want all servers to opensubsonic compatible right? whats the point otherwise

They will do it when the API have added the filter to onlyShowAlbumArtist? Or they will offer a toggle in their server setting?

again, above, to be compatible, have an easy path forward for big and small servers, and not upset many many users, i really think all artists should be opt in, not out. if the setting is opt out, then all existing clients immediately break by not knowing about onlyShowAlbumArtist or whatever the filter may be. the most popular client like dsub is rarely updated for example. this is important

[Tolriq]

That's the thing they don't break..... They return more data, they now support more artists they return more artists this is logical and expected even if you don't want to see the other side ...

But right now you break LMS and the future evolutions...

Why break everything and not have a server setting for the users who don't want the data on legacy clients.
You add support for track artist. It's there. The user don't want to have them have an option to remove them if you want to please them.

Don't break the API and the future for your very own opinion ...

Servers do transcoding per client, they can offer legacy default setting per client too ....
Servers have settings to fit user needs, that's the point.

[sentriz]

That's the thing they don't break..... They return more data, they now support more artists they return more artists this is logical and expected even if you don't want to see the other side ...
Why break everything and not have a server setting for the users who don't want the data on legacy clients.
You add support for track artist. It's there. The user don't want to have them have an option to remove them if you want to please them.

they do break. again it's a selling point that servers handle album artists correctly and don't clutter artists lists. do you think other servers will suddently start returning 1000s of more artists that the user hasn't heard of?

if the user explicitly wants them that's fine. and i think it should be controlled over the api on a per request setting. not a global server side setting

[Tolriq]

If your server have a selling point to hide stuff then hide it by default with a setting. Stop justifying your choice by what others may do in the future and ignoring what users do today .....

So fun to talk to a wall. I give up, you're thinking right I'm wrong and do not understand anything. Good luck it's not worth it.

[dweymouth]

Gonic does not assign IDs to track-only

It does now that's the whole point of the issue ....

Ooohhh.. my apologies, I didn't realize that this was the change that Gonic made. I thought he was including track-only artists in the list but with a name only and no ID - which IMO is fine and good since clients could then treat them as non-navigable and display a plain label instead of a hyperlink. In other words they only exist as a display value in tracklist views. This is how Navidrome does it which of course hasn't implemented OpenSubsonic yet, but a (single-valued) track artist that has no albums will have its name set in the artist property of the track's Child object but the artistID will be unset.

I see why Tolriq is upset @sentriz - I agree now that IF the artist has an ID (ie it exists as a meaningful entity in the DB) then it is something he will want to sync into the offline DB and it should be reteieved by the endpoints including getArtists and search3. If you want to exclude track artists I think not assigning them IDs at all is preferable, until later when more API extensions enable the proper handling of track artists as a distinct thing from album artists.

Now for @epoupon's decision - I think it's also not optimal that the discography lists are cluttered with "appearance" albums for artists. If it were up to me, we would say that the album list returned in getArtist is only for albums that they're credited as an album artist on, and we'll have to wait for API extensions to properly expose the "appearances".

[Tolriq]

but i dunno seems like we're not getting anywhere with this line of thinking

The I don't give a shit about the current API usage and servers, I have a new feature I want it my way so I want all the others to comply or break ? ;) Yes that usually don't get anywhere ...

Again: 100% of the servers that return artistsID allow finding those artist in getArtists and Search3. You want to go your way, assume but this is the reality of the current situation. Now how you want to present it.

Or I wonder how Tolriq would feel about track artists with no IDs in the OpenSubsonic response

I'm just a simple client participant now, but the API state that the IDs are mandatory in the openSubsonic part, so I would advice against as it would break all the clients that relies on the schema and expect the field to be present.

[sentriz]

The I don't give a shit about the current API usage and servers

no, it's the "the i don't want my users to be flooded with 1000s of appearances in the artist lists" as i've said already

[dweymouth]

Alright last try at being a mediator here... @Tolriq, given that sentriz will probably not implement exactly what you want right now, would you prefer it a) as it is now, or b) with IDs omitted from track-only artists so that they exist in display name only and not as a DB entity? Keeping in mind this can all be resolved happily once we have additional APIs or extensions to properly deal with roles filtering

[Tolriq]

"I" "MY USERS" do you see a pattern here? ... It's your users, your server add a server option. Don't impose your needs to the others and breaking what is currently already in prod.

But as I said I no more care, I support 10 different media providers and already have code path per Subsonic servers, anything you do have no real impact on me, just on the global OpenSubsonic concept and future. This is time lost to try to discuss.

[sentriz]

it's not just me. it's gonic, navidrome, airsonic who all currently operate on album artists. and it will be an issue if they want to start supporting track artists with legacy clients who can't filter. their lists will be flooded

(this may be the case for ampache, funkwhale, and others - haven't checked)

but yes this is going nowhere so ill probably add a sever side option

[certuna]

I've encountered the same issue when adding track artist support to Navidrome (see this PR)
IMO there's two ways to do it:

• API allows to query albumCount, i.e. the client can ask for all artists where albumCount > 0
• no changes to the API, Client receives all artists, and before displaying them to users, drops those with albumCount = 0

The only real difference is bandwidth efficiency - you send over tons of artists that the client immediately discards.

[Tolriq]

Unfortunately not all servers handle the albumCount the same for track artists.
And some clients do not discard and do use the data.

The question here is about the definition of the API and handling of legacy clients. OpenSubsonic already expose the necessary data to filter without albumCount with the artist roles.

From the API naming and how it's done and some server currently do in prod, the API define that getArtists returns all artists even if some want to read it the way that better suit their own need.

If some servers support track artists and composers and use legacy clients they can offer a setting to by default only return album artists until the OS filtering solution is found like LMS do for example.

The discussion for the new filters is done at #57

So yes a new filter is needed for OS to better handle the roles, but the question here is about how to handle this currently without touching the API. Adding random quick hacks will just block the proper filtering.

[certuna]

Yes I know - the current Subsonic API, clients just ask for all artists and get all artists, it's up to the server to define what it considers "all artists". I think that's fine (it's how I've implemented it in Navidrome, if @deluan agrees with the approach: a serverside AlbumArtistsOnly = true/false setting). In the end it's up to the servers to set albumCount correctly (i.e. zero for artists without albums), and up to clients to filter them out if they want.