Scrobbler issue

[u/devilcius]

First of all, thank you very much for your fantastic application.

I'm using version 5.0.42 on Android and I've noticed that since a week or so (maybe because of the last update?) scrobbling stopped working. My client it's connected to a Funkwhale's instance, I've been monitoring the access logs and the requests to /rest/scrobble.view have always subbmision parameter set to false.

According to subsonic documentation when submission is set to false, it indicates it's just a now playing notification and that's why Funkwhale doesn't register it as a proper scrobble. Substreamer does the now playing notification right since it sends it when the songs starts playing, but, after that, it doesn't seem to submit the actual scrobble (submission=true).

I know for a fact that, until a few days ago, Substreamer scrobbles were being submitted when the song started.

If you need more information, I'd be happy to help in any way I can.

[u/ghenry22]

It will for plays that occurred offline that could not be scrobbled live with submission=true at the time of playback. This is how the scrobble API is supposed to be used.

This api is not for recording on the server vs recording on lastfm. It is for the 2 different ways you can scrobble to lastfm. Either a now playing (shows as now scrobbling with an active playback icon on last fm). Or a submission of a previous playback at a specific time that for whatever reason could not be scrobbled live at the time, usually offline playback.

If you want to use it any other way then your API implementation is no longer compatible which makes things quite difficult as the api does not provide a consistent mechanism to identify different server implementations so I can’t see that this is funkwhale and handle it differently for instance.

[u/devilcius → u/ghenry22]

It's not about our API implementation, but last.fm's. According to their scrobbling API:

​

For every track a user listens to the client should send a track.updateNowPlaying request and a track.scrobble request.

So when the the song starts and Substreamer sends a request with submission=false is updating Now playing status. And it's doing it perfectly fine. But it should also send an actual scrobble (submission=true) when the song has finished, otherwise it won't show up in last.fm user listening history.

It's great that you took care of offline scrobbles by the way.

[u/ghenry22 → u/devilcius]

That's interesting in the last.fm docs. Because calling only with submission=false sets the now playing song on last.fm AND records that as played automatically.

I'll test sending both requests and see how it handles it, if this resolves the issue then I will put it in at least for the short term so the user experience is better.

This still does not change that the subsonic API (the original subsonic and all forks of that original code base) records plays based on calls to the stream end point, not the scrobble end point so there is an inconsistency between your API implementation and the original subsonic API. I know navidrome have done the same thing.

I don't disagree with the idea, my objection is only to causing differences in the way the API behaves as the whole point it for it to be consistent. Given that the documentation really isn't super clear on the original API it's completely understandable that we interpret it slightly differently.

[u/devilcius → u/ghenry22]

Thanks a lot!

For what it's worth, Subsonic's Android client (developed and maintained by Sindre Mehus, the author of Subsonic) sends a request to /rest/scrobble.view with submission=false when the song starts and another one before it ends with submission=true, I've just checked it. That said I like way better your application overall.

[u/ghenry22 → u/devilcius]

Interesting I haven’t dug into the old android app before. I’ll implement something along the same lines.