ListenBrainz Endpoint: Now Playing

[vysmaty]

I've been troubleshooting with @michaelherger the ListenBrainz API implementation for scrobbling from Lyrion. And we came across a non-standard solution in Multi-Scrobbler.

Could I ask for a comment? ListenBrainz keeps information about Now Playing from the first message for the duration of the track. And all it needs is one message when it starts playing.

Multi-Scrobbler tells StaleAfter 30s and later Orphaned after 60 s from the initial Now Playing message. I haven't found where to adjust these intervals in Multi-Scrobbler (e.g. ENV).

Or is this behavior standard for ListenBrainz API? I couldn't find anything on this at https://listenbrainz.readthedocs.io/en/latest/users/json.html#submission-json or https://foxxmd.github.io/multi-scrobbler/docs/configuration/#now-playing

FoxxMD/multi-scrobbler@e9e5987/src/backend/sources/PlayerState/AbstractPlayerState.ts#L127-L142 FoxxMD/multi-scrobbler@e9e5987/src/backend/sources/PlayerState/AbstractPlayerState.ts#L91-L96

Thank you very much for clarifying.

[FoxxMD]

@vysmaty thanks for reaching out

The Player implementation for a Listenbrainz Source is functionally superficial. For Sources like Listenbrainz, Maloja, and Last.fm the Source is configured with a flag that tells it that scrobbles (track discovery) only occurs in returned history rather than from monitoring the "currently playing" track from the Source (which they don't really have). Returned history, in the context of the LZ Endpoint Source, is basically everything that is submitted to the endpoint.

For these types of Sources the stale after/orphaned triggers don't mean anything. They are left in for these Sources so that the UI eventually clears the "Player" if there hasn't been any submission/activity for awhile.

ListenBrainz keeps information about Now Playing from the first message for the duration of the track

This is interesting! I did not know that. I think it would be good to update these types of sources to make the Orphaned/stale time = duration of last returned track so that the Player UI more closely emulates Now Playing behavior from the upstream service.

Or is this behavior standard for ListenBrainz API?... https://foxxmd.github.io/multi-scrobbler/docs/configuration/#now-playing

The Now Playing functionality mentioned in the docs is for Clients only.

So, if you setup multi-scrobbler like Plex (Source) -> Listenbrainz (Client) then multi-scrobbler would POST to the submit-listen LZ endpoint with nowPlaying payload type.

This would not apply to a setup like Listenbrainz (Endpoint or Source) -> Maloja (Client)

I've been troubleshooting the ListenBrainz API implementation for scrobbling from Lyrion

What issues have you been having?

[michaelherger]

I probably should have said „debugging related to the Audioscrobbler plugin functionality in Lyrion“. No big problems with Multi-Scrobbler. I just tried to maintain the Now Playing state in the UI in Multi-Scrobbler and @michaelherger countered that it was non-standard, complicated and messy and that he didn't like it at all. And He was right. 👑

Heh... I never called it messy 😂

[FoxxMD]

If you set "nowPlaying": false for a client

It only disables reporting to Clients. MS will always use upstream, Source now playing data to update the UI.

I guess that's where my confusion and conclusion came from, that you need to send listen_type => 'playing_now' repeatedly to Multi-Scrobbler to get the Now Playing state correct in end Clients.

Yep and this is my error! Two things factored into this lapse:

Listenbrainz endpoint was implemented some time before I implemented Now Playing client functionality. The main goal for endpoint was to make scrobble submission work correctly. I didn't think anyone would be paying close attention to the UI for that either (UI is a secondary priority for MS which is supposed to work quietly without you having to look at it)

When implementing Now Playing functionality I didn't find any official guidance on the reporting interval. I think I literally just made POSTS and timed the Now Playing UI on last.fm and listenbrainz websites haha. I'm sure you guys know what I mean, trying to find concrete details on LZ api is not the easiest thing in the world. Nothing during my implementation work was really related to the endpoint/sources so it never occurred to me to synchronize the two.

michaelherger countered that it was non-standard, complicated and messy and that he didn't like it at all.

I mean, fair 😂 but also it's crazy you needed to dig into the lz source code just to find out what their behavior is! I'll get MS updated to follow this convention for the LZ endpoint. Also, just fyi this is not an issue for the LZ Source because it polls for now playing at a regular interval so you guys just found the one place where behavior isn't consistent 🙃

debugging related to the Audioscrobbler plugin functionality in Lyrion“. No big problems with Multi-Scrobbler.

Ah yeah that's what i meant. if its an issue specific to submitting payloads to listenbrainz, or using the api in general, happy to weigh in if I can.

additionally to ListenBrainz Client in the File example mentioned Koito.

Thanks for the tip, I'll get that updated too

[FoxxMD]

If you'd like to try out the docker image foxxmd/multi-scrobbler:pr-341 it includes updates to the Player UI to match what we discussed with some other ui improvements for these "Now Playing" type Players. #341

[vysmaty]

Thank you, that looks great. Status Now-Playing and it alternates with songs. And at the end it becomes orphaned after a time and clears after a minute interval. 😉

But unfortunately, I have encountered an unrelated significant Bug. The correct information about album does not arrive in Clients. release_name is lost somewhere at multi-scrobbler. I made an issue #342

[FoxxMD]

Released in v0.10.0 and available in foxxmd/multi-scrobbler:latest