mirror of
https://github.com/koel/koel.git
synced 2026-04-25 16:56:02 +03:00
[GH-ISSUE #1085] Subsonic API #636
Labels
No labels
Authentication
Dependencies
Documentation
Feature Request
Flac
Help Wanted
Installation/Setup
Integration
Mobile
PR Welcome
Pending Release
Performance
Playlist
S3
Search
Sync
[Pri] Low
[Pri] Normal
[Status] Keep Open
[Status] Needs Author Reply
[Status] Needs Review
[Status] Stale
[Status] Will Implement
[Type] Blessed
[Type] Bug
[Type] Duplicate
[Type] Enhancement
[Type] Help Request
[Type] Question
[Type] Task
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/koel-koel#636
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @alex-phillips on GitHub (Sep 17, 2019).
Original GitHub issue: https://github.com/koel/koel/issues/1085
More of a feature request than an issue. Would you be willing to accept a PR that implements the subsonic API into koel?
@phanan commented on GitHub (Sep 18, 2019):
Hey! TBH I'm not familiar with Subsonic. What extra capabilities will it bring?
@alex-phillips commented on GitHub (Sep 18, 2019):
It's another self hosted music app but it's got a standard API that a lot of mobile apps use. This will essentially make it so you can use any of the mobile apps with koel.
For android, I use dsub.
@phanan commented on GitHub (Sep 18, 2019):
That sounds great. How exactly will the integration/implementation look like, though?
@alex-phillips commented on GitHub (Sep 18, 2019):
Here are the docs on the subsonic API: http://www.subsonic.org/pages/api.jsp
Obviously the endpoints will need to match, so although it would be nice, we wouldn't be able to do a 'subsonic' path prefix. Also, it looks like the response is all XML output. I know Koel uses JSON currently, so XML support would be added in. Again, this would only be for the subsonic endpoints though.
@phanan commented on GitHub (Sep 18, 2019):
Sounds good! I'm all for it.
Am Mi., 18. Sept. 2019 um 15:50 Uhr schrieb Alex Phillips <
notifications@github.com>:
@legobuild commented on GitHub (Nov 1, 2019):
I currently use Airsonic with play:sub on iOS. I've really wanted to switch over to Koel, but need offline caching on iOS. Would love this.
@JuniorJPDJ commented on GitHub (Jan 13, 2020):
Is it going in any way?
@phanan commented on GitHub (Jan 13, 2020):
@JuniorJPDJ I'm open to this but unfortunately won't have time to work on it, so I'm relying on you folks ;)
@alex-phillips commented on GitHub (Jan 21, 2020):
I'll see if I can start working on it this week
@antipiot commented on GitHub (Feb 11, 2020):
Subsonic API Would be a real + :-)
@alex-phillips commented on GitHub (Feb 11, 2020):
Unfortunately with the way Koel is built, I won't be using Koel anymore so adding in a Subsonic API isn't something I am interested in pursuing. Its method of populating the standard UI causes PHP to run out of memory with a rather large library, so continuing to use this isn't possible for me. Sorry :-/
@JuniorJPDJ commented on GitHub (Feb 14, 2020):
You could leave this issue open as I think that maybe someone would like to implement it in the future.
@alex-phillips commented on GitHub (Feb 14, 2020):
@JuniorJPDJ Sure thing!
@deanlongstaff commented on GitHub (Apr 16, 2020):
+1, i would like to use KOEL but i wont be switching until there is an API that i can use on a mobile app.
@Hukuma1 commented on GitHub (Aug 31, 2021):
Wish someone made this. :/
@legobuild commented on GitHub (Aug 31, 2021):
You can look at Navidrome as an alternative with the subsonic API.
@bilogic commented on GitHub (Jul 2, 2023):
@alex-phillips could you clarify on the out of memory issue? Do you mean the scanning of the music path from a browser?
@phanan commented on GitHub (Jul 2, 2023):
@bilogic Previously Koel loaded pretty much the whole library into the client. I deliberately chose to do so because I built Koel for my own needs, and my music library was/is never that big. However, newer Koel versions load songs/artists/albums progressively on demand, so memory should not be an issue anymore.
@smileBeda commented on GitHub (Apr 23, 2025):
Hi @phanan
First off — I’m a long-time Navidrome user and recently stumbled across Koel while browsing awesome-selfhosted. Gotta say, I was immediately struck by how beautiful Koel’s web interface is. It looks and feels much more modern and refined than Navidrome, and I’d really love to use it as my primary library frontend.
That said, I ran into a few things during setup (Docker-based) that I think are worth sharing:
The current Docker instructions work eventually, but they could benefit from clearer examples and expectations around a few common practices:
./musicto/music, which did the trick).php artisan koel:init --no-assetsstep: It’s critical, but it’s not automated. Most users do not like bothering with container commands (kind of defies the purpose of docker, I think, anyway). It might be worth including this in the entrypoint, so the garbling with container commands could be bypassed.Not a huge issue, but these things add friction - especially for new users evaluating Koel (and I have seen several online comparisons listing these two factors as the "why I did not choose Koel" reason).
This is the real showstopper for me. Without Subsonic API support, Koel can’t be used with the wide ecosystem of clients that rely on subsonic. For many users, it’s not just about choosing one app - it’s about supporting a workflow that may involve:
Think of Subsonic like the REST API of self-hosted music: it’s the universal standard that ensures interop and future-proofing. Not supporting it makes Koel harder to adopt in serious setups - even for users who love the UI - simply because we can’t connect it to the apps we already use, and have to either buy (or compile) the specifically for-it designed app.
I’m sharing this in the spirit of being constructive, because I really want to use Koel. It has massive potential, is super nice, feels slick af. But for those with large libraries and diverse client needs, Subsonic support is not a "nice to have" - it’s foundational.
As much I want, I cannot use Koel right now unless I force my family to switch their apps, which even if I build it on my own using the Github repo, is something I really would like to avoid.
Of course, I do understand one can't just "magically" implement it. It needs work - and thanks for the amazing work so far!
But I feel that you could, if integrating subsonic, actually gain quite a bunch of (eventually even paying) users who want to arrive in the 21st century and are tired of the rather 90s look of (example) navidrome. Most of us are using that because... it is well integrated.
Cheers!