[Patch] StreamRelay Delay Buffer OSCam

[tem_invictus]

StreamRelay Delay Buffer für OSCam – Konfiguration und Anleitung

Mit dem Patch streamrelay-delaybuffer_vxx.p1-xxx-tem_invictus.patch erhält StreamRelay einen optionalen, zeitgesteuerten Delay Buffer. Der bisherige direkte Verarbeitungsweg bleibt erhalten und ist weiterhin der Standard.

Der neue Verarbeitungsweg puffert die empfangenen TS-Daten pro Stream-Verbindung, wartet auf ein gültiges Control Word (CW), entschlüsselt die Daten in einem eigenen Writer Thread und sendet sie anschließend an den Client. Damit können verspätete oder kurzzeitig fehlende CWs besser abgefangen werden, ohne dass sich die Stream-Verzögerung bei jedem Problem dauerhaft vergrößert.

Danksagung: Dieser Patch basiert auf der von @BugSpencer vorgestellten Idee zum zeitverzögerten StreamRelay: Oscam StreamRelay Delay Mod

Basis und Voraussetzung

• Der Patch ist für den Quellstand OSCam r11965 erstellt.
• OSCam muss mit aktiviertem MODULE_STREAMRELAY neu kompiliert werden.
• Nach dem Austausch der Binary sollte OSCam neu gestartet werden.

Was der Patch ändert

• Ein neuer, dynamisch wachsender Ring Buffer hält TS-Daten für die konfigurierte Zeit zurück.
• Die Entschlüsselung und Ausgabe erfolgen im erweiterten Modus über einen separaten Writer Thread.
• Vor dem Start des Bufferings wird auf ein gültiges, nicht leeres CW für die aktive CAID und den aktiven ECM PID gewartet.
• Fehlgeschlagene ECM-Anfragen und Zero CWs können den Delay Buffer nicht starten oder auf eine falsche CAID/einen falschen ECM PID umschalten.
• Bei einem CW-Ausfall während des Streams wird nur für eine begrenzte Zeit gewartet. Danach werden nicht sicher entschlüsselbare Blöcke verworfen, bis ein passendes CW vorhanden ist.
• Die TS scrambling bits werden nur nach erfolgreicher Entschlüsselung entfernt.
• Der Buffer startet abhängig von stream_relay_delay_time mit ungefähr 2 MB + 2 MB je voller Sekunde Delay, wächst in 2 MB-Schritten und ist auf 20 MB pro Verbindung begrenzt.
• Automatische Backpressure pausiert das Lesen von der Stream-Quelle ab 75 % Buffer-Belegung und setzt es bei 50 % oder weniger wieder fort. Das hilft besonders auf schwächeren Geräten.
• Fehler beim Initialisieren, Schreiben, Starten des Writer Threads oder Senden führen zu einer sauberen Trennung der betroffenen Verbindung.
• Für Client-Sends gilt ein Timeout von fünf Sekunden; auch unvollständige Sends werden als Fehler behandelt.
• Beim Wechsel der Stream-Quelle werden Buffer-, Writer-, TS-, PAT/PMT/PID- und CW-Zustände vollständig zurückgesetzt.
• Locks und atomare Statuswerte schützen CWs, Verbindungen und Statistiken vor Race Conditions.

Wichtig: Der erweiterte Pfad ist standardmäßig ausgeschaltet. Ohne eine bewusste Aktivierung verhält sich StreamRelay weitgehend wie zuvor.

Konfiguration

Die Optionen befinden sich in oscam.conf im Abschnitt streamrelay. Im WebIf sind sie unter Configuration -> StreamRelay in den Bereichen Relay Timing Settings und Relay Runtime Settings zu finden.

stream_relay_delay_buffer

Schaltet den neuen Verarbeitungsweg ein oder aus.

• 0 = legacy/direct path, Standard
• 1 = extended delay-buffer path

Bei 0 wird wie bisher direkt entschlüsselt und gesendet. Bei 1 werden Writer Thread, CW startup gating, Resync und Backpressure verwendet.

stream_relay_delay_time

