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.
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!