Thank you for reopening the bug report.
The "fix" used by Flole essentially resulted in the following behavior: During a DTS wraparound, the DTS value is hard reset to 0. This is exactly what was tested, and this is precisely what the fix does 100%.
However, as I already described, this did not resolve the underlying problem; in fact, it worsened the situation. While the timeshift buffer still gets corrupted during the wraparound, the stream itself now crashes severely, leading to significant video artifacts, audio dropouts and synchronization issues that did not occur before the patch.
Before this patch, the timeshift buffer was also corrupted, so fast-forwarding, rewinding, and pausing only worked after reconnecting the stream. After the wraparound, however, the stream recovered quickly through an automatic reconnect and continued without A/V errors. The new behavior of hard-setting the DTS value to 0 causes the stream to become unusable and remain corrupted from that point onward.
I tested this on two different channels/frequencies, and in both cases, the stream did not recover after hard-setting DTS to 0. The timeshift buffer remained corrupted, and video artifacts, audio dropouts and synchronization issues occurred until the stream was stopped and restarted.
I also don't think it has anything to do with the difference between DVB-T and DVB-S because resetting the DTS value to 0 during a wraparound breaks the continuous timeline expected by MPEG-TS decoders. All downstream components—including the decoder, A/V synchronizer, and timeshift buffer—rely on monotonically increasing timestamps. A sudden jump from a high DTS to 0 creates a massive negative offset, which the decoder cannot reconcile, leading to video artifacts, audio dropouts and desynchronization. This behavior is independent of DVB-S, DVB-T, or any other transport medium, because all MPEG-TS streams use the same 33-bit PTS/DTS clock. It seems proper handling, as implemented in FFmpeg, GStreamer, and VLC, uses modular arithmetic and epoch adjustment instead of hard resets to maintain a continuous timeline.
Even GitHub Copilot, on which Flole's "fix" was based, pointed out that forcing DTS to zero does not completely resolve the issue and can cause further problems.
The alternative solution I proposed, was developed and cross-checked against each other using three different AI systems and was neither considered nor tested.
I'm aware that local compilation and testing is a possible approach, but as a non-developer, I've already invested considerable time and effort in describing/reproducing the bug, collecting logs, identifying the root cause, and proposing a technically sound solution. While I didn't do all this alone, but rather with the help of various AIs, as I mentioned, I'm not a developer. Most users don't go this far with their bug reports and it cannot be a solution that leaves the bugfix to users.
At this point, I'm genuinely unsure what constructive contribution I can still make. If no developers currently have the time or interest to properly fix this bug, it would be helpful to communicate this clearly.
Applying a workaround that, according to testing tools, is incomplete, just to close the bug, doesn't resolve the underlying problem.
I deliberately chose to hold back my previously mentioned autistic form of openness in order to prevent an escalation.
Thanks for the time and the tests conducted.