Bestimmt in Millisekunden, wie lange TS-Daten im erweiterten Delay Buffer verbleiben, bevor sie entschlüsselt und ausgegeben werden.

• Standard: 0
• Gültiger Bereich: 0-9999 ms
• Größere Werte geben dem CW mehr Zeit, erhöhen aber Umschaltzeit, Stream-Latenz und Speicherbedarf.
• Werte über 9999 werden automatisch auf 9999 begrenzt.
• Eine Änderung wird von einem laufenden Writer Thread übernommen; für reproduzierbare Tests empfiehlt sich trotzdem ein neuer Stream-Verbindungsaufbau.

stream_relay_cw_timeout

Maximale Wartezeit in Millisekunden auf ein verwendbares CW.

• Standard: 5000 ms
• Beim Start wird die Verbindung getrennt, wenn innerhalb dieses Zeitraums kein gültiges CW für den aktiven Stream verfügbar ist.
• Der Wert begrenzt außerdem die CW-Wartezeit des Writer Threads beim Start.
• 0 bedeutet keine Wartezeit und führt beim Start ohne bereits vorhandenes CW zur sofortigen Trennung. Für den normalen Betrieb ist daher ein Wert größer als 0 sinnvoll.

stream_relay_resync_grace

Wartezeit in Millisekunden bei einem CW-Ausfall oder veralteten CW während eines bereits laufenden Streams.

• Standard: 1000 ms
• 0 = immediate resync; der betroffene Block wird ohne zusätzliche Wartezeit verworfen.
• Nach Ablauf der Wartezeit werden nicht entschlüsselbare Blöcke verworfen, bis das passende CW wieder vorhanden ist.
• Der Wert darf stream_relay_cw_timeout nicht überschreiten. Ein höherer Wert wird beim Einlesen der Konfiguration automatisch entsprechend reduziert.

stream_relay_buffer_time

Dies ist die bereits vorhandene, einmalige Startverzögerung vor der Stream-Verarbeitung. Sie ist kein Ersatz für den neuen zeitgesteuerten Delay Buffer.

• Standard: 0 ms
• Funktioniert sowohl mit stream_relay_delay_buffer = 0 als auch mit stream_relay_delay_buffer = 1.
• Im WebIf können wieder bis zu fünf Stellen eingegeben werden.
• Der Wert bleibt unabhängig einstellbar und wird auch bei aktiviertem Extended Delay Buffer berücksichtigt.

stream_relay_log

Aktiviert zusätzliche ODD/EVEN-, CW-Timing- und Buffer-Statistiken im OSCam-Log.

• 0 = zusätzliche Dauerprotokollierung aus, Standard
• 1 = zusätzliche Protokollierung ein

Für die Einrichtung und Fehlersuche ist 1 hilfreich. Im Dauerbetrieb kann die Option wieder auf 0 gesetzt werden. Wichtige Zustands- und Fehlermeldungen werden unabhängig davon protokolliert.

stream_tcp_waitall

Steuert im erweiterten Modus, wie Daten von der Stream-Quelle gesammelt werden.

• 1 = MSG_WAITALL verwenden und größere Blöcke abwarten, Standard
• 0 = kleinere Datenmengen nach einem kurzen Poll verarbeiten; geringere Latenz, aber potentiell höhere CPU-Last

Auf schwächeren Geräten ist 1 der sinnvollere Ausgangspunkt. 0 eignet sich zum Testen auf ausreichend leistungsfähiger Hardware, wenn möglichst geringe zusätzliche Latenz wichtiger ist.

Empfohlene Startkonfiguration

Diese Werte sind ein konservativer Ausgangspunkt. Die optimale Delay-Zeit hängt von Reader, Netzwerk, Sender und den tatsächlichen ECM-Zeiten ab.

[streamrelay]
stream_relay_enabled = 1
stream_relay_delay_buffer = 1
stream_relay_buffer_time = 0
stream_relay_delay_time = 500
stream_relay_cw_timeout = 5000
stream_relay_resync_grace = 1000
stream_relay_log = 1
stream_tcp_waitall = 1

