[Bug] Better support for lms using the Subsonic API

[FibreTTP]

Describe the bug
There are a few "bugs" that stop Koito from working properly with the music server lms.

First things first, a, uhh, minor issue... lms only supports scrobbling to ListenBrainz API endpoints with an API key in the form of a UUID (since ListenBrainz API keys are UUIDs).

The following issue doesn't concern scrobbling, but how the configured Subsonic server is authenticated with.

Since lms doesn't support the token+salt method of authentication in Subsonic, Koito will not start if configured with it (since it fails to authenticate). lms does however support the older username+password auth scheme, but with the password being an API key set in its interface... again, however, setting u=USERNAME&p=APIKEY as the SUBSONIC_PARAMS also fails, but because &v=1 is appended, which causes lms to crash. (this is a separate bug for lms, it probably shouldn't crash. but the issue is that &v=1.0.0 is the correct formatting.)

Koito/engine/engine.go

Lines 113 to 115 in 0ec7b45

	if cfg.SubsonicEnabled() {
	l.Debug().Msg("Engine: Checking Subsonic configuration")
	pingURL := cfg.SubsonicUrl() + "/rest/ping.view?" + cfg.SubsonicParams() + "&f=json&v=1&c=koito"

The recommended way to authenticate with lms, is to support the apiKeyAuthentication extension in OpenSubsonic. This allows sending ?apiKey=APIKEY in lieu of u+p / u+t+s. But of course, setting SUBSONIC_PARAMS to ?apiKey=APIKEY also doesn't work due to &v=1.

You can get past the initial ping check by appending &v=1.0.0 (or any future version) to your parameters variable; Koito starts fine because lms accepts it. But the hardcoded &v=1 is still present in the API request.

However, having &v=1.0.0 (or any future version) in your SUBSONIC_PARAMS variable causes more issues. When Koito searches for cover art, it first searches the Subsonic server for the album. Again, a version parameter is hardcoded into the request, which of course is required (and is formatted correctly this time: 1.13.0), but having multiple of that version parameter is probably not supported in the Subsonic spec, and promptly crashes lms (it really needs to not crash and just report an error).

The above paragraph isn't actually replicable with Koito since you can't scrobble to Koito from lms anyway. The errors were found with curl, simulating what Koito would do based on the following:

Koito/internal/images/subsonic.go

Lines 48 to 52 in 0ec7b45

	const (
	subsonicAlbumSearchFmtStr = "/rest/search3?%s&f=json&query=%s&v=1.13.0&c=koito&artistCount=0&songCount=0&albumCount=10"
	subsonicArtistSearchFmtStr = "/rest/search3?%s&f=json&query=%s&v=1.13.0&c=koito&artistCount=1&songCount=0&albumCount=0"
	subsonicCoverArtFmtStr = "/rest/getCoverArt?%s&id=%s&v=1.13.0&c=koito"
	)

Koito/internal/images/subsonic.go

Line 119 in 0ec7b45

err := c.getEntity(ctx, fmt.Sprintf(subsonicAlbumSearchFmtStr, c.authParams, url.QueryEscape(mbid.String())), resp)

Expected behavior
Firstly, Koito should support creating API keys in the form of UUIDs. Though I'm not opposed to creating a feature request in lms to support scrobbling to ListenBrainz endpoints with non-UUID API keys.

I think the "easiest" way to support authenticating with lms is to support OpenSubsonic with apiKeyAuthentication, and to send &v=1.13.0 with all Subsonic API requests.

Screenshots/Logs
API key auth (lms crashes, Koito exits):
SUBSONIC_PARAMS=apiKey=APIKEY

{"level":"debug","time":1772731985529,"message":"Engine: Checking Subsonic configuration"}

{"level":"fatal","error":"Get \"http://lms.home.arpa:5082/rest/ping.view?apiKey=APIKEY&f=json&v=1&c=koito\": EOF","time":1772731985554,"message":"Engine: Failed to contact Subsonic server! Ensure the provided URL is correct"}

API key auth with added version parameter in env variable:
SUBSONIC_PARAMS=apiKey=APIKEY&v=1.16.1

{"level":"debug","time":1772732171938,"message":"Engine: Checking Subsonic configuration"}

{"level":"info","time":1772732171945,"message":"Engine: Subsonic credentials validated successfully"}

Username+Password (API key) auth (lms crashes, Koito exits):
SUBSONIC_PARAMS=u=USERNAME&p=APIKEY

{"level":"debug","time":1772733342272,"message":"Engine: Checking Subsonic configuration"}

{"level":"fatal","error":"Get \"http://lms.home.arpa:5082/rest/ping.view?u=koito&p=APIKEY&f=json&v=1&c=koito\": EOF","time":1772733342285,"message":"Engine: Failed to contact Subsonic server! Ensure the provided URL is correct"}

Username+Password (API key) auth with added version parameter in env variable:
SUBSONIC_PARAMS=u=USERNAME&p=APIKEY&v=1.16.1

{"level":"debug","time":1772645892385,"message":"Engine: Checking Subsonic configuration"}

{"level":"info","time":1772645892393,"message":"Engine: Subsonic credentials validated successfully"}

Version (please complete the following information):

• Koito version: v0.1.7

Additional context
N/A

[gabehf]

I agree the Subsonic implementation is pretty basic. I'll rework it to hopefully fix all of the authentication issues soon.

As for the non-uuid API key problems, the ListenBrainz docs specify a user token as "a unique alphanumeric string" rather than a UUID, so I don't think it's out of spec for Koito to have just a random string as an API key rather than a UUID. So, the preferred fix for this would be to open an issue on lms to support non-uuid user tokens, (maybe only when a custom listenbrainz url is specified?), but I wouldn't necessarily be opposed to making all future API keys generated by Koito to be UUIDs ina future version if lms doesn't want to make the change.