(lame nerd shit, continue scrolling)
Did some debugging on the VOD backup script I mentioned a few threads ago and, sure enough, a faulty assumption was the culprit.
By looking at a corrupted file, I found the following two discontinuities:
As you can see, there's two sections where 15 segments get repeated. Checking the logs, I see that I was served a series of six playlists ending in the following segments:
>1170, 1155, 1185, 1200, 1185, 1215
This lines up perfectly with the discontinuity I found.
I mentioned last time that I used the header to check whether I should download the playlist, and if there were "no new segments" added, I would do nothing. However, this assumed a monotonically increasing segment count from the server, since after performing the check it always saved the new segment count as the count to compare against for the next loop without checking whether it was actually larger. The result above shows this was a flawed assumption. Thus, this occurred:
>Get playlist 1 (download new segments through 1170, set count to 1171)
>Get playlist 2 (don't download any segments, set count to 1156)
>Get playlist 3 (re-download segments 1156-1170 + new segments 1171-1185, set count to 1186)
>Get playlist 4 (download new segments 1186-1200, set count to 1201)
>Get playlist 5 (don't download any segments, set count to 1186)
>Get playlist 6 (re-download segments 1186-1200 + new segments 1201-1215, set count to 1215)
This is all fixed by adding a single conditional so that the segment count is only updated when it is actually larger. As for why the server is doing this, I probably should have saved all the header data to see if I could find a pattern, but I'm going to chalk it up to weird caching shit and call it a day.
Definitely a good exercise in debugging and a reminder to carefully consider your assumptions, especially when interfacing with something you don't control.