Nach dem Speichern sollten die Stream-Clients neu verbunden werden. Ein OSCam-Neustart ist die sicherste Methode, damit alle Verbindungen garantiert mit dem neuen Modus und einem leeren Zustand beginnen.

Abstimmung der Werte

1. Mit stream_relay_delay_time = 500, stream_relay_cw_timeout = 5000 und stream_relay_resync_grace = 1000 beginnen.
2. stream_relay_log = 1 während der Tests aktivieren.
3. Treten Meldungen wie KeyOld, no Key oder wiederholte resync drop-Ereignisse auf, zuerst Reader- und ECM-Probleme prüfen. Bei normaler Reader-Funktion kann stream_relay_delay_time in Schritten von etwa 250-500 ms erhöht werden.
4. Bei kurzen CW-Lücken kann stream_relay_resync_grace vorsichtig erhöht werden, jedoch nie über stream_relay_cw_timeout.
5. Läuft der Stream stabil, kann stream_relay_delay_time schrittweise reduziert werden, bis ein guter Kompromiss aus Stabilität und Umschaltzeit erreicht ist.
6. Erst danach bei Bedarf stream_tcp_waitall = 0 testen und dabei CPU-Last sowie Stabilität beobachten.
7. Nach Abschluss der Tests stream_relay_log = 0 setzen, sofern die zusätzlichen Statistiken nicht dauerhaft benötigt werden.

Legacy-Betrieb

Wer das bisherige Verhalten beibehalten möchte, verwendet:

[streamrelay]
stream_relay_delay_buffer = 0
stream_relay_buffer_time = 0

In diesem Modus sind stream_relay_delay_time, stream_relay_cw_timeout und stream_relay_resync_grace für den erweiterten Writer-Pfad nicht aktiv.

Hinweis für Updates von älteren Patch-Versionen

In v08 wurden zwei Optionsnamen geändert:

stream_relay_delay_time_min -> stream_relay_delay_time
stream_relay_delay_time_max -> stream_relay_cw_timeout

Für die alten Namen gibt es keine Compatibility Aliases. Vor dem Start mit v08 müssen vorhandene Einträge in oscam.conf deshalb auf die neuen Namen geändert werden.

 

[BugSpencer]

Warum wird denn die Kopie vom Patch direkt als wichtig angeheftet?

 

[Robert51]

Worin liegt der Unterschied zwischen p0 und p1 ?

 

[Azo]

Hi,
gibt es denn keine Chance, dass ihr @tem_invictus und @BugSpencer zusammen an dem "Projekt" arbeitet?
Das Ziel ist doch das gleiche, oder verstehe ich da was falsch?

Tschau
Azo

 

[mestorf]

Ich zitiere mal die KI soll jeder selber entscheiden v8 = tem_invictus v9 = @BugSpencer -> Klare Empfehlung: Nutze v0.9 (StreamRelayDelayModv9) ka was das wieder soll aber wenn v8 schon angepinnt hat es @BugSpencer erst recht verdient. Oscam StreamRelay Delay Mod

Der Detailvergleich im Code​

1. Puffer-Logik und Initialisierung​

• v0.8 (p0/p1): Erstellt einen festen Ringpuffer, der Daten sammelt, bis eine definierte Schwelle (Delay) erreicht ist. Wenn der Puffer vollläuft oder der Stream anfängt zu laggen, neigt die v0.8-Logik dazu, den Puffer hart zu droppen. Das führt in der Praxis zu kurzen Bildaussetzern oder Hängern, wenn die Datenrate schwankt.
• v0.9 (StreamRelayDelayModv9): Baut eine dynamischere Abfrage um den Lese- und Schreibzeiger des Buffers. Die Freigabe der Daten an den Client erfolgt geschmeidiger, weil das Reset-Verhalten bei Datenabriss angepasst wurde.

2. Thread-Sicherheit und Fehlerbehandlung​

• v0.8: Besitzt rudimentäre Mutex-/Lock-Mechanismen. Wenn der Stream abreißt (z. B. beim Umschalten oder bei Kaskaden-Entschlüsselung), kann es vorkommen, dass Lesezugriffe auf noch nicht geschriebene Pufferbereiche erfolgen.
• v0.9: Bietet zusätzliche Absicherungen vor Schreib-/Lesezugriffen außerhalb des gültigen Speicherbereichs. Das reduziert die Gefahr von sporadischen Abstürzen (Segmentation Faults) des Binaries beim schnellen Zappen deutlich.

