![]() If they insert an ad at the start of the podcast on release day, but not the days that follow (this podcast episode has been out for 10 days at this Since the report seems to have been made on June 6 (or was that just when we got back to them?) I wonder if we can make any assumptions about when they actually listened to the podcast, and if they started it on release day (Friday, June 3) but didn't finish it and then continued on Monday June 6? If we could follow up with them, would they remember those details? Depending on how much time has passed between the initial pause and resume (it is a day or more?) it could have something to do with the podcast inserting different ads on release day vs after release day. Why it is so far behind isn't exactly clear, but this theory about dynamic ad insertion might be a good explanation. So I might argue that the audio isn't skipping ahead so much as it has "caught up" to where it should be. This seems to match what they reported in "video 2" The audio and intro music that is playing at the start of that video clip at 1:20 actually starts around 49 seconds for me. The timestamp at the point where it seems to "skip ahead" actually matches the audio that plays on my device at that timestamp (1:28). I haven't been able to reproduce this myself "in the wild" listening to podcasts, but I looked at #44 (comment) and watched "video 1" while comparing it to the podcast audio currently on my device. So when I reached the end of playable audio, the player paused (and wouldn't play again), but it didn't advance to the next episode because the player thought I still had 19s of the episode remaining. My guess is, the duration was cached when I first started playing, then later on new dynamic ads were inserted and the episode was 19 seconds shorter. The audio for the episode sounded like it was supposed to have ended. I also think this bug bit me in a different way recently - The episode stopped with 0:19 left on the clock, and would not play on to completion. I'm trying to find a good instance that I can capture more logs for, but since it comes up sporadically it's hard to pin down. ![]() It takes a while for the playback to catch up and the bug to hit (like 5-10m). This podcast does have dynamic ads, and as suspected it happens most often when playing after a long paused period. I've turned off Auto Downloads so that I'm always streaming episodes, and I've hit this bug myself several times, often on the Decoder Ring podcast. Since this happens on so many podcasts, and users don't experience this in other apps, it seems unlikely to me that this is an issue with the hosts, and more like something we should be able to fix on our end. So once the users gets to that part in the audio, there's a jump (either forward or back). I don't know how that framework buffers/streams content, but my best guess would be that at some point when the app requests content beyond the current buffer, the host starts serving audio with different dynamic content. My understanding is that because we're streaming, that means we're using the AVPlayer. Users who download, or try on other apps, do not experience this issue. ![]() I also see users pausing for a while and then resuming the episode. ![]() Through some spot-checking, it appears that all of these issues happen with podcasts that use dynamic ad insertion, and the user either has auto-downloads disabled or is away from wifi so the episode is streaming. Complaints of this seem to go back over a year so not likely a recent regression.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |