Severe timestamp inaccuracy for 'currently playing track'

[zachwinter]

When fetching a user's currently playing track, the following value is expected in the response (pulled from API documentation):

timestamp | integer | Unix Millisecond Timestamp when data was fetched

Based on my observations, though, timestamp doesn't represent when the data was fetched. It instead represents when the user started playback of the current song.

As of right now, the only way for an application to know current track progress to millisecond accuracy is to derive the value using Date.now() - timestamp. However, if a user manually seeks within a track this becomes impossible.

Endpoint(s):

• GET /v1/me/player

Scope(s):

• user-read-playback-state

Steps to reproduce:

• With a track playing, ping the endpoint multiple consecutive times. Observe that progress_ms updates properly, but timestamp remains unchanged.
• Observe that Date.now() - timestamp is equal to progress_ms with the addition of client/server latency.

Expected behaviour:

• timestamp should represent the exact moment that progress_ms was calculated.

Actual behaviour:

• timestamp represents the exact moment the user started playback of the current song.

[arirawr]

We're looking into this - thanks for the report.

[ophilbinbriscoe]

Is there a recommended approach for showing an accurate (ideally to the ms) representation of the current playback time through the API in the meantime? My use-case is synchronizing events to occur at particular times (derived from the audio features/analysis endpoints for a given track) for whatever track is currently playing. At the moment my app is always a few seconds off from the Spotify player that is actually playing the track.

[kalkih]

In the meantime, I'm checking the time before sending the request and then again the time on the response, I then compare the two times and divide by two for the delay, not sure how much this actually helps but it should hopefully account for the rough latency between Spotify API -> my app.

Also, the progress_ms reported from the /v1/me/player endpoint seems to be very unreliable, even on stable connections, it seems to differ quite a lot.
Interacting with Spotify, by hitting pause/play, seeking in the track, etc seems to make the progress_ms more accurate for a few minutes, at least from my experience.

[Bemmu]

Just tried this today, and it still seems to be broken. Expected that if I make multiple requests to api.spotify.com/v1/me/player while a song is playing, then the fetch time would change, but it does not.

[zachwinter]

@Bemmu Yes, this behavior hasn't changed.