last.fm loses currently playing song?

[equanimity]

Apologies if this is either a well-known issue, or a non-musicCabinet issue, or both. I did not notice it before in SubSonic, but I only used it for a day or two.

The issue is that when a new song starts playing, the last.fm recently played list correctly updates to:
Current Song (now playing)
Previous Song (just listened)

but while the song is playing, last fm will "lose" the currently playing track, and revert back to just showing
Previous Song (just listened)

After a couple of minutes (or when the next track starts), the missing track will reappear. So at the end of a playlist of 10 songs, all 10 will be correctly scrobbled, but the "now playing" item is missing a lot of the time.

Is there a way to fix this?

Thanks in advance.

[hakko]

From what I've learned so far, this is a last.fm issue.

Subsonic scrobbles songs to last.fm the very second you start listening to it. This is pretty annoying if you're skipping through a random playlist (and you want correct last.fm stats).

I rewrote this in MusicCabinet so that when you start listening to a song, a "Now playing" update is sent to last.fm. Not until 80% of the track has been played uninterrupted (and some extra rules for short songs etc), a scrobble is sent to last.fm. This makes for much more accurate stats.

I've tried sending continuous "Now playing" updates to last.fm to have the song constantly displayed while you're listening to it, but with no effect. Since the stats actually get correct, I've left it the way it is with just one "Now playing" update and then one scrobble.

If anyone else have used the last.fm API and found a better solution for this, feel free to post here.

[equanimity]

Hi Hakko,

Thanks, that is very clear.

My use case is that I use the first item on this list (via recenttracks.txt) to display the currently playing track on my desktop, since this works across any player I use.

I am not sure what the trick might be with the API calls to scrobble / updatenowplaying, but I offer 2 thoughts:
- could it be that track.updateNowPlaying.duration is somehow not being set or is corrupted so until the scrobble happens the track is removed?
- clementine has worked around this somehow. They have the expected behaviour that each track is "now playing" / never scrobbled if it is skipped near the start (I tested 5, 25 and 50 seconds) but is scrobbled if skipped near the end (2:00 of a 2:40 song, without seeking).

I will look into it more and let you know. Thanks again,

[hakko]

I'm not sending duration for the updateNowPlaying call. I'll try that, thanks!

[equanimity]

Great! Duration does not seem to be well documented. For a small thing like this i wish i could have just submitted a patch to you, but since i couldn't, thanks for addressing it.

[hakko]

Let's see if it works better from now on: viewtopic.php?f=4&t=9777&p=53923#p53923

[flvinny521]

If I can piggyback on this thread, can I assume that the change in scrobbling that you implemented (80% of track elapsed vs. immediate) would carry over to playing through the official Android app or DSub?

I want to make sure that my skips don't get scrobbled.

[hakko]

It's generally better to start a new topic for new questions, it helps people searching for an answer to the same question!

But to answer, I think that scrobbling from apps is their own responsibility. The server doesn't know if the app is fetching a song to listen to it, or to cache it. It doesn't know if the app plays a cached song over and over etc. But I'm not a 100% sure on this.

[flvinny521]

Good point, thank you for the reply.

[daneren2005]

1) It is the apps responsibility to scrobble AFAIK.
2) What I can remember of the way Subsonic/DSub handle it is that they scrobble when a song is "ended", regardless of whether or not it is done by reaching the end of the song or by skipping to the next song.