3. Kompatibilität​

• v0.8: Ist auf ältere Stande der StreamRelay-Integration zugeschnitten.
• v0.9: Wurde an neuere Quellcode-Stände angepasst, bei denen das Handling der Socket-Verbindungen leicht überarbeitet wurde.

Welche Version ist zu empfehlen?​

Klare Empfehlung: Nutze v0.9 (StreamRelayDelayModv9).

Warum v0.9?​

1. Höhere Stabilität beim Zappen: Die zusätzlichen Schutzmechanismen gegen Speicherzugriffsfehler machen v0.9 im Alltagsbetrieb spürbar robuster.
2. Besseres Umschaltverhalten: Das geänderte Buffer-Handling verhindert ein unnötiges Leerlaufen des Puffers bei leichten Schwankungen der Bitrate, was zu einem flüssigeren Bild führt.

Einziger Grund für v0.8:​

Die v0.8 solltest du nur dann wählen, wenn du eine sehr alte Codebasis kompilierst, auf der der v0.9-Patch aufgrund von Code-Abweichungen (Hunk failed) gar nicht erst durchläuft. Wenn v0.9 sauber durchkompiliert, gibt es keinen technischen Grund, auf der älteren v0.8 zu bleiben.

 

[tem_invictus]

Warum meine Version angepinnt ist, kann ich nicht sagen. Kann ja nur ein Mod gemacht haben.

Ich möchte hier auch nicht anfangen welcher Patch ist besser, dies das. Wir verfolgen in einigen Bereichen einfach andere Ansätze. Allerdings sind die Behauptungen von @mestorf , bzw. dessen KI einfach falsch. Nicht alles was die KI plappert stimmt, vor allem nicht, wenn man nur beide Patches gegeneinander vergleichen lässt und die KI keinen Zugriff auf den gesamten Code hat.

1. Pufferlogik
   v08 nutzt keinen festen Puffer, sondern einen Ringpuffer, der dynamisch bis 20 MB wächst. Bei hohem Füllstand wird der Datenempfang gebremst; der Puffer wird nicht pauschal „hart gedroppt“. v9 ignoriert dagegen teilweise fehlgeschlagene Schreibvorgänge, wodurch Daten unbemerkt verloren gehen können. v9 bietet zwar ein adaptives Delay, aber kein nachweislich besseres Reset-Verhalten.
   
   
2. Thread-Sicherheit
   Auch hier ist die Aussage eher umgekehrt: v08 verwendet Buffer-Mutex, getrennte CW-Locks, Atomics und zusätzliche Bereichsprüfungen. v9 entfernt mehrere Prüfungen und enthält sogar einen doppelten Mutex-Unlock sowie ungeschützte gemeinsam genutzte Variablen. Eine höhere Segfault-Sicherheit von v9 lässt sich daraus nicht ableiten.
   
   
3. Kompatibilität
   Beide Patches basieren auf OSCam 11965 und lassen sich dort mit StreamRelay kompilieren. v9 ist nicht für eine neuere Socket-Codebasis erstellt worden – die Versionsnummern stammen lediglich von unterschiedlichen Autoren.

Hier gibt es noch mal die episch lange Ausführung:

Spoiler: Zusammenfassung Lang

### 1. Puffer-Logik und Initialisierung

> v08 erstellt einen festen Ringpuffer und droppt ihn bei Überlauf hart.

Das ist falsch.

- v08 verwendet zwar einen Ringpuffer, dieser wächst aber dynamisch in 2-MiB-Schritten bis zur Obergrenze. Zusätzlich kann er am Ringende kompaktiert werden.
- Bei hohem Füllstand bremst v08 den Producer zwischen 75 % und 50 % Auslastung, anstatt den Puffer einfach zu verwerfen.
- Ein fehlgeschlagener Schreibvorgang wird erkannt und führt kontrolliert zum Abbruch der Verbindung. v9 ignoriert dagegen die Rückgabewerte von `streamrelaybuf_write()`; betroffene Datenblöcke können dadurch still verloren gehen.
- v08 verwirft bei fehlendem oder veraltetem CW gezielt den aktuellen Datenblock. Das ist ein Resync-Mechanismus und kein „Drop des ganzen Puffers wegen schwankender Bitrate“.

