4.4 not scrobbling when playing through iSub and Z-Subsonic

[jaume]

Hi there,

I just wanted to report an issue that I have observed since I upgraded to 4.4. With the new stable version I observed the following:

- Subsonic scrobbles when playing mp3 files through the web player
- Subsonic does not scrobble when playing mp3 files through iSub
- Subsonic does not scrobble when playing mp3 files through Z-Subsonic
- Log shows AudioScrobblerService lines for web plays
- Log shows no AudioScrobblerService lines for iSub and Z-Subsonic plays, not even the ones that show an attempt and fail to submit the scrobble

I have rolled back to 4.3 and the scrobbling is working fine in all three scenarios.

Is anyone else experiencing the same issue? Is this a bug or am I missing something?

Any help is much appreciated.

[jaume]

Just to clarify, I am using iSub and Z-Subsonic on a non jail-broken iPhone 3GS iOS 4.2.1

[haptic]

I'm experiencing the same thing, with the Android app and SubAir. It has something to do with external players.

[baaldemon]

This appears to be a feature and not a bug.

The io.PlaylistPlaylistInputStream.java class is responsible for calling the AudioScrobbleService

In 4.4 a change was made in the code to only scrobble if the players clienId is null. Which if you are using a client that uses the REST interface, which I believe those do, the clienId gets set, for example using the adroid client this clientId is set to "android".

I cant speak for the full reasons why, sindre would be able to clarify, but I believe with the added REST API method to call the Scrobbling service the client is now going to be responsible for the Scrobbling of songs. Which will be great once its implemented on your client.

So rather than relying on the server side to scrobble, which causes the songs to be listed as played once the file is downloaded and not actually when the file has been played, the client can now tell it to scrobble when you are listening and then when you have completed listening to the song. Which is a major advantage because it will reflect your actual music listening rather than your downloading/caching of each song. So be patient for your client to call the new API and it should resolve itself when that happens.

[jaume]

Thank you so much for the explanation.

If that is the case, that is then great news. Maybe Sindre can confirm as you said. However, if the behaviour is this, then it means that we will end up having a better scrobbling service.

Since you seem to know so much about this, you may be able to explain what is happening now that I am using 4.3. I have two completely behaviours:

1. When using Z-Subsonic 2.3 scrobbling works as it is supposed to work.

2. When using the newly released iSub 3.0 songs number 2 to second to last in a playlist are being scrobbled twice. So it looks like iSub is telling Subsonic to scrobble when I am listening and then when I have completed listening to the song causing 4.3 to scrobble those songs twice. See example log:

2/11/11 7:55:21 PM GMT] DEBUG AudioScrobblerService Successfully registered now playing for song 'Cato As A Pun' for user vidanes at Last.fm.
[2/11/11 7:55:22 PM GMT] DEBUG AudioScrobblerService Successfully registered now playing for song 'Heimdalsgate Like A Promethean Curse' for user vidanes at Last.fm.
[2/11/11 7:55:50 PM GMT] DEBUG InputStreamReaderThread (c:\subsonic\transcode\lame) Error writing mp3 output
[2/11/11 7:55:50 PM GMT] DEBUG AudioScrobblerService Successfully registered submission for song 'Cato As A Pun' for user vidanes at Last.fm.

As you can see 'Cato As Pun' is being submitted as 'Now playing' and as 'Submission' by iSub (or Subsonic) and 4.3 is registering two scrobbles to my last.fm.

If 4.4 follows the behaviour that you explain, should it not be registering properly from iSub 3.0?

[haptic]

This appears to be a feature and not a bug.

The io.PlaylistPlaylistInputStream.java class is responsible for calling the AudioScrobbleService

In 4.4 a change was made in the code to only scrobble if the players clienId is null. Which if you are using a client that uses the REST interface, which I believe those do, the clienId gets set, for example using the adroid client this clientId is set to "android".

I cant speak for the full reasons why, sindre would be able to clarify, but I believe with the added REST API method to call the Scrobbling service the client is now going to be responsible for the Scrobbling of songs. Which will be great once its implemented on your client.

So rather than relying on the server side to scrobble, which causes the songs to be listed as played once the file is downloaded and not actually when the file has been played, the client can now tell it to scrobble when you are listening and then when you have completed listening to the song. Which is a major advantage because it will reflect your actual music listening rather than your downloading/caching of each song. So be patient for your client to call the new API and it should resolve itself when that happens.

I appreciate the thorough response. I would love for scrobbling to work as you have described, since the "scrobbling while downloading" has been a minor annoyance since day one. However, when you say "be patient, the new API should resolve itself", how long should that be? A few minutes, hours, days? It's been almost a week, and not a single song has scrobbled from my phone yet.

Regardless, Subsonic is awesome and this one bug won't keep me from using it. It is annoying though.

[baaldemon]

However, when you say "be patient, the new API should resolve itself", how long should that be? A few minutes, hours, days? It's been almost a week, and not a single song has scrobbled from my phone yet.

What I mean by that is when the developer of the application you use updates their client code to call the new Scrobble REST api. Which I would hope would be the next time you have to update your software but I cannot comment on any actual client as I dont work on developing them.

When using the newly released iSub 3.0 songs number 2 to second to last in a playlist are being scrobbled twice. So it looks like iSub is telling Subsonic to scrobble when I am listening and then when I have completed listening to the song causing 4.3 to scrobble those songs twice. See example log:

Initially glancing at your log I was confused because the entries are out of order. But what looks like happened there was that the client played Cato As a Pun, causing a now playing submission for that song (not in the snippet you gave), finished downloading the song from the server and triggered the played submission but there was a lame issue, then restarted the download of the song. Im guessing the Lame error that was thrown caused this to happen but I cant say for sure. On the server side scrobbling is pretty stupid, it registers a now playing when the song download starts, and then a played once the download has finished. So if the client is requesting the song again it will call the scrobble service again.

[jaume]

Thanks again for the response.

I would like to clarify that upon checking the log after listening through Z-Subsonic, I am getting the same two entries as with the iSub app. How can then one be registered once and the other twice?

(..) what looks like happened there was that the client played Cato As a Pun, causing a now playing submission for that song (not in the snippet you gave), finished downloading the song from the server and triggered the played submission but there was a lame issue, then restarted the download of the song. Im guessing the Lame error that was thrown caused this to happen but I cant say for sure. (...)

Do you know if there is any way of fixing this issue?

It was never happening before I moved to 4.4. Only now that after moving to 4.4 I rolled back to 4.3.

P.S. I have tried to uninstall and reinstall 4.3 with no success. I would like to stick to 4.3 until they iron out the issues but without the double submissions. It is so strange that I was able to use 4.3 with no issues in the past and now I am having these. [/quote]