Listen length is consistently ~10s below calculated track duration

[duckfromdiscord]

Describe the bug The new releases of multi-scrobbler, when scrobbling to a maloja client, track the length of plays on Spotify. At the end, a "tracked time" and a "wanted tracked %" are displayed showing how much of the song has been listened to. The raw payload is also displayed, complete with a track duration and a listen length.

After I listen to a full track beginning to end (i.e. the track starts and I do not skip around inside it, nor do I skip the track itself), the percentage is almost always somewhere between 89-95%, and the listen length is almost always 10-20s below the track duration,

To Reproduce

1. Set up a maloja scrobbler
2. Set up a spotify source
3. Double click on a song on spotify
4. Listen to it completely, without skipping

Expected behavior To be honest, I'm not quite sure if this behavior is how it's actually supposed to work, but I would think the listen length should be closer to the track duration.

Logs Demonstration with a track of length 3:17 on Spotify:

00:35:43+00:00 debug   : [Sources] [Spotify - unnamed] [Player ...-SingleUser] New Play: (34TufQ4EFzmDIFXJ3A8Yau) Kero Kero Bonito - Flamingo
00:35:43+00:00 debug   : [Sources] [Spotify - unnamed] [Player ...-SingleUser] Started new Player listen range.
...
00:39:00+00:00 debug   : [Sources] [Spotify - unnamed] [Player ...-SingleUser] Incoming play state () does not match existing state, removing existing: (34TufQ4EFzmDIFXJ3A8Yau) Kero Kero Bonito - Flamingo
00:39:00+00:00 debug   : [Sources] [Spotify - unnamed] [Player ...-SingleUser] Ended current Player listen range.
00:39:00+00:00 debug   : [Sources] [Spotify - unnamed] [Player ...-SingleUser] New Play: (...)
00:39:00+00:00 debug   : [Sources] [Spotify - unnamed] [Player ...-SingleUser] Started new Player listen range.
00:39:00+00:00 debug   : [Sources] [Spotify - unnamed] [Player ...-SingleUser] (34TufQ4EFzmDIFXJ3A8Yau) Kero Kero Bonito - Flamingo added after met thresholds with tracked time of 187.38s (wanted 240s) and tracked percent of 95.00% (wanted 50%) and not matching any prior plays
00:39:00+00:00 info    : [Sources] [Spotify - unnamed] Discovered => Kero Kero Bonito - Flamingo @ 2023-11-15T00:35:43+00:00
00:39:00+00:00 debug   : [Sources] [Spotify - unnamed] Last activity was at 2023-11-15T00:39:00+00:00. Will check again in interval 10 seconds.
00:39:00+00:00 verbose : [Sources] [Spotify - unnamed] Sleeping for 10s
00:39:01+00:00 debug   : [Scrobblers] [Maloja - unnamed-mlj] Refreshing recent scrobbles
00:39:01+00:00 debug   : [Scrobblers] [Maloja - unnamed-mlj] Found 40 recent scrobbles
00:39:01+00:00 info    : [Scrobblers] [Maloja - unnamed-mlj] Scrobbled (New)     => (Spotify) Kero Kero Bonito - Flamingo @ 2023-11-15T00:35:43+00:00
00:39:01+00:00 debug   : [Scrobblers] [Maloja - unnamed-mlj] Raw Payload: {"album":"Flamingo","artists":["Kero Kero Bonito"],"duration":187.376,"key":"[redacted]","length":197.528,"time":1700008543,"title":"Flamingo"}

Versions (please complete the following information):

• multi-scrobbler: 0.6.1

I'm quite happy that this feature has been added to multi-scrobbler. Anyone using maloja will now have a lot more insight on their scrobbles.

[FoxxMD]

This is due to the interval MS polls the source at.

With the state tracking MS does not consider a track being "played" until it gets back "I am playing" data from the source. Since it polls every 10 seconds consider this timeline:

• +0s -> MS polls spotify -> spotify player says "I am paused/stopped"
• +4s -> You click "start" on spotify player, song starts playing
• +10s -> MS polls spotify -> spotify player says "I am playing"

MS cannot account for those missing 6 seconds because all it knows is that at +0s spotify was not playing and at +10s it is playing. The same "missing time" occurs when spotify moves to the next track. It's easier to think of polling interval as the "highest resolution MS can track play duration and position" as.

(Spotify is the best of them as far as reporting play information but it does not report when, exactly, the current song started being played.)

There's definitely room for improvement here though. You could decrease the polling interval down to 5 seconds to make duration reported more accurate. I could also add a heuristic to check for something like:

• if 96% of the track is played or
• last track position from end of track was less than polling interval

then fudge the duration and report that 100% was played. But that's not exactly accurate since you could have clicked "skip to next track" in the last 10 seconds (say if the track has a long fadeout or outro you normally skip). I'd probably make this an opt-in option for sources.

[duckfromdiscord]

If it knows the length of the song at the beginning of the scrobble, could it wait that exact amount of time and then check the progress? The issue with fudging the duration is that, like you said, both skips towards the end and entire plays will show up the same.

[FoxxMD]

Good idea! I've added both strategies.

If a source (Spotify) reports player positional data MS now calculates polling interval based on proximity to the end of a track -- aiming for polling 2 seconds, then 1 second, before track ends. That gives it much more accurate data on how close the player got to the end of the track and also makes reporting position for the "next" track more accurate (usually within 1 second of track starting) before it returns to normal interval (10 seconds or w/e is in configuration).

Additionally, under these circumstances:

• source positional data reported
• track has duration reported
• MS has determined the player did not change state (has been in "Playing" state between previous and new track)

It will now also fudge start/end position if they are within 3 seconds of the true start/ending of a track with the assumption that network jitter or polling delays caused that inaccuracy.

---

One caveat I found that is specific to spotify: If your Spotify player has Automix enabled and Spotify uses it for your playlist/queue then MS cannot accurately determine when a track will end. This is because the track is "mixed" in your queue with a shorter play time than its actual length and Spotify does not report this modified play time in its API. This does not affect MS's ability to scrobble from Spotify but it will affect the accuracy of the duration MS reports was played -- the smart polling and fudging will not work, it'll just be the same as it was prior to these additions. I've added this disclaimer to the docs.

[FoxxMD]

This is released 0.6.2

[duckfromdiscord]

Just watched a song get scrobbled the second it finished. Awesome!