Oscam StreamRelay Delay Mod

[BugSpencer]

Ich würde den Patch in der aktuellen Form nicht anwenden. Einige Punkte sind aus meiner Sicht offen oder sollten korrigiert werden:

• In oscam-config-global.c wurde die bisherige Validierung von httpmaxrequestsize entfernt. Das wirkt fachfremd zum DelayBuffer-Patch und sieht nach einer Regression aus.
• Der Default von stream_relay_buffer_time wurde von 0 auf 500 geändert. Laut Changelog ist das weiterhin der Legacy-Startup-Delay und wirkt auch bei stream_relay_delay_buffer = 0. Damit verändert der Patch auch den Nicht-DelayBuffer-Pfad. Falls das gewollt ist, sollte es explizit begründet werden.
• Der Rückgabewert von streamrelaybuf_init() sollte geprüft werden. Wenn Speicher- oder Mutex-Initialisierung fehlschlägt, darf der Buffer nicht trotzdem als initialisiert behandelt werden.
• Der Rückgabewert von streamrelaybuf_write() sollte ebenfalls geprüft werden. Backpressure hilft gegen normale Überfüllung, ersetzt aber keine Fehlerbehandlung bei Grow-/OOM-/MaxSize-Fehlern.
• stream_resptime wurde semantisch verändert. Im Nicht-DelayBuffer-Pfad sollte geprüft werden, ob der Wert weiterhin wie vorher aktualisiert wird. Zusätzlich sollte der Cast von größeren Zeitwerten auf int abgesichert werden.
• Im Debug-Log von decrypt() wird die Batch-Größe nach dem Reset von fill[oddeven] geloggt. Dadurch kann im Log batch=0 erscheinen, obwohl vorher tatsächlich Pakete im Batch waren.
• streamrelaybuf_readPtr() ist API-seitig riskant, falls fromThread == false künftig genutzt wird, weil dann interne Read-Pointer ohne Lock verändert werden. Im aktuellen Aufrufpfad scheint das zwar nicht akut zu greifen, aber robuster wäre eine einheitlich gelockte API.

Aus meiner Sicht sind vor allem die entfernte httpmaxrequestsize-Validierung, die ungeklärte Default-Änderung von stream_relay_buffer_time und die fehlende Fehlerbehandlung bei streamrelaybuf_init() / streamrelaybuf_write() die Punkte, die geklärt werden sollten.

vG 04

• von meiner Seite passt in allen Versionen auch nocht nicht alles, Veto das Irgendwo so jetzt einzuschecken
• Rückmeldungen, was Funktioniert, und was nicht, vergleiche was wo besser ist, vermisse ich hier noch
• ich habe bei mir Intern auch schon was angepasst, bin aber noch am Testen.
• httpmaxrequestsize-Validierung, Das war bei mir schon verloren gegangen
• Default-Änderung von stream_relay_buffer_time, da verwende ich sogar 700ms, das ist essentiell, damit es beim add Delay es nur 1x Kurz Pause macht, und nicht eine weile Bild/Ton stottert bis es sauber weiterläuft (v2, v4 bei den anderen?)
• Delaybuffer startet erst nach gültigem CW, das finde ich nicht optimal
• Resync-Grace-Zeit, wofür, warum zurücksetzen

 

[tem_invictus]

Dafür machen wir das ja hier, damit man testen/probieren kann. Ob das überhaupt in der Master kommt ist eine ganz andere Frage.

stream_relay_buffer_time, hier geht es ja vor allem darum, was als default mitgeschickt wird. Welcher Wert da am besten funktioniert, hängt vom jeweiligen Setup ab. Teilweise macht heir auch bis zu 1500ms Sinn. Und das sollte der User einstellen und nicht stumpf einen Wert bekommen. Und vor allem ist es bei 0 erstmal deaktiviert und der User muss sich dafür entscheiden, dies nutzen zu wollen.

stream_relay_resync_grace, wenn mitten in Stream mal keine found kommt, würde das stream delay die ganze Zeit vergrößert werden bis zum maximum und selbst wenn wieder ein found kommt dort bleiben. Hiermit kann man also festlegen, kommt z.B. 1000ms kein found, dann den Buffer einmal zurücksetzen.

Hier hatte ich was zu gültigem CW geschrieben, halte ich für zwingend notwendig.

Beitrag im Thema 'Oscam StreamRelay Delay Mod'

21. Juni 2026

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...

• tem_invictus

• 

 

[Robert51]

Beim selber bauen bin ich leider raus.

Dann muss ich halt warten, bis jemand so freundlich ist.

 

[Token]