> v9 besitzt eine dynamischere Zeigerlogik und ein besseres Reset-Verhalten.

Nur der erste Teil ist eingeschränkt richtig: v9 hat eine adaptive Verzögerung zwischen `min` und `max`. Diese reagiert allerdings auf fehlende/veraltete CWs, nicht auf Bitratenschwankungen.

Das Reset-Verhalten ist nicht besser:

- v08 stoppt bei einem Source-Reconnect den Writer, leert/freed den alten Puffer und setzt CW-, PID- und Parserzustände zurück.
- v9 besitzt diesen vollständigen Reconnect-Reset nicht.
- Eine von v9 erhöhte Verzögerung wird nach Wiederkehr eines gültigen Keys nicht zuverlässig auf den Mindestwert zurückgesetzt.

**Antwort:** Die Behauptung eines geschmeidigeren v9-Puffers ist nicht belegt. v9 hat eine interessante adaptive Delay-Idee, v08 behandelt Überfüllung, Fehler und Reconnects aber kontrollierter.

### 2. Thread-Sicherheit und Fehlerbehandlung

> v08 hat nur rudimentäre Locks und kann aus ungeschriebenen Pufferbereichen lesen.

Das Gegenteil ist der Fall.

v08 verwendet:

- einen Mutex für Pufferzugriffe,
- separate Mutexes für EVEN/ODD-CW-Zustände,
- Atomics für Threadstatus und Zähler,
- einen explizit initialisierten globalen Mutex,
- Prüfungen von `readPosNext`, verfügbarer Länge und Headerlänge vor jedem Lesezugriff.

v9 entfernt mehrere dieser Prüfungen. Dort wird die im Header gespeicherte Länge ohne gleichwertige Kontrolle auf den tatsächlich verfügbaren Pufferbereich übernommen.

Darüber hinaus enthält v9 konkrete problematische Stellen:

- `streamrelaybuf_readFromThreadDone()` entsperrt denselben Mutex zweimal hintereinander – einmal direkt und einmal über `SAFE_MUTEX_UNLOCK`. Das ist undefiniertes Verhalten.
- Mehrere gemeinsam genutzte Felder sind nicht als atomar deklariert, werden aber gleichzeitig aus verschiedenen Threads gelesen und geschrieben.
- `keyOld` wird teilweise ohne denselben Lock gelesen und verändert.
- v9 entfernt das Scrambling-Bit bereits vor der Prüfung, ob überhaupt ein gültiger Key vorhanden ist. Bei übersprungener Entschlüsselung kann dadurch verschlüsselter Payload als unverschlüsselt markiert weitergesendet werden.
- v9 ignoriert Buffer-Schreibfehler.

**Antwort:** Für eine Behauptung, v9 verhindere Segfaults besser, gibt es im Code keine Grundlage. Die statische Analyse zeigt vielmehr zusätzliche Race-, Bounds- und Mutex-Risiken in v9.

### 3. Kompatibilität

> v08 ist für ältere Quellen, v9 für neuere Socket-Implementierungen.

Das ist falsch. Beide Patches basieren auf demselben OSCam-Stand 11965. Ich habe beide separat auf Tag 11965 angewendet und mit aktiviertem `MODULE_STREAMRELAY` erfolgreich kompiliert.

v9 ist also nicht deshalb „moderner“, weil die Datei v9 heißt. Die Versionsnummern stammen von unterschiedlichen Autoren und bilden keine gemeinsame Versionsreihe.

Auch beim Socket-Handling ist v08 nicht älter:

- v08 prüft, ob `send()` tatsächlich die vollständige Länge gesendet hat.
- v9 behandelt auch einen partiellen positiven Rückgabewert wie einen erfolgreichen Versand und sendet den Rest nicht nach.

