Control /stream scrobling action

Type of change

  • API tweak

Proposal description

Currently the behavior of /stream API endpoint is not well defined regarding scrobling / setting the last played status or the play count.

Some servers assume a call to that end point increase the playcount, some don’t. Some have internal settings to change the behavior (Ampache).

This is problematic for clients as they do not know what happen and if they need to call scrobble manually too.

This is also problematic for clients that can download transcoded media to device as the stream endpoint is the only one supporting that, yet this is not real play and should not be counted as such.

The proposal is to add a new parameter to the /stream API endpoint to allow control by the clients if this should count as a scrobble / play or not.

Backward compatibility impact

Adding a new parameter should not have impact as long as the default behavior when the parameter is not passed is kept.

API details

Add a new optional scrobble boolean parameter to the /stream endpoint to give back the control to the clients.

Security impacts

N/A

Potential issues

N/A

Alternative solutions

By default always consider that a /stream call should not scrobble but this would be a breaking change.


Proposal status

Proposed

Server implementation status

1 Like

(Aren’t you afraid it will make things complicated with timeOffset parameter?)

I think it would make more sense to just never scrobble on this endpoint: scrobbling systems (ListenBrainz, Last.FM) have strict rules for scrobbling, that the server cannot control from this endpoint.
Ex: serving the whole file at once does not mean the client has listened enough of the track.

Yes that’s my alternative solution but the big but is that it might be a breaking change for some users / cases.

Else we can just limit this to be a noScrobble option to allow forced opt out, but can’t force an opt-in and use the scrobble end point to force (As it should have been by default I guess)

I agree with @itm : This endpoint (/stream) should never scrobble. Some clients already changed to work like this (ex: substreamer) and I think adding new parameters to control this behaviour would only complicate things for everyone (too many options to support, both client and server sides). This might be a breaking change, but from what I see in the current client implementations it already works this way.

I think that to make things clear about our effort, we need to host a documentation site and make some of these points (scrobble on stream, Error 41, search3 with empty query, etc…) explicitly and more well documented. This would be THE reference used by “Subsonic” compatible clients and servers from now on.

I agree breaking is better, but breaking is also a pain point for some of the servers that might have to deal with the support (or have to update their own clients). Specially since in all case playing 1/2 second of a song should never consider this being played …

For public doc I also agree once we all (or vast majority) validate how it will work. I think that for discussion a forum is better than doing PR and everything as more fluid. But final decision needs to be organized for client to consume.

A proper tool for easy update of the doc with history would be needed, not my area of expertise.

pain point for some of the servers

Which servers? I think it is easier for them to remove code than it is for all of us to add code :slight_smile:

A proper tool for easy update of the doc with history would be needed, not my area of expertise.

A GitHub repository with a static site (using Hugo?) and auto publish to a github.io page would be enough, IMHO.

The servers that consider a stream a play and don’t call the scrobble in their clients. To adapt to not scrobbling this means their clients needs to scrobble. And if some old or unmaintained client does not do that, they will complain to the server dev before or at the same time as the client dev :slight_smile:
The goal is to try to not impact the current ecosystem, but have it evolve.

For example I have users here requesting that the percentage value I consider played should be configurable. To be able to offer that I need to be sure that the server does not update the playcount outside of my control. Not talking about duplicate scrobbling too.
Having a way to be sure is nice. Since the concept of the extensions is to be optionals, it’s hard to say if you support extensions you must obey to this new rule don’t you think?

Just trying to figure out the right target and path for this project to have a chance to succeed to even larger horizon that currently participating member (Even if current participation is already really great, thanks all for that).

A GitHub repository with a static site (using Hugo?) and auto publish to a github.io page would be enough, IMHO.

If anyone already know how to manage that then yes, maybe to avoid issue about it’s X client that pushes this for his own good, or it’s Y server, we could create a Github organisation for that to host it? (But again let’s finish the first round about who’s in and how. Waiting for Ampache and Gonic). I’ll also ping the last one you mentionned.

Is there any serious client that relies on the stream endpoint to automatically scrobble?
Personally I never considered to scrobble from this endpoint, and I won’t bother implement this even if we add an option to force it, as it just does not make any sense.

The problem I see is that the server can be configured to scrobble to some external service, and scrobbling services do not share the same scrobbling policy.
Unfortunately, clients don’t know anything about the scrobbling policy of the external service used by the server.
So one solution would be to add to scrobble the duration the song has really been listened to so that the server can decide to actually scrobble or not, based on the policy of the scrobbling service used.

There’s already a scrobble end point with submit or not that give the client full control. Do not submit to advertise you are playing so the dashboard can display then submit when it’s finished to actually update playcount and scrobble. The API is here.

So LMS does not auto scrobble, @deluan what does Navidrome do currently? I know Ampache does scrobble by default and have an hidden option to change that behavior.

API is here indeed but does not allow the client to tell the actual duration of the listen. We should not rely on the client to decide if the actual scrobble has to be done or not, if we want to respect the scrobbling service requirements.

More details:

lastFM:

A track should only be scrobbled when the following conditions have been met:

  • The track must be longer than 30 seconds.
  • And the track has been played for at least half its duration, or for 4 minutes (whichever occurs earlier.)

ListenBrainz:

Listens should be submitted for tracks when the user has listened to half the track or 4 minutes of the track, whichever is lower. If the user hasn’t listened to 4 minutes or half the track, it doesn’t fully count as a listen and should not be submitted.

Edit: and what if another service requires something else?

It’s the client that sends the information, in the end it will send what suit it’s service.

The main issue is that there’s 2 different things here. Play count and external app scrobbling.
The user should be in full control about when he want a song to be counted as played. It’s a frequent request and matters a lot for audio books too and resume points.

And do not forget offline playback. When the app is back online it can’t send fake data for 4 minutes to ensure it’s played and scrobbled. If it have to send fake data then the control is over.

Most of the users want 90 95% as played not 50%. Being played have impacts on personal mixes and everything.

Else we need to separate playcount / lastplayed value setting and external scrobbling and add 2 new API.

It’s a frequent request and matters a lot for audio books too and resume points.

Isn’t it the role of the bookmark endpoints?

And do not forget offline playback. When the app is back online it can’t send fake data for 4 minutes to ensure it’s played and scrobbled. If it have to send fake data then the control is over.

But why does this prevent the client from calling the scrobble endpoint and tell how long each song was listened to?

Most of the users want 90 95% as played not 50%. Being played have impacts on personal mixes and everything.

Can’t it be just controlled server side?

What I am saying is just to shift this from the clients to the server. The client just tells what has been listened to and for how long, and the server decides whether to scrobble/increase play count based on its settings.
I guess we don’t want the user to configure these same custom values for all clients that they may use with their server?

And what about Symfonium that support most servers :wink:

Users need to configure all the servers and for the servers that do not offer configuration have different result between songs?

All servers (Plex/Kodi/emby/jf) offers a way to give control to the client for many use cases including offline playback.
Let’s not cripple Subsonic by making it worse for clients.

Subsonic is what prevent me to have control hence this proposal and you want the exact opposite of the need.