FAQ: Pocket Casts on my iPhone or Android device shows duplicate episodes of Phones Show Chat (or similar)

This seems to be an issue that keeps cropping up and I wanted to get some thoughts down somewhere as to what's going on.

For starters, there's nothing wrong with the RSS file for each podcast - this is the plain text file that tells podcatchers which episodes are available and where to grab them from. There's nothing to go wrong here, other than the occasional typo, which I'd typically pick up very quickly.

Every other podcatcher on every platform (I've tried over a dozen on Android, iOS, Windows Phone and Blackberry) reads this RSS file fine and podcasts appear as they should.

But then there's Pocket Casts, probably the most popular third party podcatcher in the phone world. This goes one step further than the podcatcher itself grabbing the RSS (or XML) file for each of your favourite podcasts. Instead, it grabs them all onto a custom server, the idea being that each client round the world doesn't have to grab the same old RSS files time and time again - it simply has to sync with the Pocket Casts server and the latter will tell it what's new.

Unfortunately, all of this depends on the logic built into the server code by Shifty Jelly, Pocket Casts' developer. And when the logic doesn't allow for typical Internet 'glitches' then things can go haywire.


What seems to be happening is that after I publish my new RSS file, with a new podcast episode mentioned in it, to my web server, the Pocket Casts server grabs it immediately and all is usually well. But the server isn't just grabbing the file once, it's hammering podcast URLs around the world (I'm guessing once every minute) through the day. So, for a big web host (I use Names) with many servers and levels of caching, it's possible that in the first few minutes or so after a major file change, the 'old' file might be available on the right URL, while all the various servers and mirrors sort themselves out.

This shouldn't cause an issue - logic dictates that the file might be older and should be ignored. Or perhaps, acting properly, Pocket Casts' server should receive this temporary copy of the 'old' RSS file and remove the new episode? After all, for all it knows, I might have pulled the episode for editorial reasons!

What actually happens is that the PC server spots the new episode and makes it available for all synced clients. It might sometimes then (in the first few minutes) spot an old copy and resets the RSS file timestamp/baseline in its database to this. A few minutes later, it sees the new/proper RSS file again and says 'Oh, this is new' - again - and parses the newest entry, adding this too to its database. Again.

Rinse and repeat and you can see why some people using Pocket Casts might be seeing multiple 'copies' of a podcast.

This is purely down to how the logic on Pocket Casts' server handles temporary caching glitches from web servers. And I can't believe it's beyond Shifty Jelly's programming skills to get this one right. It's NOT rocket science for a line of code to recognise that the database entry it's trying to add matches the one it added five minutes previously and to then abort the addition.

I'd welcome comment from Shifty Jelly, though all the code on their server is proprietary so fixing this is 100% down to them!

PS. I accept the observation that very few other podcasts are affected by this, but the RSS file is tiny, plain text and unambiguous. It can be read and understood by any podcatcher or browser at any time - and all of them do this perfectly... except the Pocket Casts server. Given that I can't do anything about the massive server farm run by Names, the logical thing is for Shifty Jelly to make its server code more...robust!

PPS. It seems that others have noticed the same issue with other podcasts, all with the Pocket Casts application. See, for example, comment in here. And here. And here. Ultimately, the solution may be to ditch Pocket Casts and use a simpler, more direct podcatching application.

UPDATE: Shifty Jelly has now admitted that the issue is at their end and they have 'rolled out a fix just for Steve'. And - cough - all the other podcasts seeing the issue. Still, at least things work now?

Comments

Popular posts from this blog

Wavelet - and better sounding speakers (and headphones) on Android...

Bluetooth keyboard incorrect PIN or password - SOLVED

How to fix Blink XT2 Camera 'Thumbnail failed' error!