Type in your question below and we'll check to see what answers we can find...
Loading article...
Submitting...
If you couldn't find any answers in the previous step then we need to post your question in the community and wait for someone to respond. You'll be notified when that happens.
Simply add some detail to your question and refine the title if needed, choose the relevant category, then post.
Before we can post your question we need you to quickly make an account (or sign in if you already have one).
Don't worry - it's quick and painless! Just click below, and once you're logged in we'll bring you right back here and post your question. We'll remember what you've already typed in so you won't have to do it again.
Please see below the most popular frequently asked questions.
Loading article...
Loading faqs...
Please see below the current ongoing issues which are under investigation.
Loading issue...
Loading ongoing issues...
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.
Solved! Go to Solution.
We believe we found the issue and deployed a fix. Is the resume point being returned correctly for you now?
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:
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.
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!
Hey there you, Yeah, you! 😁 Welcome - we're glad you joined the Spotify Community! While you here, let's have a fun game and get…