Oscam StreamRelay Delay Mod

[BugSpencer]

Ich habe mal das Streamrelay in OSCAM angepasst.
Kann das mal jemand testen?
Es ist damit möglich mit einer ECM Zeit von 5000ms ohne aussetzer zu schauen.
Wenn so eine Funktion nicht gewünscht ist, Kommentar rein, dann lösche ich das hier...
Der Stream wird einfach einstellbar/Automatisch verzögert. Also später entschlüsselt.
Das klappt Super. Hier im Bild sieht man schon 4 einstellungen dazu.

Mehr Infos trage ich hier noch nach.
Selber getestet habe ich nur die: cortexa15hf_openpli_scarthgap, Alles gebaut mit SimpleBuild4
Wenn das gut funktioniert, und ich den Source entrümpelt habe, poste ich den auch

ich vermute besser die Uhrzeit von Transponder auf NTP umstellen. Das macht dem Streamrelay nichts. Aber beim OpenATV stand bei einem Problem Transponderzeit im Log

Beschreibungen

Parameter:
stream_relay_delay_time_min = 0
Hier kann man ein Delay einstellen, was beim start schon aktiv ist.
1000ms ergibt ECM Zeit darf 1600ms sein anstatt 600ms bis Bildfehler auftreten, das Zappen dauert dann 1000ms länger

stream_relay_delay_time_max = 4500
Hier kann man einstellen wie hoch das Delay Automatisch erhöht werden darf.
schreibt DVBAPI einen Odd oder Even Key ins Streamrelay wird sich die Zeit gemerkt (Struct vom key erweitert)
Wird beim entschlüsseln ein ODD Key benötigt, und ist der letzte ODD Key vor länger als 12000ms geschrieben worden, wird das delay solange erhöht bis der Key da ist.
4500ms = ECM darf gut 5000ms sein.
wenn man mehr einstellt muss man aufpassen das nicht irgendwann der key zu neu ist.
Das würde auch gehen, macht aber beim zappen keinen Spass [dvbapi] delayer = 5000; stream_relay_delay_time_min = 5000; stream_relay_delay_time_max = 10000

stream_relay_log = 1
wenn 1 wird im Log die Zeit von jedem keywechsel angezeigt.
bei delay erhöhung werden 3 zeilen auch so angezeigt

stream_tcp_waitall = 0
0 ist das originale verhalten
DVB_BUFFER_WAIT_CSA wird nie kommen weil "recv(.. ,MSG_WAITALL)" immer wartet bis DVB_MAX_TS_PACKETS komplett voll ist
DVB_MAX_TS_PACKETS habe ich aber auf 256 geändert (vielfaches von 128)
es werden so immer komplette 128x188 byte entschlüsselt
nicht wie vorher 278= 128+128+22 immer gleich, auch wenn mehr oder weniger ankommt
1 hier habe ich mal probiert auf delay zu Optimieren
TCP recv ist ohne MSG_WAITALL, DVB_BUFFER_WAIT_CSA ist wieder aktiv. DVB_BUFFER_WAIT_CSA wie vorher 128
werden 130 packte empfangen, werden 128 oder 32+32+32+32 je nach CPU in den Delaybuffer geschrieben
2packete dauert für die cpu so lange wie 128, also lege ich die mal zurück
wenn beim nächsten recv schon (bytesRead > packetSize) vorhanden sind, dann wird mit poll kurz geprüft ob schon neue daten kommen würden.
Sind daten da werden die gelesen, zum Delaybuffer aber erst ab DVB_BUFFER_WAIT_CSA
Sind keine neuen Daten da PollTimeout, werden die vorhandenen daten schon direkt weitergeleitet.
nicht erst 100ms warten, ein möglichst gleichmässiger flow.
Die CPU Zeit war bei meinem Receiver nur minimal höher, aber es wurde auch schon vorher ein 22er eingespart.
Bei mir war es immer nur ein batch mit weniger als 128, nach vielen mit 128/256
Also einfach testen was besser läuft

