Add support for Funkwhale

[agateblue]

Hi there! I'm just discovering httpdirfs through the *Sonic support, and it's really interesting.

I've tried it with Funkwhale (an audio streaming server I work on), since  Funkwhale implement a subset of the Subsonic API. However, it doesn't work as httpdirfs rely on non-ID3 based subsonic endpoints (and Funkwhale only supports ID3 based endpoints).

As per the subsonic documentation:

File structure vs ID3 tags

Starting with version 1.8.0, the API provides methods for accessing the media collection organized according to ID3 tags, rather than file structure.

For instance, browsing through the collection using ID3 tags should use the getArtists, getArtist and getAlbum methods. To browse using file structure you would use getIndexes and getMusicDirectory.

Correspondingly, there are two sets of methods for searching, starring and album lists. Refer to the method documentation for details.

Would you be interested by bringing compatibility with ID3 based Subsonic servers? Unfortunately, I cannot help with the code itself (not a C dev), but we have an open demo server (https://demo.funkwhale.audio) you can use for your tests, and I'm available if you want to discuss this further.

I'd also be happy to add httpdirfs to https://funkwhale.audio/apps/ if we manage to make this work :)

Anyway, thank you for the great project!

[fangfufu]

Hi,
I am happy to add ID3 API support.

1. Are you a developer for Funkwhale?
2. Do you have an API documentation for Funkwhale, like the one for Subsonic?
3. Do you have a server that I can connect to? Please email me with a server's login credential, if necessary. I don't actually run a Subsonic server. I have been using @jcharaoui 's server.

[agateblue]

Terrific!

Are you a developer for Funkwhale?

Yes, you could say I'm the maintainer :)

Do you have an API documentation for Funkwhale, like the one for Subsonic?

We do have an API documentation that list the supported endpoints, but I'd recommend using the one at http://www.subsonic.org/pages/api.jsp, since we used this one as a basis for our implementation.

I'm not 100% sure of the endpoints you'll need to implement in the context of a Fuse FS, but possibly:

• http://www.subsonic.org/pages/api.jsp#getArtists
• http://www.subsonic.org/pages/api.jsp#getArtist
• http://www.subsonic.org/pages/api.jsp#getAlbum

To ensure backward compatibility, you may want to provide a CLI flag like --sonic-id3 to indicate the type of API httpdirfs should use. Other apps, such as DSub are doing something similar (via a "Use ID3 tags" checkbox).

Do you have a server that I can connect to?

Sure! You can use https://demo.funkwhale.audio for your tests (credentials are demo and demo). The server is reset every few hours.

[fangfufu]

Cheers, I will let you know when I get some more done. It should be fairly easy.

While you are here, I do think that this project might be suffering from a bit of feature bloat - it was originally designed for mounting HTTP directory listings, now it supports Subsonic API as well. It is really bad for advertising purposes - what am I meant to say to people, when they ask me what this software does? Do you reckon I should fork/split the software, so there is one software that supports HTTP directories only, and another one that supports Subsonic API? The only reason these two features exist in one software, was because it was easier to add support for Subsonic API on top of existing code, than doing everything from scratch. @jcharaoui said similar thing over the email as well.

[fangfufu]

@EliotBerriot, are these valid? https://docs.funkwhale.audio/swagger/

[agateblue]

While you are here, I do think that this project might be suffering from a bit of feature bloat - it was originally designed for mounting HTTP directory listings, now it supports Subsonic API as well.

That's a hard question :D

To be frank, I'm not familiar enough with the project to give a definitive answer, but I kind of understand why Subsonic support doesn't sound like a core feature of httpdirfs.

That being said, eventhough *sonic servers aren't pure HTTP dir listing servers, you're still mounting HTTP content from these, so it's not entirely weird either.

An option could be to consider the *sonic logic as a plugin, and advertise it as such. A few benefits:

• It's easier for newcomers to understand it's not the core feature
• Eventually, it makes it possible to integrate other backends without compromising the core project

Since all the CLI flags are namespaced under --sonic-*, you're already good on that side :)

@EliotBerriot, are these valid? https://docs.funkwhale.audio/swagger/

This are valid docs, but for our non-sonic API. If you're willing to implement ID3-based Sonic endpoints, you shouldn't use these.

[fangfufu]

@EliotBerriot Funkwhale's created timestamp does not follow the same format as Subsonic / Airsonic.

Funkwhale produces:
created="2019-10-21 14:42:31.284232+00:00"
whereas Subsonic / Airsonic produces :
created="2017-04-14T12:36:28.000Z"

Could you file a bug report please?

[fangfufu]

@EliotBerriot, Funkwhale's output the following API call are not the same as the ones spit out by Subsonic / Airsonic:

• http://www.subsonic.org/pages/api.jsp#getArtists
• http://www.subsonic.org/pages/api.jsp#getArtist
• http://www.subsonic.org/pages/api.jsp#getAlbum

Other than the difference of created, Funkwhale also doesn't output path, which is used for setting the filename.

I am not sure if I want to add something specifically for Funkwhale, mainly due to the lack of API documentation from Funkwhale. I don't think pointing me to Subsonic's API documentation is sufficient, as Funkwhale's output is sufficiently different.

I am happy to add support for Funkwhale, if

• Funkwhale fixs the relevant API output, so it is compliant to Subsonic standard,
• or if Funkwhale documents the format of the required API, and guarantee that it is frozen.

[agateblue]

Thank you for having a look @fangfufu!

I'll fix the created and path issue, I'll submit a MR for both these items on Funkwhale side and let you know when it's deployed on the demo site (probably next week).

[agateblue]

@fangfufu this is the corresponding MR on our side: https://dev.funkwhale.audio/funkwhale/funkwhale/merge_requests/943

Once it's reviewed and merged, it will be deployed ~6 hours later on https://demo.funkwhale.audio.

Let me know if you need anything else :)

[fangfufu]

@EliotBerriot , your requested feature is added in c2be88c. I note that your demo server still hasn't been updated for my requested changes.

I wrote some code to compute the required path using track, title and suffix, so it is not strictly necessary for your server to return path. However, path would be used in preference to track, title and suffix on servers that support Subsonic API properly. I am not going to write code to cope with your server's created, as it would break compatibility to normal Subsonic server. Right now, HTTPDirFS will read the date portion of your created element, your current implementation does not completely stop HTTPDirFS from functioning.

Finally, your server's return header does not have Accept-Ranges: bytes, which implies that your server does not support HTTP Range Requests. I actually added a new check to for this header. So to make HTTPDirFS work with Funkwhale, you need the following two flags: --no-range-check and --sonic-id3

[agateblue]

The update has been deployed on https://demo.funkwhale.audio, and I confirm this is working with the latest version of httpdirfs 🎉

Thank you so much @fangfufu, I'm going to update our website ensure it includes proper link to your project!

[fangfufu]

@EliotBerriot , thanks! Advertising are much appreciated! 😊