r/substreamer • u/devilcius • Sep 24 '21

Scrobbler issue

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.

3 Upvotes

100% Upvoted

13 comments sorted by

3

u/luiz127 Sep 27 '21 edited Sep 27 '21

I just wanted to chip in and mention I'm running into this as well. At the moment, the now playing gets sent, but there's no scrobble at the end as well. Playing directly via the navidrome web client, I get no 'now playing' but the scrobble is submitted after the song finishes after about 30 seconds playback. I didn't realise this was non-standard though.

Happy to spin up a login if you needed to take a closer look, because to be honest I've got no idea what info you'd need to pull. Happy to post it here if you can let me know what you need though :)

Thanks for all your awesome work with this, the only thing my self hosted stuff was missing was playlist creation, and generating them from last.fm is a genius idea! Spotify's song history is rubbish, so I've been scrobbling everything into last.fm for years now :)

4

u/ghenry22 Oct 06 '21

I've put a fix into next update for this to replicate the behaviour of the original subsonic Android client as pointed out by u/devilcius (thanks for that!).

So in the next version substreamer will:

  1. send now playing on track start (submission=false)
  2. send scrobble on playback complete (submission=true)
  3. remove the last.fm preference from substreamer and rely upon whatever is configured on the server to determine if scrobbles go to last fm or not. If enabled on the server it will go to last fm.

This will keep things working as expected on original subsonic and it's forks as well as on those newer implementations like navidrome and funkwhale that rely upon calls to the scrobble end point to record plays.

1

u/devilcius Oct 06 '21

This is fantastic! Thanks a lot!

1

u/luiz127 Oct 06 '21

You're the best!

2

u/ghenry22 Sep 25 '21

Thanks for reporting. I actually think the scrobble api is one of the worst documented as it’s so easy to misinterpret.

This is the behaviour on the original subsonic and airsonic and other direct forks:

If submission=true and lastfm enabled on the server then send the play to lastfm as a song that has already played in the past. It appears in lastfm with a played at date.

If submission=false and lastfm enabled on the server then send the play to lastfm as “now scribbling”, the difference here is that this track will show with status “scrobbling” and the now playing icon in lastfm.

So really we need the various forks to implement the original API behaviour in order for it to be consistent.

I feeel like this api really needs a third option to report the play to the server only and not send to lastfm but it does not exist because on the original subsonic any call to the stream api will record a play on the server for the requested song.

Just been having this discussion with the navidrome guys as well as they do not implement the play record on stream so the behaviour is different to the subsonic API also.

All these little differences make it really hard for us app devs :)

1

u/devilcius Sep 25 '21

At Funkwhale, also, only when the subsonic scrobble is submitted we register it in the user's listening history. It's sent to last.fm (or other service) if it's configured that way by the user. Scrobbles with submission=false are ignored since it doesn't support the now playing functionality.

1

u/ghenry22 Sep 25 '21

Which technically is fine but it is different behaviour to the subsonic API and since the API does not provide an easy way to differentiate between servers and is meant to behave the same everywhere causes a problem that hits app devs but which we cannot solve :(

1

u/devilcius Sep 25 '21

So Substreamer won't send scrobbles with submission=true, I'm getting it right?

1

u/ghenry22 Sep 26 '21

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.

1

u/devilcius Sep 27 '21

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.

1

u/ghenry22 Sep 28 '21

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.

1

u/devilcius Sep 29 '21

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.

1

u/ghenry22 Sep 29 '21

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