ListenBrainz plugin: Support for custom ListenBrainz URL for self-hosted API-compatible scrobbler instance, e.g. Koito

[nupulu]

It would be great if we could self-host a ListenBrainz API-compatible scrobbler such as Koito.io and point MA ListenBrainz Scrobbler plugin top use the self-hosted instance instead of the cloud-based original ListenBrainz service.

[OzGav]

@ijc

[ijc]

@nupulu I'd be happy to review a PR for this. I can't say if/when I would get round to implementing it myself.

[DutchJaFO]

maybe something like the virtual device variants that HA itself uses to allow support for devices that have the same protocol under a different name ?
It would be nice if this could be as userfriendly with an auto-discovery option if possible.

[myanesp]

Any updates on this? I use multi-scrobbler for scrobbling my listenings to the services I want, local-first, like Maloja or Koito, and would be really nice if we can scrobble listenings from MA to multi-scrobbler. It is compatible with LB endpoint so I think it should be easy to implement.

Many thanks anyways!

[relic664]

I've looked at this as I'm currently suffering with having LastFM as a scrobbler for my Koito instance.

There's a problem in that the MA ListenBrainz plugin relies on liblistenbrainz. I took a look at the upstream and the problem is the client.py has a hardcoded value for API_BASE_URL, so there's no way (currently) to modify it.

There's a couple of options

1. We could raise the issue upstream, but since liblistenbrainz is maintained by metabrainz I'm not sure how receptive they would be to support other API endpoints outside their own. This would be a really minimal change (i.e., def __init__(self, API_BASE_URL='https://api.listenbrainz.org').
2. We could create a thin client within MA to support this feature and only implementing the two methods submit_playing_now and submit_single_listen. Obviously this has a non-zero increase in maintenance burden, but we could minimize it by only using the MA client for when a user has a custom URL endpoint, otherwise still leverage liblistenbrainz's client.py.
3. We could create a fork of liblistenbrainz and make the changes required to specify API_BASE_URL instead of using a hard coded value.

@ijc what do you think? I don't mind raising (1) upstream and falling back to (2) if they're not receptive. Happy to contribute and help push this along.

[ijc]

I don't mind raising (1) upstream and falling back to (2) if they're not receptive

SGTM, go for it! Thanks, Ian.

(1) would be best, but failing that I wonder if it would be possible to monkeypatch the API_BASE_URL in listenbrainz.client at runtime.

[FoxxMD]

1. Should be pretty easy. Metabrainz as an org is pretty active on github and they maintain selfhosted deployments for both metabrainz and listenbrainz. Using your own instance is part of the LZ design, so I imagine updating the lib to use a user-supplied URL would be aligned with their goals.

[relic664]

For anyone interested in monitoring progress, I've opened a PR here metabrainz/liblistenbrainz#41. If/when that's merged, I can work on the small set of changes needed to support a custom URL in music assistant.

[relic664]

@ijc I got the PR merged upstream and it's included in 0.7.0 (https://github.com/metabrainz/liblistenbrainz/releases/tag/0.7.0).

Do you want me to prepare a PR to support this is MA or would you like to?

[ijc]

Please go ahead, I'm not planning to work on this myself in the short term.

[relic664]

PR is open here music-assistant/server#3228

[relic664]

PR has been merged and this feature will be available with the next server version release.