Closed weirdcrap closed 7 years ago
It should work, but I haven't tested it personally with LibreSonic. Could you give me some details on the environment you used to set it up, so I can prepare a VM and test it with it?
The error message you get occurs when the plugin tries to contact the server for the first time (to validate that it actually responds to a "ping" command). It expects to get a standard response for a Ping request, if it doesn't then it considers that server to be unreachable (or otherwise not able to communicate with it). In essence, it's trying to call the server using this documented function: http://www.subsonic.org/pages/api.jsp#ping
You could try to check that on a browser manually and see what you get back. Perhaps the sever is listening in a different URL (maybe under a certain path)?
Are you using Token based authentication or Hex encoded Password? That makes a difference in the API being used, as Subsonic prefers "token-based" authentication but AFAIK that is not supported in some alternatives which only implement Hex Encoded Password instead (or plain text, but that's really insecure).
@midwan Sure.
This is running in a docker container made by the lovely folks at LinuxServer.io which is in turn running on top of UnRAID 6.3-RC6 (which IIRC is essentially a custom build of slackware).
I have this and a number of other server type media apps and the like all running behind an NGINX reverse proxy, though I even bypassed that and connected directly using my static IP and port and it didn't make a difference.
When navigating to my server using the ping documentation you linked I get this back:
`
`
I imagine the above URL in the response is my problem. It doesn't appear to be actually pointing to my server but rather a non-existent page (the main libresonic.org just redirects to the github page). I will look through my settings again and see if I can find where to change this.
Not sure if this makes a difference or not but the official SubSonic Android App has no problems connecting to the server and identifying with the way I have it setup now.
I have tried both Token (first) and Hex Encoded (second) and neither appears to work correctly, I just get the same failure message I mentioned above.
@weirdcrap
Yes, it definitely because it doesn't get a Ping response. As documented in the Subsonic API, it should come back with an empty
Is there a chance the LibreSonic API has a difference there? I'll have to check. EDIT: according to this (https://github.com/Libresonic/libresonic/blob/stable/libresonic-rest-api/src/main/resources/libresonic-rest-api.xsd) there isn't a Ping command listed at all in LibreSonic!?
I'll setup a similar environment to test it out, unless you come up with anything from your side until then. ;)
Interesting, the author of Libresonic claims he attmpts to keep Libresonic cross compatible with Subsonic applications where possible so I am surprised he doesn't have the ping function in the API.
Is there anything you would like from me to help you troubleshoot?
@weirdcrap Not for now, I'm thinking of implementing a "fallback" check for such cases where Ping fails, that would allow LibreSonic to work also. Once that's in place, I'll notify you here so you can test!
Note to self: Maybe a checkbox (something like "Test connection") to control if a Ping command is sent to the server to validate the connection. It should be checked by default, but if disabled we could skip the Ping command altogether and assume the server is there.
@weirdcrap Update: could you please test the following instead: http://your-server/rest/ping.view?u=joe&p=sesame&v=1.12.0&c=myapp
where "joe" is a valid username, and "sesame" is a valid password for your server?
Absolutely, I will test it tonight when I get home from work.
EDIT: Status=OK so looks like we are good.
subsonic-response xmlns="http://libresonic.org/restapi" status="ok" version="1.13.0"
@weirdcrap Thanks for that. It confirms my suspicion that it only works with authentication passed in but for some reason, it didn't work correctly earlier for you.
Could you please try with the latest released version (v2.9 currently) and see if that helps? Make sure to test both the default Token Based authentication and Hex Encoded Password methods, in case one does not work and the other does...
I still get the error that "the subsonic server did not respond in a way the plugin expected. Apply settings anyway?" regardless of which authentication method I attempt to use. Do I need to pass the rest api path to the plugin?
I forgot to mention in the OP that I originally tried this through an nginx reverse proxy I have setup though I also tried a direct connection using my static ip and application port and it doesn't seem to make a difference.
Currently my settings are: hostname: libresonic.mydomain.com Port: 80 Path: / username: musicbee password: *****
I have also tried a direct connection to the service: hostname: 123.456.789.123 Port: 4040 Path: / username: musicbee password: *****
Could you please set up a temp account for me to test with?
Kindly send the details at midwan at Gmail dot com.
Credentials sent.
@weirdcrap Thank you, I managed to recreate the problem with the account you gave me. The problem is due to the XML format of the response, and specifically while attempting to Deserialize it.
Since the plugin expects a Subsonic API response according to the documentation (see here: http://www.subsonic.org/pages/api.jsp#ping), it expects that the response will have the Root element named "subsonic-response". Instead of that however, LibreSonic returns "libresonic-response" as the Root element and the code does not know how to Deserialize that.
This is really a bug of LibreSonic, if they want to be 100% compatible with SubSonic they need to stick to the same API responses. Otherwise we need to explicitly add support for it as an alternative.
@weirdcrap From what I can see they have a related issue at LibreSonic's project page also: https://github.com/Libresonic/libresonic/issues/82
Thanks for your hard work, glad to know it wasn't just something I was doing wrong.
I will keep an eye on this thread and the one over at Libresonic and hopefully a fix isn't to far down the line. It sounds like they made those changes to differentiate themselves legally from the SubSonic project https://github.com/Libresonic/libresonic/issues/52 So I don't know if they will entertain the idea of rolling the API back to returning SubSonic responses.
@weirdcrap Yes, and from what I can see they reverted them because it caused several clients to stop working (e.g. DSub), so the current version they have on the repo is using the "subsonic-response". Try upgrading to that and test again, it should work... :)
Meanwhile I'll look into adding libresonic as an alternative.
From what I can see I am using the latest version of LibreSonic available. The Repo lists v6.1 as the latest release and my server is also running on 6.1.
I could try deleting and re-pulling the docker container.
Hm, maybe they haven't published this version with the fix? Although it was from last May...
I am no expert in GitHub but it looks like it isn't in the stable branch? https://github.com/Libresonic/libresonic/blob/stable/libresonic-main/src/main/java/org/libresonic/player/controller/JAXBWriter.java#L137
The latest release (https://github.com/Libresonic/libresonic/releases) contains the fix, at least in the source files that I just checked...
Ok, I will delete and recreate the docker and report back.
Ok, re-creating the docker container didn't fix it. Maybe the LinuxServer.io container is pulling from an older copy of the source? I won't pretend to know how docker, containers, github, and all that stuff mesh together lol.
I see this in the Versions history at the bottom of the container page: "29.11.16: Switch to building from release tags following v6.1 stable release."
Not sure if that means anything to you or not.
I will try another docker container template for Libresonic and see if that makes any difference.
Doesn't seem to matter which docker container template I choose, all of them have issues with the plugin.
It seems that the problem is not only the XmlRootAttribute, which is fixed in these versions of LibreSonic, but also the Namespace which indicates "http://libresonic.org/restapi" instead of the expected "http://subsonic.org/restapi". I didn't notice that earlier, sorry.
These are attributes in the XML response and they are expected with that exact naming from the receiving end to identify what it got (and how to parse it and make sense out of it). If the naming is different, then it's not recognized and cannot be Deserialized - hence the error message.
Let me see if I an figure out a better way to handle this...
@weirdcrap OK, I have a fix implemented and it seems to work. I'll prepare a beta binary for you to test with shortly...
@weirdcrap You can find version v2.10 beta in the Releases (https://github.com/midwan/MB_SubSonic/releases) section, please give it a try and let me know how it works for you.
Works great! Thanks for your hard work. It works with my reverse proxy setup and both Hex Enc and Token authentication are working.
Thanks for confirming!
@weirdcrap Is anyone still using Libresonic these days? It seems like people moved to Airsonic and from there to Airsonic-advanced now. I'm considering removing support for it, as the project seems dead for a few years now.
Just found out about MusicBee and have a LibreSonic server so I figured I would check out your plugin. I am using LibreSonic 6.1, MusicBee v3, and v2.9 of your plugin. Has this been tested/known to work with LibreSonic?
I am having issues getting the plugin connected to LibreSonic either through the domain name or the direct static IP address, I just keep getting an error that the server did not respond in an expected way (plugin did not got OK from server).
I can see that at least some information is getting up to the server as I have a new player entry in LibreSonic (though it isn't properly identified) and I am the only person using the server so I know the new player came from me.