Announcements

Help Wizard

Step 1

NEXT STEP

FAQs

Please see below the most popular frequently asked questions.

Loading article...

Loading faqs...

VIEW ALL

Ongoing Issues

Please see below the current ongoing issues which are under investigation.

Loading issue...

Loading ongoing issues...

VIEW ALL

API - v1/shows/{id}/episodes - resume_point returns incorrect data

Solved!

API - v1/shows/{id}/episodes - resume_point returns incorrect data

Plan

Premium

 

Country

UK

 

Device

Consistent across MacOS 14.6.1, Android 14, and reproducible at https://developer.spotify.com/documentation/web-api/reference/get-a-shows-episodes  

 

Operating System

MacOS 14.6.1, Android 14, and the API

 

My Question or Issue

I have had a nodejs script which, when executed, gets a list of episodes of a podcast, finds the oldest episode I haven't finished listening to yet, and then resumes playback of it on a device.  This has been working perfectly for months, but the last few days it's been playing the same episode every time. 

 

I had a chance to look at the issue today, and found that the API (for example: https://api.spotify.com/v1/shows/4pqW0HTIeZcx7vqHpwzmZj/episodes?market=UK&limit=50&offset=200) does not show the same resume point as the official clients on MacOS nor Android - where those devices see the episode as played, the API sees it "fully_played": false.  This is repeatable at https://developer.spotify.com/documentation/web-api/reference/get-a-shows-episodes, even after marking an episode as unplayed and then marking it as played again.

 

Attached is a screenshot of the MacOS desktop client and the same show in the API reference showing different playback states for episode 350 of No Such Thing As A Fish.

 

Interestingly, open.spotify.com shows a completely different set of played states, also attached.

 

Finally, I have tried this with another podcast (2dXkTgfC5mECruaLFUERe1), which shows the same behavior.  Attached is a screenshot of all 3 (open.spotify.com, MacOS Desktop, and API reference), all showing completely different playback states.  The Android app also shows a different set of playback states to the other three.  

 

Screenshot 2024-09-07 at 20.43.01.png
Screenshot 2024-09-07 at 20.40.06.png
Screenshot 2024-09-07 at 20.45.28.png
Reply

Accepted Solutions
Marked as solution

We believe we found the issue and deployed a fix. Is the resume point being returned correctly for you now?

View solution in original post

8 Replies

I've found the exact same issue.

 

When I pull all the data for episodes in my playlist the resume_point data is out of order compared to the episodes.

 

I'm 68 minutes into a certain episode - but this episode returns resume_point = 0ms whereas another episode in the playlist shows a resume point of 4125000ms (~ 68 minutes). The second episode in question is only 35 minutes in length so makes no sense to have this value.

 

A regression must have been made in the API that means resume point data does not match up with the episodes returned in the list.

I am experiencing the exact same issue. I filed this issue with more details but here's a summary:

  • GetShowEpisodes and GetEpisodes both return incorrect resume_point values.
  • GetEpisode works correctly, matching the results from the Spotify UI (open.spotify.com).

Since this API calls the same URI as GetEpisodes, just with one ID instead of many I think Matt's hunch in the above comment is right; since fetching the episode data one at a time returns the correct resume_point values, it seems the resume_point values are being shuffled when fetching multiple episodes at a time.

I just wanted to confirm that we have been able to reproduce this and are looking into it. Will provide an update when we have a fix in place.

Thanks for the update LambertSpot!

 

I did some more digging into it and realized that GetEpisode only returns valid results up to a point; if I make many (~26) sequential GetEpisode requests, at some point it starts returning incorrect resume_point values.

Marked as solution

We believe we found the issue and deployed a fix. Is the resume point being returned correctly for you now?

It looks like its working for me 🙂

 

Thanks for the fix!

 

Hi Matt,

I’m experiencing the same issues you’ve described with the resume_point values not matching the playback states shown in the official Spotify clients. It's frustrating when the API doesn't reflect the actual playback status, especially when relying on it for automating tasks with Node.js.

I’ve also noticed discrepancies across different platforms, which adds to the confusion. It seems like a regression might have occurred in the API.

Thanks for sharing your findings! I hope Spotify can resolve this soon so we can get back to smooth playback resumption. If anyone has updates or workarounds in the meantime, please share!

Cheers!

Forgive me, I didn't realise wasn't subscribed to notifications - I missed all the replies.  I just checked and can confirm this is fixed for me, thanks @LambertSpot and team!

Suggested posts