Das Schreiben zurück zum Receiver habe ich in einen Thread gepackt.

Ich habe generell keine Uhrzeit verwendet, nur die Laufzeit vom Receiver, die ändert sich nicht bei Zeitänderungen.
Nicht das sich jetzt die Transponderzeit um das Delay verschiebt?

Man kann nicht pauschal 1MB verzögern, das klappt nicht, Weil die Baudrate Dynamisch schwankt, deswegen wird mit zeitstempeln gearbeitet

Log:
2026/05/26 23:36:17 5BBD161A c (ecm) dvbapi (098D@000000/025B/0083/B7:AB2D03C86EEE86F9FF5E04CED4A341FA): found (354 ms) by oscamserver - Sky Cinema Premiere
2026/05/26 23:36:17 00000000 (relay) (ODD) TimeOK=322ms Delay=100ms DelayBuffer: Used=41772bytes, Size=2097140bytes Packets: Fuell=0 Cluster=97 Small=97 Wait=0
2026/05/26 23:36:24 5BBD161A c (ecm) dvbapi (098D@000000/025B/0083/B7:4DFA34BAE25A5169A590D688AB12E070): found (364 ms) by oscamserver - Sky Cinema Premiere
2026/05/26 23:36:24 00000000 (relay) (EVEN) TimeOK=313ms Delay=100ms DelayBuffer: Used=41772bytes, Size=2097140bytes Packets: Fuell=0 Cluster=102 Small=102 Wait=0
TimeOK=322ms der Key wurde zu dem zeit punkt wo er das erste mal benötigt wurde, vor 322ms von DVBAPI geschrieben, ob der auch richtig ist, egal
Delay=100ms das Delay ist gerade 100ms, alles was im Delaybuffer ist, bleibt da auch drin, bis älter als 100ms 1:1 raus wie rein 100ms verzögert
Used=41772bytes so viel ist im Delaybuffer
Size=2097140byte so groß ist der Delaybuffer gerade
Packets: je ODD/EVEN wechsel werden diese auf 0 gesetzt (nach der Log ausgabe) mit tcp_waitall wird das nicht mit angezeit, weil immer gleich
Fuell=0 keinmal wurden 256x188 byte empfangen, bytesRead=DVB_MAX_TS_PACKETS
Cluster=97 97x waren es packete vom clustersize 128 oder 32 je CPU (wenn buffer voll zählt das auch)
Small=97 97x waren es weniger als 128x188 byte, nach einem poll timeout 5ms, siehe an genau gleich
Wait=0 keinmal musste wegen DVB_BUFFER_WAIT_CSA gewartet werden


Ringbuffer:
je Stream wird ein Ringbuffer erstellt, der auch Dynamisch wachsen kann.
Das ist jetzt fix eingestellt.
beim Start 2MB + 2MB ab je 1000ms (stream_relay_delay_time_min)
grow 2MB
max 20MB
In den Ringbuffer kann ich beliebige längen einfügen. Die bekommen bei einfügen einen Zeitstempel.
Ist max erreicht, wird verworfen bis es weiter geht. -> Log


Hier mal ein Log:
[streamrelay]
stream_relay_delay_time_min = 0
also ohne delay angefangen,
ein found (754 ms), da wurde das delay auf 200ms hochgesetzt, danach nochmal auf 500ms.
Dabei wird alles korrekt entschlüsselt.
Bei Delay erhöhung gibt es dann einen kurzen Frezze im Bild/Ton. Alles kommt später an. In einer Aufnahme bemerkt man das nicht
man kann ja auch stream_relay_delay_time_min = 1000 oder höher setzen, dann dauert das zappen länger aber zwischendurch muss nicht erhöht werden

Spoiler: Log

