Unsupported base Subsonic features/endpoints: checking for them and dealing with them?

[NattyNarwhal]

As a client developer, there doesn't seem to be much guidance on how to handle features in base Subsonic that a server might not want to implement (i.e. chat, podcasts, radio, now playing, etc.), hasn't gotten around to yet, or is functionality from the future. If an API endpoint isn't implemented, unknown, or will never be implemented, it's ambiguous how a client should interpret the response. I'd like clarification in the documentation with two things:

• How do I check if an endpoint is implemented or not? I'd like to pre-emptively i.e. disable features in UI if they rely on features the server doesn't have.
  • OpenSubsonic extensions can be probed (check if OS in response, if so, consult extension API), but features in base Subsonic can't be.
  • It seems the best bet is to just try the endpoint anyways, but interpreting it is made trickier by the next question...
• If an endpoint isn't implemented and I try it anyways, what response should I get?
  • It seems Subsonic, Navidrome, and OC Music at least implement this in subtly different ways. Subsonic returns 404 HTML responses, Navidrome returns 404 or 410 (depending on if unknown or intentionally unimplemented) plain text bodies, OC Music (used to at least?) returned a normal Subsonic error code of 70.

[lachlan-00]

i know ultrasonic does a config check on server update/save.

It pings endpoints to see if they exists like podcasts / radio streams and disables the features.

when I test connection they check

• chat
• bookmarks
• shares
• podcasts
• videos
• jukebox

I assume they just do a getChat, etc and look at the responses then hide those tabs in the menu's

[Tolriq]

That's why OS was created, you can not and should not assume anything about the legacy Subsonic API, nearly everything have different implementations between the servers.

And since it's legacy and unmaintained for some servers, we can't change the doc to clarify things that servers will never update or implement.

So TL;DR; you face the joy of legacy Subsonic, the end goal will be that most endpoints will have a new better OS version at some point.

[tamland]

One could add a "features" extension that lists which features are supported by the server.

[Tolriq]

Yes and no, if it only covers legacy endpoint why not. (But then it means that the servers are updated so a client still needs to handle non OS servers so the benefit is minimal, we could simply enforce the kind of answers for OS servers on non implemented endpoints if servers agrees.).

But since OS adds new features that are optional and could be optional over endpoints that needs to be listed here this would mean that the features list would not be a finite list of know value at a point as new ones are added.
That would mean handling versioning of this and it starts to be complex for little benefits and overlaps with the actual extensions.

In all cases there's still a few legacy servers widely used due to the fact that currently there's no perfect subsonic servers that support some edge cases like raw file browsing and multi library and track artists that some users wants. The gap is closing and thanks to OS most people start to migrate to updated servers but a client should still support those for now.

When Navidrome as the most well known have multi artists, multi library and maybe file browsing (I think @deluan still don't want that one), with LMS having most and Gonic just missing track artists it might be time to start pushing users to OS servers specially with the more secure api Keys now in prod.

[paulijar]

I would vote for adding the endpoint like "baseFeaturesSupported" which would report the availability of the legacy Subsonic features. Certainly it wouldn't be vital as one can always test the availability of each service like Ultrasonic does but I feel that having a dedicated endpoint would be cleaner. Even if the new endpoint is just mildly useful, then on the other hand, the server-side implementation would be super-simple, so the "bang for a buck" would still be decent. And as it's easy to implement, I presume that almost all OS-servers would have it eventually.

It's a fair point that to support the legacy servers, the clients still couldn't rely on this new extension. But maybe in the distant future, some clients are willing to drop the support for the non-OS servers, and then there would be a cleaner API available for them.

[lachlan-00]

Wasn't there a version minimum requirement? like an expectation that subsonic was supported at 1.16.1 before extension. or maybe i just thought that in my head.

i would just assume that reported version is the valid subsonic version and then the server name denoted OS extension and that all subsonic endpoints were supported unless changed by OS

[NattyNarwhal]

I would vote for adding the endpoint like "baseFeaturesSupported" which would report the availability of the legacy Subsonic features. Certainly it wouldn't be vital as one can always test the availability of each service like Ultrasonic does but I feel that having a dedicated endpoint would be cleaner. Even if the new endpoint is just mildly useful, then on the other hand, the server-side implementation would be super-simple, so the "bang for a buck" would still be decent. And as it's easy to implement, I presume that almost all OS-servers would have it eventually.

TBH, it could also be added as part of getOpenSubsonicExtensions, i.e. an extension to indicate support (or explicit lack thereof), so no additional endpoints would be necessary.

And since it's legacy and unmaintained for some servers, we can't change the doc to clarify things that servers will never update or implement.

I think it's still worth specifying the behaviour for endpoints that don't exist or won't exist. There was already some inconsistency here, and it'd be useful to have that clarified.

In all cases there's still a few legacy servers widely used due to the fact that currently there's no perfect subsonic servers that support some edge cases like raw file browsing and multi library and track artists that some users wants.

I'm not sure what servers users tend to use, I don't do any analytics. I should ask...

[Tolriq]

@lachlan-00 no the minimum is lower, and even then not all servers provides all features hence the valid request.

@NattyNarwhal
That would mean an extension per endpoint, that's a lot of them for nearly no gains, specially as we'll probably build new endpoints for most if not all of them.

And the most non OS servers sill use are the AirSonic variants that have file mode and multiple libraries.
Most of my users would not migrate to Navidrome because of the lack of file mode and multiple libraries. (Some did start multiple navidrome instances, but this is a lot less efficient as soon as you have overlapping genres or artists)

If you make some OS features visible in your app, users will just tell you that X or Y does not work pretty fast.

So IMO this is not really necessary and we can define the official answer to non supported answer, but as long as this only covers legacy endpoints and so won't have interference with the future OS endpoints, I'm not against this.