Ich habe dann auch mal ein wenig gebastelt. Getestet bisher auf einer Dreambox One, lief bei mir bisher stabil. Allerdings gibt es bestimmt noch genug Grenzfälle, die bei mir nicht aufgetaucht sind.
EDIT: das basiert auf v4 von
@BugSpencer
1. Stabilisierung des Delaybuffer-Threadings
Der Delaybuffer wurde gegen Race-Conditions abgesichert. Lesen, Schreiben und Vergrößern des Delaybuffers werden jetzt per Lock geschützt, damit Writer-Thread und Stream-Thread nicht gleichzeitig inkonsistente Buffer-Zustände erzeugen können. Außerdem werden Datenblöcke für den Writer zuerst aus dem Buffer herauskopiert, bevor auf Keys gewartet, entschlüsselt oder gesendet wird. Dadurch bleibt der interne Buffer-Zustand stabil, auch wenn das Warten auf einen CW länger dauert. Die CW-/Key-Daten selbst sind nun ebenfalls pro Key geschützt. Updates durch neue CWs und gleichzeitiges Entschlüsseln können sich dadurch nicht mehr gegenseitig stören. Zusätzlich wurden Statuswerte wie Writer-Status, Client-Status und Response-Time auf atomare Zugriffe umgestellt. Das macht die Kommunikation zwischen den beteiligten Threads sauberer. Behoben wurden außerdem mögliche Probleme bei Delay-Zeitberechnungen und beim Logging von Buffer-Größen. Auch das Vergrößern des Buffers wurde angepasst, damit vorhandene Daten kompakt verschoben werden können, ohne den Lesezustand falsch zu verändern.
2. Delaybuffer startet erst nach gültigem CW
Der Delaybuffer wird jetzt nicht mehr sofort gestartet, sobald PAT/PMT und CAID bekannt sind. Stattdessen wartet streamrelay zuerst auf einen echten, gültigen CW. Wichtig dabei: CWs, die komplett aus Nullen bestehen, werden ignoriert. Solche CWs entstehen z.B. bei „not found“-ECMs und dürfen den Delaybuffer nicht aktivieren. Das behebt den Fall, dass z.B. zuerst CAID 098C probiert wird, aber keinen Key liefert. Früher konnte der Delaybuffer trotzdem schon starten. Wenn danach erst CAID 098D einen gültigen CW liefert, war der Buffer bereits in einem schlechten Zustand. Jetzt startet der Buffer erst, wenn der tatsächlich nutzbare CW angekommen ist.
3. CAID-/ECM-PID-Tracking
Ein gültiger CW wird jetzt an die aktive CAID und ECM-PID gebunden. Dadurch wird verhindert, dass ein fehlgeschlagener ECM-Versuch oder ein CW von einer anderen ECM-PID den Streamrelay-Zustand falsch beeinflusst. Wenn dvbapi also von 098C auf 098D umschaltet, zählt erst der gültige CW von 098D als aktiver Startpunkt für den Delaybuffer.
4. Kein unnötiges Vorpuffern bei ECM-Fehlern
Vor dem ersten gültigen CW werden keine verschlüsselten TS-Daten mehr in den Delaybuffer geschrieben. Dadurch kann der Delaybuffer bei wiederholten ECM-Fehlern nicht mehr bis zur Maximalgröße anwachsen, obwohl noch gar kein nutzbarer Key vorhanden ist. Das verhindert insbesondere Startprobleme, bei denen der Buffer durch „no key“-Situationen unnötig groß wird.
5. Begrenztes Warten, wenn gar kein gültiger CW kommt
Wenn ein Sender bzw. Service überhaupt keinen gültigen, nicht-null CW liefert, bleibt streamrelay jetzt nicht mehr endlos im Startzustand hängen. Stattdessen wird gemessen, wie lange der Client bereits auf den ersten gültigen CW wartet. Wird innerhalb von
stream_relay_delay_time_max kein gültiger CW gefunden, wird der Streamrelay-Client getrennt. Dadurch kann DVBAPI sauber aus dem Versuch herauskommen, statt dauerhaft die ECM-PIDs durchzuprobieren, bis OSCam neu gestartet wird.
6. Besseres Verhalten bei Key-Ausfällen im laufenden Stream
Wenn während eines laufenden Streams ein Key fehlt oder alt wird, wird die Verzögerung nicht mehr dauerhaft bis zum Maximum erhöht. Stattdessen wird diese Situation als begrenzter Resync-/Drop-Fall behandelt. Das heißt: streamrelay wartet nur begrenzt auf den passenden Key. Wenn er nicht rechtzeitig kommt, werden Daten verworfen bzw. vorwärts gesprungen, bis der Stream wieder zu einem vorhandenen Key passt.
7. Neue konfigurierbare Resync-Grace-Zeit
Es wurde eine neue Option
stream_relay_resync_grace hinzugefügt. Damit lässt sich konfigurieren, wie lange streamrelay bei einem laufenden Stream auf einen fehlenden/passenden Key wartet, bevor es resynchronisiert bzw. Daten verwirft.
### Kompakt Englisch
Harden streamrelay delay buffer threading
- protect delay buffer reads/writes and growth with locking
- copy writer blocks out before key waits, descramble, and send
- add per-key locking around CW updates and decrypt
- use atomics for writer status, client status, and response time
- fix delay time overflow and size_t logging issues
- make buffer growth compact records without mutating read state
- add comments for reconnect packet-size assumptions and TS max size
streamrelay: gate delay buffer on valid CW
Start the delay-buffer writer only after a non-zero CW is active for the selected CAID/ECM PID, and ignore failed/zero CWs during CAID fallback.
Avoid buffering encrypted TS data before the first usable CW arrives, so startup with repeated ECM failures cannot grow the delay buffer to max. Handle mid-stream key outages as bounded resync/drop events instead of permanently increasing stream delay.
Add human-readable delay-buffer size logging and a configurable stream_relay_resync_grace option with WebIF support.
streamrelay: stop startup wait when no valid CW arrives
Do not leave streamrelay clients waiting forever when a service never produces a valid non-zero CW. Track how long the client has been waiting for the first active CW and disconnect it after stream_relay_delay_time_max.
This keeps the delay buffer from starting on invalid CWs while also letting DVBAPI unwind instead of retrying ECM PIDs indefinitely.
