Open amourao opened 5 years ago
Hey @amourao - thanks for the info. I'll try to get more information on how played_at
is calculated and document the expected behaviour better.
Hey @amourao - thanks for the info. I'll try to get more information on how
played_at
is calculated and document the expected behaviour better.
Hey @arirawr, thank you for your answer. I've been performing some additional tests over the last couple of days, and found that the timestamp is consistently being set at the end of the track. Maybe what happened on Nov 8th was just a bug.
Anyway, it would be great to have this behaviour clarified on the API documentation.
@arirawr Noticed this morning that "Played_At" timestamps still seem to be set to the end of the track. Assuming @amourao and my assements are accurate, this is definitely a departure from when I first started integration with your API and is really not ok, as it completely breaks my (and I assume several other) apps. Please provide an update on when this will be addressed. Thank you.
@arirawr: "Played_At" still seems to be set to the end time (end of track) rather than start time and results are delayed even after the track has completed playing. Anyone else still seeing this behavior?
I'm pretty sure we saw the same thing in 2017 or '18 and it was determined to be a bug.
@arirawr: "Played_At" still seems to be set to the end time (end of track) rather than start time and results are delayed even after the track has completed playing. Anyone else still seeing this behavior?
I'm pretty sure we saw the same thing in 2017 or '18 and it was determined to be a bug.
The random behavior is still not fixed, and can even result in some duplicate tracks on Last.fm, as it assumes that tracks are scrobbled both at the begining and end timestamps.
@arirawr This is not a documentation issue...it is a bug. When will it be fixed?! It's been broken for months.
@Kaprow I can confirm that this bug still happens as of today.
@Kaprow I can confirm that this bug still happens as of today.
@amourao Thanks for confirming. Yes, I'm still using a workaround in my code. How do we get them to respond to this, let alone address it?! I'm pretty sure @arirawr didn't even update the documentation like she said she would >.<
Hey @amourao @Kaprow I'm not at Spotify anymore and don't have any info on the status of this.
I can confirm that this bug still happens as of today.
@amourao I just ran a test and it looks like they fixed it. Can you confirm?
https://github.com/spotify/web-api/issues/918 Looks to be somewhat related. The information returned to me on this endpoint is out of order, wrong (played_at) and missing tracks listened to.
Does that sound similar to this issue?
@MichaelMelody91 it is not necessarily the same issue, but the API acts a bit funky sometimes. The main problem with this issue is that is is intermittent; sometimes it returns the wrong timestamp, but I don't know how to trigger it.
Has this been fixed yet?
Issue found on November 9th 2018.
Endpoint(s):
GET /v1/me/player/recently-played
Scope(s):
Steps to reproduce:
Expected behaviour:
Timestamps ("played_at") should always match the start or the end of the play/"scrobble". The API description is also not clear in the expected behaviour.
Actual behaviour:
Timestamp recording is inconsistent:
This is confirmed by my last.fm log (which is connected to my Spotify account): last.fm always stores the timestamp at the start of the play, irregardless of the inconsistencies in the Spotify API.
Results on both cases were recorded using the same device. It may be important to note that the device was offline during both recording temporal spans.
I've annexed results from both API for the two cases, Nov 7 and Nov 8.
scrobble_data.zip