Robert, ich würde dir empfehlen, dich in das thema S4=Simplebuild4 einzuarbeiten,
und/oder zum einstieg den S3-Builder vom DEB anzuschauen.

vielleicht kann ja mal @Phantom/@Alex die v6 und v7 mit in den DEB-builder integrieren ?!

 

[Azo]

Hi,

Spoiler: build

| Addons : WEBIF WEBIF_LIVELOG WEBIF_JQUERY WITH_COMPRESS_WEBIF HAVE_DVBAPI READ_SDT_CHARSETS WITH_DEBUG MODULE_MONITOR WITH_LB
| Protocols: CAMD35 CAMD35_TCP NEWCAMD CCCAM CCCSHARE GBOX STREAMRELAY
| Readers : NAGRA NAGRA_MERLIN IRDETO CONAX CRYPTOWORKS SECA VIACCESS VIDEOGUARD DRE TONGFANG BULCRYPT GRIFFIN DGCRYPT
| CardRdrs : PHOENIX INTERNAL

Tschau
Azo

 

[60plus]

Hi,

hier noch eine bitte schön mit STATIC_LIBDVBCSA

Token hat Recht, du schaffst es, dich damit zu beschäftigen und wenn man sich bemüht bekommt man auch Hilfe.

​

​

 

[Robert51]

Danke. Werde das mal zumindest versuchen. Mit ü 70 nicht ganz so einfach.

 

[Token]

das frischt aber etwas die gehirnzellen auf, und das brauchen wir alten ja regelmässig.

 

[twicko]

Ich habe den Patch mit der aktuellen Oscam gebaut. Muss ich in der config noch was einstellen oder funktioniert diese auch so?

Gibt es da Wertek die man empfehlen kann?

Vielen Dank!

 

[BugSpencer]

Ich habe etwas probiert:

In OSCAM ist das ja so eingestellt:
#define DVB_MAX_TS_PACKETS 278

hier im Patch wird es so verwendet:
#define DVB_MAX_TS_PACKETS 256

Ich habe es mal mitzählen lassen, wie groß es sein darf, damit es immer in 2x128er decrypt passt.
262 ging bei einem kurzem test, 263 schon nicht mehr.
Also kann man es auch bei 256 belassen.

Bei cryptCount=128 muss die unveränderte oscam 50% mehr rechnen als nötig

 

[kitte888]

kann man die auch mit den emu bauen

da muss aber einiges am pacth gemacht werden

 

[tem_invictus]

Und hier wäre v08 von mir.

WICHTIG, es sind ein paar Namen geändert. Ich fand das jetzt so erstmal sinnvoller für den weiteren Verlauf. Lässt sich mit Sicherheit drum streiten

bisher "stream_relay_delay_time_min" wurde zu "stream_relay_delay_time"
bisher "stream_relay_delay_time_max" wurde zu "stream_relay_cw_timeout"

Changed

• Renamed stream_relay_delay_time_min to stream_relay_delay_time and stream_relay_delay_time_max to stream_relay_cw_timeout across configuration, runtime code, and WebIf. No compatibility aliases are provided.
• Restored the legacy stream_relay_buffer_time WebIf input to five digits.
• Removed unused delay-buffer and active-CW state, normalized the new buffer code to OSCam's tab indentation, and renamed the Fuell statistic to Full.

Fixed

• Kept connection slots occupied until writer shutdown and all per-connection keys, mutexes, client data, and delay-buffer state are fully cleaned up.
• Cleared TS scrambling bits only after successful decryption, and limited ECM key-aging notifications to the extended delay-buffer path.
• Terminated the affected connection when writer allocation or thread creation fails, preventing undrained buffers and reader stalls.
• Added a five-second client socket send timeout and treated partial sends as connection errors instead of silently dropping data.
• Reset writer, buffer, packet-framing, PAT/PMT/PID, key, and active-CW state when replacing a stream source.
• Added configuration fixups that cap stream_relay_delay_time at 9999 ms and constrain stream_relay_resync_grace to stream_relay_cw_timeout.
• Hardened ring-buffer initialization, record bounds, and overflow handling, and compacted the buffer when too little tail space remains for a wrap marker.
• Made reader/writer statistics atomic to remove data races and signed 16-bit overflow.

 

[Clint_Eastwood]

@Alex, oder @Phantom
könnt ihr die v08 bitte hier mit einbauen, danke

 

[Alex]

Das wird Phantom schon machen, sobald er dazu kommt

 

[checkersky]

Könnte jemand den V8 patch mal für vuplus4k_armv7 bereit stellen ?
Danke !