• 2026/05/25 19:49:17 58BED8B7 c (ecm) dvbapi (098D@000000/0005/008B/B7:E2A2EAA13BDF034E7889BB666EF08936): found (367 ms) by oscamserver-4 - Sky Cinema Christmas
• 2026/05/25 19:49:17 00000000 (relay) (EVEN) TimeOK=260ms Delay=0ms DelayBuffer: Used=24076bytes, Size=2097140bytes Packets: Fuell=23 Cluster=217 Small=194 Wait=23
• 2026/05/25 19:49:24 58BED8B7 c (ecm) dvbapi (098D@000000/0005/008B/B7:A967C47404777E497C9B7688D058AD94): found (311 ms) by oscamserver-4 - Sky Cinema Christmas
• 2026/05/25 19:49:24 00000000 (relay) (ODD) TimeOK=312ms Delay=0ms DelayBuffer: Used=24076bytes, Size=2097140bytes Packets: Fuell=17 Cluster=204 Small=187 Wait=17
• 2026/05/25 19:49:31 58BED8B7 c (ecm) dvbapi (098D@000000/0005/008B/B7:A6A1B5F62B85CF89FF73DCAB1A09EBC4): found (270 ms) by oscamserver-4 - Sky Cinema Christmas
• 2026/05/25 19:49:31 00000000 (relay) (EVEN) TimeOK=321ms Delay=0ms DelayBuffer: Used=17684bytes, Size=2097140bytes Packets: Fuell=62 Cluster=320 Small=259 Wait=62
• 2026/05/25 19:49:38 00000000 (relay) (ODD) KeyOld= 14293ms
• 2026/05/25 19:49:38 58BED8B7 c (ecm) dvbapi (098D@000000/0005/008B/B7:F69C54FC90E8DFE0D82E97B250F98DE1): found (754 ms) by oscamserver-4 - Sky Cinema Christmas
• 2026/05/25 19:49:38 00000000 (relay) (ODD) TimeOK=47ms Delay=200ms DelayBuffer: Used=230644bytes, Size=2097140bytes Packets: Fuell=47 Cluster=284 Small=237 Wait=47
• 2026/05/25 19:49:45 58BED8B7 c (ecm) dvbapi (098D@000000/0005/008B/B7:9A2DAA99344CBEC0382AD4A84255EAEC): found (368 ms) by oscamserver-4 - Sky Cinema Christmas
• 2026/05/25 19:49:45 00000000 (relay) (EVEN) TimeOK=436ms Delay=200ms DelayBuffer: Used=164620bytes, Size=2097140bytes Packets: Fuell=37 Cluster=240 Small=203 Wait=37
• 2026/05/25 19:49:52 58BED8B7 c (ecm) dvbapi (098D@000000/0005/008B/B7:B825651AF60D3C3BAAF771906E699AC2): found (370 ms) by oscamserver-4 - Sky Cinema Christmas
• 2026/05/25 19:49:52 00000000 (relay) (ODD) TimeOK=417ms Delay=200ms DelayBuffer: Used=140544bytes, Size=2097140bytes Packets: Fuell=24 Cluster=215 Small=190 Wait=24
• 2026/05/25 19:49:59 58BED8B7 c (ecm) dvbapi (098D@000000/0005/008B/B7:350279F2CEEA4CD4A16A80E6456A5E00): found (370 ms) by oscamserver-4 - Sky Cinema Christmas
• 2026/05/25 19:49:59 00000000 (relay) (EVEN) TimeOK=427ms Delay=200ms DelayBuffer: Used=230456bytes, Size=2097140bytes Packets: Fuell=19 Cluster=197 Small=178 Wait=19
• 2026/05/25 19:50:06 00000000 (relay) (ODD) KeyOld= 14443ms
• 2026/05/25 19:50:06 58BED8B7 c (ecm) dvbapi (098D@000000/0005/008B/B7:0022E840ABE5EFBC33C92D99DF861FBB): found (1042 ms) by oscamserver-4 - Sky Cinema Christmas
• 2026/05/25 19:50:06 00000000 (relay) (ODD) TimeOK=67ms Delay=500ms DelayBuffer: Used=395088bytes, Size=2097140bytes Packets: Fuell=22 Cluster=217 Small=195 Wait=22
• 2026/05/25 19:50:13 58BED8B7 c (ecm) dvbapi (098D@000000/0005/008B/B7:00D842BCF1A6CB0B6B66CC7DA9668234): found (291 ms) by oscamserver-4 - Sky Cinema Christmas
• 2026/05/25 19:50:13 00000000 (relay) (EVEN) TimeOK=801ms Delay=500ms DelayBuffer: Used=428200bytes, Size=2097140bytes Packets: Fuell=21 Cluster=197 Small=176 Wait=21
• 2026/05/25 19:50:20 58BED8B7 c (ecm) dvbapi (098D@000000/0005/008B/B7:EA7F166157DE4CD850EF1858094C1C31): found (284 ms) by oscamserver-4 - Sky Cinema Christmas
• 2026/05/25 19:50:20 00000000 (relay) (ODD) TimeOK=828ms Delay=500ms DelayBuffer: Used=861092bytes, Size=2097140bytes Packets: Fuell=36 Cluster=243 Small=207 Wait=36
• 2026/05/25 19:50:27 58BED8B7 c (ecm) dvbapi (098D@000000/0005/008B/B7:7F2DC49B755C366A35661C26601834F7): found (256 ms) by oscamserver-4 - Sky Cinema Christmas
• 2026/05/25 19:50:27 00000000 (relay) (EVEN) TimeOK=839ms Delay=500ms DelayBuffer: Used=680740bytes, Size=2097140bytes Packets: Fuell=80 Cluster=361 Small=281 Wait=80

