Sending an empty query to the search system is generally a bug if it doesn’t return an empty one. Of course, no such specification exists in the Subsonic API. A design that expects bulk submissions from Search is eccentric.
Am I correct in thinking that the policy has not yet been finalized and that the Subsonic API may be supported in the future?
Thanks a lot for the bad rating 
As explained there:
You can enable compatibility mode for outdated servers, the wizard should tell you that. (And the doc clearly state that if you server is maintained but does not support that, you need to contact me so I convince them), not put a bad rating based on false assumptions.
There’s a ton of work since a year to improve Subsonic API, and we now are building a public organisation to achieve that goal.
As you can see after a lot of works most recent updated servers do support the API.
So to resume: Subsonic API is fully supported including for outdated and no more maintained servers via the compatibility mode.
OK. I felt an arbitrary atmosphere in the UI and announcements. Symfonium seem to want to recommend non-canonical expected behavior as the default for Symfonium. I hope you do a great job!
You really did not read anything?
There’s no way to achieve sync without that mode, all servers have agreed on that and implemented it.
There’s compatibility mode that do not use search3 for the older servers.
There’s a work in progress to build a public org with all servers and client to define Subsonic API extension and solve all those issues with a proper API change. (The org is already up finishing some details OpenSubsonic · GitHub with already 10 members from servers and clients before going fully public)
What is your problem with any of those? Why bad rating on the insane amount of effort done to try to improve the global Subsonic API?
What server do you use?
All major updated servers where contacted and agreed and fixed and joined the organisation…
I added stars It’s OK? I can’t seem to connect to Airsonic, but I’ll try when I have time. In the first place, specifications such as bulk transmission and subsonic are incompatible. So, I’m excited to see what OpenSubsonic has to offer.
This is not a star issue this is more about having the proper information Always contact support and devs before bad rating with assumptions that can be wrong.
Airsonic was contacted Search3 API behavior · Issue #885 · airsonic-advanced/airsonic-advanced · GitHub they no more update their app. So just enable the compatibility mode when configuring the host as the wizard tells you to. (And the wiki see below)
[Wiki] Subsonic / OpenSubsonic - media provider configuration .
I would highly suggest that you migrate your server to something more secure and maintained like Navidrome. (https://www.navidrome.org/)
Thank you for your kind response.
But my suspicions are of a slightly different kind. Many bulk-preferring applications have in common that they ignore server-provided sorting and searching and implement their own degrading implementations. I hope it doesn’t turn out to be a bad wheel redevelopment. The second point is the quirky extension I mentioned at the beginning. There are already several types of apps that do bulk since the dawn of time. However, it was not an out-of-the-ordinary design.
Security assurance and server product selection can be considered separately. As many users have pointed out, Navidrome is not fully compatible with Subsonic and is not a replacement for some use cases. It’s not a bad idea to think of vanilla Subsonic or Airsonic as the baseline when investigating ecosystem fit and backwards compatibility. This is separate from security issues. We may have slightly different views on where to put the golden standard as an implementation reference. (It doesn’t mean you are wrong.)
I can’t see the whole picture of OpenSubsonic at the moment, but if backward compatibility can’t be secured, changing the name and namespace is one of the ideas. (Were there any such suggestions?) Claiming compatibility but having material differences is a bit of a burden for developers. I’m sorry if this way of thinking offended you.
I understood the information you provided. If there is no problem, you can close this ticket.
I do claim compatibility because I do have compatibility
Compatibility option is there to address the outdated servers. Vanilla subsonic is not updated since 3 years and have security issues by design. Airsonic is abandoned too. Yet I fully support them, it’s just that the sync is slower because the subsonic API have no end points to get all the songs in an efficient way.
Compatibility option is not a gimmick or a bad thing in the API usage, it’s just that Subsonic API lack things, so servers allowing fast sync are preferred since they offer a better quality of life to the users.
Many bulk-preferring applications have in common that they ignore server-provided sorting and searching and implement their own degrading implementations.
Symfonium is offline first and support many different other servers like Plex, Emby, Jellyfin, Kodi, …, it have it’s own sorting and everything, but sorry it’s actually way more powerful that what API support.
You should really see a little more what the app can do, to understand the choices.
Whatever changes and API extensions the org will bring in all cases it won’t be added to no more maintained server like Subsonic and Airsonic, so this is not really relevant to the compatibility mode.
Those servers will never offer the features needed to build advanced apps like Symfonium.
@tesshucom I was informed that you have your own server : GitHub - tesshucom/jpsonic: This is a repository for development. See https://github.com/jpsonic/jpsonic
That would have been simpler to tell.
Should I understand that you have no interest in adjusting your search3 endpoint or being part of the org?
If you won’t change search3 i’ll document your server as requiring compatibility mode.
