Description:
Hello Enigma2 Development Community,
This post addresses a common and persistent issue with the timeshift functionality observed across a wide range of Enigma2-based set-top boxes when using a softcam for descrambling encrypted channels.
The Problem:
When a user is watching a scrambled channel with timeshift active and a specific viewing delay established (e.g., watching 15 seconds behind the live broadcast), if the softcam's descrambling process is temporarily interrupted (due to issues like ECM processing delays, softcam restarts, or brief upstream problems affecting decryption), the timeshift playback position invariably "jumps" forward once descrambling resumes. This jump significantly reduces or entirely negates the user's intended timeshift delay, often forcing playback بسیار close to, or at, the current live point of the broadcast. This behavior is consistently reported and impacts the usability of timeshift for many users.
Expected Behavior:
Ideally, the timeshift system should preserve the user-established viewing delay despite temporary descrambling interruptions. When descrambling capabilities are restored after a brief outage, the timeshift buffer should reflect the period of interruption (e.g., as a segment of black screen or undecryptable video). Subsequently, the clear, descrambled picture should resume, but the playback should continue with the original timeshift delay still intact relative to the ongoing live broadcast. The timeshift progress indicator should not exhibit a sudden forward leap that discards the accumulated delay.
Steps to Reproduce (General Scenario):
- Activate timeshift on any scrambled television channel.
- Establish a noticeable viewing delay (e.g., by pausing the live feed for several seconds and then resuming playback from the timeshift buffer).
- Induce or wait for a temporary interruption in the softcam's descrambling process (this can be simulated by restarting the softcam, or it may occur naturally due to network/server latency if using cardsharing).
- Allow the softcam and descrambling process to recover, and for the clear picture to return.
- Observe that the timeshift playback position has advanced sharply, and the previously established viewing delay relative to the live broadcast has been substantially diminished or eliminated.
Additional Context and Suggestion:
This behavior significantly undermines the utility of the timeshift feature on encrypted channels, as transient descrambling issues can nullify the core benefit of the delay. The GStreamer framework, commonly used for playback, typically expects a well-formed input stream. The root of this issue appears to be how the Enigma2's DVB source handling and timeshift recording mechanism manage "data underflow" or "timeline discontinuities" that arise from the softcam when it cannot provide a continuous stream of descrambled data.
It is worth noting that some other (non-Enigma2) set-top box platforms incorporate features (sometimes marketed as "Video Delay" or similar) that successfully mitigate this problem. These systems appear to maintain the user's viewing offset by "padding" the timeshift buffer with placeholder data during decryption gaps, thereby preserving a more consistent timeline for the player.
We appeal to the Enigma2 development community to investigate potential enhancements to the timeshift recording and playback logic to better handle these common scenarios. One conceptual approach could involve the timeshift recorder inserting null TS packets (or a similar inert padding mechanism) into the timeshift file during periods of descrambling unavailability. The goal would be to maintain a temporally consistent data stream for the player, thus preventing the large jumps that currently occur, even if it means a period of unwatchable (padded) content within the buffer.
Addressing this issue would greatly improve the timeshift experience for a significant portion of the Enigma2 user base. Thank you for your consideration.