Spoiler: Screenshot

Sie müssen registriert sein, um angehängte Bilder zu sehen

Anhang Source als Patch.
Im Beitrag 62 sind Fertige Version2 Fertige V2
Im Beitrag 118 sind Fertige Version4 Fertige V4

 

[Vigor]

Ist es nicht so, dass solche Zeiten nur dann auftreten, wenn man keine vernünftigen Configs hat?

 

[DarkStarXxX]

Nö, man kann seine Quellen halt nicht beeinflussen und die werden wegen des tausches des CI+ Moduls immer weniger und damit kommen die Karten immer mehr an ihre Grenzen.

Weniger Karten = Mehr Auslastung = Höhere ECM Zeiten (bei ca 550ms ist ende bei NDS / Sky).

 

[BugSpencer]

700ms gehen auch so noch, es wird die restzeit im log angezeigt
einfach in dvbapi einen delay eintragen, und damit eine schlechte ECM Zeit Simulieren

 

[Leo888]

(bei ca 550ms ist ende bei NDS / Sky).

Nur weil Da das Märchen immer wieder erzählst, wirds nicht wahrer.
Alles unter 1000ms läuft flüssig, ab dauerhaft drüber wird problematisch.

 

[DarkStarXxX]

Das ist kein Märchen.

Das kann man selbst messen, aber egal Besserwisser wie immer halt...

 

[PingX]

Läuft das auch unter VTI, ARM (VUDuo4kSE)? bekomm kein Webif?

 

[DarkStarXxX]

Dann fehlt dir vielleicht die "libdvbcsa.so.1"

opkg install libdvbcsa

 

[BugSpencer]

v1.1.0
sonst mal von console starten, und rechte 755

 

[PingX]

das läuft nur unter py3, oder? vti dann nicht?

 

[DarkStarXxX]

PingX​

Das hat mit der Python Version nichts zu tun.

 

[BugSpencer]

das ist nur oscam, sag mir die gewünschte einstellung in simplebuild4. Bis auf libdvbcsa habe ich alles abgewählt

 

[PingX]

bekomme bei opkg install libdvbcsa - incompatible architecture

und am VTI Feed findet er es nicht. Lach mich nicht aus - das ist schon eine oscam.bin (usr\bin...)?
evtl hilft das hier: download.digital-eliteboard.com/?dir=uploads%2FOScam-Trunk%2Farm%2F - diese laufen in der vu

 

[DarkStarXxX]

Dann hat VTI die lib vielleicht nicht extern musst du warten bis es eine Version mit eingebauter Lib gib.

 

[PingX]

es wär schon eine super Sache, wenn das kommen würde...