duplicate scrobbles. about mpdas

[hrkfdn]

are you sure you're not running multiple instances of mpdas?

[carnager]

100% since this only happened every few songs.

[hrkfdn]

does the log (in debug mode) indicate multiple scrobbles for the same song?

[carnager]

i maybe have a clue what might cause this...
mpdas scrobbles the song, while keeping the now playing status as an extra item
https://fb.53280.de/W5zCCD/ - i guess this might cause issues from time to time.

also: the timestamp is wrong. it says 9 minutes ago, even though it scrobbled a few seconds ago.

[hrkfdn]

now playing submissions are separate and (according to the API doc) can not result in a scrobble. do you happen to be using mpd crossfading?

[carnager]

no crossfading here. i will keep it running and report as soon as another duplicate appears

[kchr]

I just ran into this issue, however in my case it was caused by crossfading (using ncmpcpp as client) and resolved by setting crossfading to 0.

[timss]

Seems to be an issue on last.fm's side triggering these errors. I tried changing crossfade, but did not have any effect.

First up, a successfull scrobble:

(21:38:25) [INFO] New song: ミドリ - ゆきこさん
(21:38:25) [INFO] Updated "Now Playing" status successfully.
(21:39:57) [INFO] Scrobbling: ミドリ - ゆきこさん

However, look what happens when the service is unavailable:

(21:41:33) [INFO] New song: ミドリ - かなしい日々。
(21:41:33) [INFO] Updated "Now Playing" status successfully.
(21:42:50) [INFO] Scrobbling: ミドリ - かなしい日々。
(21:42:54) [ERROR] Last.fm returned an error while scrobbling:
<?xml version="1.0" encoding="utf-8"?>
<lfm status="failed">
<error code="16">
    There was an internal error. Please retry your request.
</error>
</lfm>

Following this there's a mix of re-handshaking, trying to scrobble new songs as they are played and "now playing" being updated:

(21:42:54) [ERROR] Code: 16
(21:42:54) [ERROR] The service is temporarily unavailable, we will try again later..
(21:42:54) [ERROR] Re-Handshaking!
(21:42:54) [INFO] Last.fm handshake successful. SessionID: 37f67309fe59759dde8423a3e5ede70d
(21:42:54) [ERROR] Error scrobbling. Trying again in 5 minutes.
(21:44:11) [INFO] New song: ミドリ - お猿
(21:44:11) [INFO] Updated "Now Playing" status successfully.
(21:46:20) [INFO] New song: ミドリ - 根性無しあたし、あほぼけかす
(21:46:24) [ERROR] Last.fm returned an error while updating the currently playing track:
<?xml version="1.0" encoding="utf-8"?>
<lfm status="failed">
<error code="16">
    There was an internal error. Please retry your request.
</error>
</lfm>

The result can be something like this:

Haven't had the time to look for possible solutions, workarounds or if this is something that last.fm can fix on their side yet. Anyone got any input?

[timss]

Confirmed that this is indeed an issue on last.fm's side of things, and it is currently beeing looked into:

http://www.last.fm/forum/21713/_/2262164/_/21428069

[hrkfdn]

Thank you everyone for your investigations and input. I'm assuming that I can close this issue, then?

[timss]

Seems like it! Doesn't seem like this is something that can be (or should be) worked around in the scrobble client.

[timss]

Actually, according to a last.fm staff member duplicates can happen if the client assumes a request is timed out due to long response time, even though it will (eventually) be scrobbled correctly.

http://www.last.fm/forum/21713/_/2262164/_/21430393

Not sure if this is the case for mpdas, or my personal experience with duplicates using mpdas.

[hrkfdn]

I see. I'm a bit at loss here on how to handle such a situation, as HTTP timeouts definitely do happen and should be handled accordingly. How am I to know that the server has processed my submission regardless of the timeout?

[timss]

I don't know the details of the protocol, but it sounds to me like there could possibly be a scenario where a proper error code is returned by last.fm, even though the track will be scrobbled after a while..? E.g. the one I mentioned:

<?xml version="1.0" encoding="utf-8"?>
<lfm status="failed">
<error code="16">
    There was an internal error. Please retry your request.
</error>
</lfm>

If you can't trust the response you get things easily get a bit hairy. Maybe I'm misunderstanding things here, though.

Since a staff member recently replied to the thread I suggest you ask him. I was thinking I could maybe do it, but again, I don't know enough about this to not make a fool of myself or possibly make the situation confusing.

[timss]

Not much of a problem anymore as appropriate actions has been taken by last.fm staff at this point. Just thought I'd mention that it only affected 2.0 scrobblers (like mpdas), if it ever becomes an issue again.

http://www.last.fm/forum/21713/_/2262164/_/21438973

[hrkfdn]

Thanks again for your input/comments, guys!