### Empfehlung

Die pauschale Empfehlung für v9 ist technisch nicht haltbar. Auf Basis des Quellcodes ist v08 die defensivere Variante: stärkere Synchronisation, mehr Bounds-Prüfungen, kontrollierte Buffer-Fehlerbehandlung, Reconnect-Reset und Active-CW-Zuordnung nach Service, CAID und ECM-PID.

v9 enthält zwei interessante Ansätze – adaptives Delay und einen Next-Key-Swap –, müsste vor einer Empfehlung aber hinsichtlich Mutex-Nutzung, Datenrennen, Bounds-Checks, Reconnect-Reset und Fehlerbehandlung überarbeitet werden. Ein erfolgreicher Build allein ist weder bei v08 noch bei v9 ein Stabilitätsnachweis.

 

[Azo]

Hi,
@tem_invictus
Denkst Du bitte beim nächsten Patch dran die Version im Log zu ändern.

Spoiler: Version

cs_log("StreamrelayDelayBuffer teminvictus_v07 Start dvbcsa_bs_batch_size=%i active_caid=%04X active_ecm_pid=%04X key_mask=0x%02X",

Tschau
Azo

 

[Reiner123]

kommt das auch da rein? https://www.digital-eliteboard.com/s3-builder/

 

[DarkStarXxX]

Seh ich das eigentlich richtig, das bei dieser Version der Delay nicht Dynamisch steigen kann, sondern fest auf einen wert gesetzt werden muss?

 

[tem_invictus]

Ja, das ist richtig – wobei man zwischen der Verzögerungszeit und der Speichergröße des Ringpuffers unterscheiden muss.

Bei meiner Version wird mit stream_relay_delay_time ein fester Grund-Delay eingestellt. Automatisch erhöht wird dieser Wert nicht. Lediglich die Speichergröße des Ringpuffers kann bei Bedarf dynamisch wachsen. Der eingestellte Delay kann während des Betriebs manuell geändert werden und wird vom Writer übernommen.

BugSpencers Version verfolgt dagegen einen dynamischen Ansatz: Fehlt beim Entschlüsseln das benötigte CW, wird der Delay schrittweise erhöht, bis das CW eintrifft oder stream_relay_delay_time_max erreicht ist. Der Delay kann also nicht unendlich wachsen, sich aber bis zum konfigurierten Maximum aufbauen und für die laufende Verbindung erhöht bleiben.

Ein Beispiel mit einem Live-Signal:

Angenommen, der Stream läuft normalerweise mit 1000 ms Delay und ein CW trifft zwei Sekunden verspätet ein.

Bei der BugSpencers Version wird während dieser Zeit weiter gepuffert und der Delay erhöht. Sobald das CW eintrifft, kann der gepufferte Inhalt weiter entschlüsselt werden. Das Bild läuft danach aber beispielsweise drei statt einer Sekunde hinter dem Live-Signal. Beim nächsten verspäteten CW kann der Abstand erneut wachsen – bis zum eingestellten Maximum.

Meine Version behält dagegen den Grund-Delay von 1000 ms bei. Fehlt während des laufenden Streams ein CW, wartet sie zusätzlich höchstens für die mit stream_relay_resync_grace konfigurierte Zeit. Kommt das CW rechtzeitig, geht es weiter und der zusätzliche Rückstand wird wieder abgebaut. Kommt es nicht, werden die nicht entschlüsselbaren Blöcke verworfen und der Stream synchronisiert sich neu, sobald wieder ein passendes CW vorhanden ist. Das kann einen kurzen Bildfehler oder Aussetzer verursachen, der Delay erhöht sich dadurch aber nicht dauerhaft.

Trifft von Anfang an überhaupt kein gültiges CW ein, würde BugSpencers Version den Delay bis stream_relay_delay_time_max aufbauen. Danach fehlt das CW jedoch immer noch, sodass auch der größere Puffer keine Entschlüsselung ermöglicht. Meine Version startet den eigentlichen Delay-Buffer dagegen erst nach einem gültigen CW und trennt die Verbindung, wenn innerhalb von stream_relay_cw_timeout keines eintrifft.

Genau dieser Unterschied wird auch im Changelog beschrieben: CW-Ausfälle während des Streams werden als begrenzte Resync-/Drop-Ereignisse behandelt, anstatt den Stream-Delay dauerhaft zu erhöhen. Deshalb wurden bei mir auch die Optionen umbenannt:

stream_relay_delay_time_min -> stream_relay_delay_time
stream_relay_delay_time_max -> stream_relay_cw_timeout

Es handelt sich somit nicht einfach um eine fehlende Funktion, sondern um zwei unterschiedliche Strategien:

• BugSpencers Version versucht bei einem verspäteten CW, die bereits gepufferten Streamdaten zu erhalten. Während des Wartens kann das Livebild stehen bleiben. Trifft das CW ein, wird der Stream mit entsprechend größerem Abstand zum Live-Signal fortgesetzt.
• Meine Version wartet nur eine begrenzte Zeit. Trifft das CW nicht rechtzeitig ein, verwirft sie die nicht entschlüsselbaren Daten und synchronisiert sich neu. Dadurch bleibt der Abstand zum Live-Signal begrenzt, allerdings kann es zu einem kurzen Aussetzer, Bildfehler oder Sprung kommen.

Meiner Meinung nach soll der Buffer gelegentliche, leicht erhöhte ECM-Zeiten abfangen. Wenn die CWs ständig extrem zu spät kommen, liegt vermutlich an anderer Stelle ein Problem vor.


PATCH IM ERSTEN POST AKTUALISIERT, DAMIT DAS LOG AUCH V08 ANZEIGT.

 

[Reiner123]

Wenn die CWs ständig extrem zu spät kommen, liegt vermutlich an anderer Stelle ein Problem vor.

Ja, beim Spender. Ich habe den V4 testweise auf einer Box und mal getestet, als es auf Sy-Fy extrem war. 2500ms, und das dauerhaft. Bild und Ton waren dabei einwandfrei, solange die Zeiten nicht unter 1800ms gefallen sind. Dann gab es Aussetzer. Im Normalfall um die 200ms und mal einer dabei um die 1000ms funktioniert einwandfrei.

 

[tem_invictus]

Update v09

Fixed

• Restored handling of all successful CW result types in stream_write_cw(). CWs returned as E_CACHE1, E_CACHE2, or E_CACHEEX are now installed just like E_FOUND results instead of being reported as handled without updating the StreamRelay key.
• Restored per-connection ECM parity tracking from the v10C implementation. Repeated ECM notifications for the same ODD/EVEN parity no longer mark a valid key as old while OSCam suppresses a duplicate CW response.
• Initialized and reset the ECM parity tracker when a connection starts, the active ECM changes, or a stream source reconnects.

Behavior

• Cache hits can now start and refresh StreamRelay descrambling correctly.
• Avoids stale KeyOld states that could trigger resync drop, missing audio, or an unknown media type message after transport-stream packet loss.

@Robert51 , das löst hoffentlich die Probleme die du beschrieben hast

 

[Robert51]

Heute hatte ich mit dem Patch v09 wieder das Problem mit "unbekannter Medientyp". Trat auf, als der Senderwechsel von Romance TV auf Universal TV gemacht wurde. Ich teste jetzt mal die nächsten Tage die Version von BugSpencer, ob es an meiner Box liegt.

Spoiler: Log

2026/08/06 23:06:24 75E6787D c (dvbapi) Demuxer 0 stopped descrambling for program 0206 (Romance TV)
2026/08/06 23:06:24 2BCAAC2B c (client) plain streamrelay-client 127.0.0.1 granted (anonymous, au=off)
2026/08/06 23:06:24 2BCAAC2B c (relay) Stream client 15 connected. ip=127.0.0.1 port=37534
2026/08/06 23:06:24 2BCAAC2B c (relay) Stream client 15 request. host=127.0.0.1 port=8001 path=/1:0:19:65:10:85:C00000:0:0:0: (http header)
2026/08/06 23:06:24 75E6787D c (dvbapi) Demuxer 0 ecmpid 0 CAID: 09F0 ECM_PID: 1F35 PROVID: 000000
2026/08/06 23:06:24 75E6787D c (dvbapi) Demuxer 0 ecmpid 1 CAID: 098D ECM_PID: 1C35 PROVID: 000000
2026/08/06 23:06:24 75E6787D c (dvbapi) Demuxer 0 ecmpid 2 CAID: 098C ECM_PID: 1A35 PROVID: 000000
2026/08/06 23:06:24 75E6787D c (dvbapi) Demuxer 0 found 3 ECM pids and 5 STREAM pids in CA PMT
2026/08/06 23:06:24 75E6787D c (dvbapi) Demuxer 0 trying to descramble PID 1 CAID 098D PROVID 000000 ECMPID 1C35 ANY CHID PMTPID 0065 VPID 05FF
2026/08/06 23:06:24 75E6787D c (dvbapi) Demuxer 0 trying to descramble PID 2 CAID 098C PROVID 000000 ECMPID 1A35 ANY CHID PMTPID 0065 VPID 05FF
2026/08/06 23:06:24 2BCAAC2B c (relay) Stream client 15 waiting for valid CW before buffering (timeout=5000 ms)
2026/08/06 23:06:25 75E6787D c (relay) Using ecm_mode=0x04
2026/08/06 23:06:25 75E6787D c (ecm) DVBApi (P: 098D:000000:0065:1C35:125D: #ECM_L:B7 #CW=000000000000000067BE4A0628BBE74F HOP:00): found (110 ms) server - Universal TV
2026/08/06 23:06:25 2BCAAC2B c (relay) StreamrelayDelayBuffer teminvictus_v09 Start dvbcsa_bs_batch_size=128 active_caid=098D active_ecm_pid=1C35 key_mask=0x02
2026/08/06 23:06:25 00000000 (relay) (ODD) TimeOK=509ms Delay=500ms DelayBuffer: Used=587.8 KiB, Size=2.0 MiB
2026/08/06 23:06:26 75E6787D c (dvbapi) Demuxer 1 ecmpid 0 CAID: 09F0 ECM_PID: 1F35 PROVID: 000000
2026/08/06 23:06:26 75E6787D c (dvbapi) Demuxer 1 ecmpid 1 CAID: 098D ECM_PID: 1C35 PROVID: 000000
2026/08/06 23:06:26 75E6787D c (dvbapi) Demuxer 1 ecmpid 2 CAID: 098C ECM_PID: 1A35 PROVID: 000000
2026/08/06 23:06:26 75E6787D c (dvbapi) Demuxer 1 found 3 ECM pids and 5 STREAM pids in CA PMT
2026/08/06 23:06:26 75E6787D c (dvbapi) Demuxer 1 trying to descramble PID 1 CAID 098D PROVID 000000 ECMPID 1C35 ANY CHID PMTPID 0065 VPID 05FF
2026/08/06 23:06:26 75E6787D c (dvbapi) Demuxer 1 trying to descramble PID 2 CAID 098C PROVID 000000 ECMPID 1A35 ANY CHID PMTPID 0065 VPID 05FF
2026/08/06 23:06:27 75E6787D c (dvbapi) Demuxer 1 restarting decoding requests after 1 ms with 2 enabled and 1 disabled ecmpids!
2026/08/06 23:06:27 75E6787D c (dvbapi) Demuxer 1 trying to descramble PID 1 CAID 098D PROVID 000000 ECMPID 1C35 ANY CHID PMTPID 0065 VPID 05FF
2026/08/06 23:06:27 75E6787D c (dvbapi) Demuxer 1 trying to descramble PID 2 CAID 098C PROVID 000000 ECMPID 1A35 ANY CHID PMTPID 0065 VPID 05FF

 

[Kind regards]

zum einen hast du keinen Streamrelay User festgelegt ( deshalb anonymous) und meines Wissens nutzt Romance TV kein SR.

 

[Robert51]

Das mit Romance ist mir klar. Es ging ja nur darum, daß beim Wechsel von diesem Sender zu Universal TV die Meldung "unbekannter Medientyp" kam. Vielleicht ist dieser Hinweis ja hilfreich.