@ByteHamster and I discussed this again.
We think it’s got to do with the caching in combination with advertising being added or disappearing between plays.
For example: I play and cache one version with ads, pause, then play again and cache a version without ads. At that point your existing timestamp is ‘later’ in the actual podcast.
There’s 2 components at play here: OkHttp (it fetch the file using the protocol) & Media player (which orchastrates the buffering & caching).
OkHttp was updated to a newer version when we had the issue with podcast hanging at 17 minutes. Maybe this introduced a change that causes servers not to recognise any-more that we’re requesting more of the same file.
Or, maybe the servers of some hosts changed something in the way cache/serve files.
Now we give the media player the following instructions for buffering:
- minimum buffer of 1 hour
- maximum buffer of 3 hours
- backbuffer (keep in cache the audio that’s already played): 5 minutes
We’re hoping that by buffering/caching (more or less) whole episodes, the suspected differences in received files gets eliminated. This will be included in 3.5.0-beta3.