<div dir="auto"><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Hi GStreamer Developers,</div><div dir="auto"><br></div><div dir="auto">We are working with an application (Enigma2 STB software) that implements live DVB timeshifting, buffering the incoming Transport Stream to disk (or potentially RAM) and allowing delayed playback.</div><div dir="auto"><br></div><div dir="auto">We face a recurring challenge: when the live DVB source is temporarily interrupted (e.g., signal loss) and then resumes, playing back from the timeshift buffer *at a fixed delay* becomes unstable.</div><div dir="auto"><br></div><div dir="auto">**Scenario:**</div><div dir="auto">1. Live DVB stream is being buffered.</div><div dir="auto">2. User is watching with a fixed delay (e.g., 30 seconds behind live) by reading from the buffer. Playback is smooth.</div><div dir="auto">3. The DVB signal input is temporarily lost (e.g., 5 seconds). Buffering stops receiving data. Playback likely pauses or freezes.</div><div dir="auto">4. The DVB signal returns. Buffering resumes, writing new data with current PTS timestamps. A significant PTS gap now exists in the buffer.</div><div dir="auto">5. The application calculates the correct target playback position: `[current_buffer_end_pts] - [desired_delay]` or equivalent seek target based on byte position/time.</div><div dir="auto">6. The application issues a `seek()` operation to this target position.</div><div dir="auto"><br></div><div dir="auto">**The Problem:**</div><div dir="auto">Often, despite the application issuing a precise `seek()` command to the correct delayed position after the signal returns, the GStreamer pipeline seems to perform an aggressive resynchronization. Instead of resuming smoothly at the target seek point (which might be just before the large PTS gap), the playback often "jumps" much further forward, closer to the live point (end of the buffer), effectively losing the user's desired timeshift delay.</div><div dir="auto"><br></div><div dir="auto">**Our Understanding:**</div><div dir="auto">We believe this jump is GStreamer's default behavior when encountering a large PTS discontinuity during seek/playback in what is essentially a growing file/buffer scenario, prioritizing regaining sync with the newest data over strictly honoring the seek target near the discontinuity.</div><div dir="auto"><br></div><div dir="auto">**Seeking Guidance:**</div><div dir="auto">Are there recommended GStreamer pipeline configurations, specific elements (queues with certain properties, identity, custom buffers?), flags, or best practices for handling this specific scenario?</div><div dir="auto"><br></div><div dir="auto">Specifically, how can an application using GStreamer best achieve **stable, delayed playback from a live-buffered stream that is prone to source interruptions and resulting PTS discontinuities**, prioritizing the *maintenance of the delay offset* over immediate resynchronization to the live edge after an interruption?</div><div dir="auto"><br></div><div dir="auto">Is there a way to configure the pipeline or specific elements (like decoders, sinks, or demuxers) to be more tolerant of these gaps during seeks, or to better handle the resumption logic to respect the application's seek target?</div><div dir="auto"><br></div><div dir="auto">Any pointers, documentation references, or examples would be greatly appreciated. We want to ensure we are using GStreamer correctly for this challenging timeshift use case.</div><div dir="auto"><br></div><div dir="auto">Thank you for your time and the excellent framework.</div><div dir="auto"><br></div><div dir="auto">Best regards,</div><div dir="auto">[Mohamed, e.g., Enigma2 Community Member]</div></div>