Oscam StreamRelay Delay Mod

[OnkelAtze]

Das Problem war: StreamRelayDelayModv2.patch hat mehrere Threads auf dieselben Daten losgelassen, ohne sie sauber zu schützen.
Ein Thread schreibt Streamdaten, ein anderer liest und entschlüsselt sie, ein weiterer setzt neue CWs.
Ohne korrektes Locking kann dabei "Mist" passieren: kaputte TS-Pakete, falsche CW, Crashes oder sporadische Fehler...

Darum kamen die pthread_mutex rein.
Durch Writer-Thread gemeinsam erzeugte Zustände:

Ringbuffer wird gleichzeitig gelesen und geschrieben.
CWs können gleichzeitig gesetzt, gelesen und freigegeben werden.
realloc() im Buffer wäre mit alten Pointern gefährlich.
Auf 32-bit/MIPS sind manche größere Werte nicht automatisch sicher lesbar.

Meine Version macht jetzt:

Daten werden kurz aus dem Ringbuffer kopiert, danach wird ohne Lock entschlüsselt und gesendet.
Der Ringbuffer ist geschützt.
CW Zustand ist geschützt.
send() behandelt Teilsendungen korrekt.

StreamRelayDelayModv3.patch ist der saubere Build-Stand. (aus meiner Sicht)
Ob er im Livebetrieb auf einer Box wirklich stabil läuft, können nur echte Test zeigen.

 

[latte0815]

Hi,

@OnkelAtze
mit dieser Version gab es jetzt keine Probleme beim bauen. Leider kann ich im Moment nicht weiter testen da Family am TV hängt. Die 920er ist trotz der Patche immer noch ziemlich bockig, zumindest meine.

 

[Token]

vielleicht solltest du auch mal lernen, das "bockige" einer 920 zu verstehen, um es effektiv zu beheben!
das sinnfreie rumpatchen hilft da nicht unbedingt weiter!
ein emu und irgendwelche "wunder".patch'es sind da mit sicherheit keine lösung!

 

[BugSpencer]

@Token mit meiner V2 aus dem ersten Post,
hilft "stream_tcp_waitall = 0" bei der 920er.
ja oder nein
wenn nicht, kann das wieder raus.



pthread_mute: ist es denn je passiert das was defekt geschrieben wurde?
Das sollte nicht möglich sein. Ein Thread schreibt an einer stelle, ein anderer liest an anderer stelle. Ein Grow ist abgeischtert
Den Buffer kann man außerhalb von oscam Testen

Das was ich getestet habe, muss ich noch mal ändern, test fehlgeschlagen.

 

[OnkelAtze]

Wenn der Buffer als echter lockfreier SPSC-Ringbuffer gedacht ist, muss er auch so implementiert sein, feste Größe oder grow nur außerhalb des Parallelbetriebs, atomare read/write-Indizes, klare Speicherbarrieren und keine internen Pointer, die nach Grow/Realloc weiterverwendet werden. Im aktuellen v2-Patch teilen sich Reader und Writer aber Metadaten und Buffer-Lifetime. Deshalb ist Mutex hier Absicherung gegen Race Conditions. Ein externer FIFO-Test reicht dafür nicht aus, weil er das OSCam-Threading mit CW-Updates, Writer-Thread, Disconnect und Grow nicht vollständig abbildet.

Ich will dir kein Kind in den Bauch reden. Es ist dein Projekt. Ich habe nur gezeigt, was ich ändern würde. Wenn das nicht relevant ist, bleib bei v2.

 

[latte0815]

vielleicht solltest du auch mal lernen, das "bockige" einer 920 zu verstehen, um es effektiv zu beheben!
das sinnfreie rumpatchen hilft da nicht unbedingt weiter!
ein emu und irgendwelche "wunder".patch'es sind da mit sicherheit keine lösung!

Was gibt es da zu verstehen? Es wurde doch wohl eindeutig festgestellt das es an den Treibern der Box liegt. Was ist denn für dich denn schon wieder Sinnfreies rumpatchen?
Was hat denn jetzt der EMU schon wieder damit zu tun, ist dir eventuell mal in den Sinn gekommen das man auch mehrere Boxen in Verwendung hat?

 

[Token]

Es wurde doch wohl eindeutig festgestellt, das es an den Treibern der Box liegt.

NEIN, dein thema liegt nicht an den treibern!

mal abgesehen, das es hier nicht reingehört, weil es mit dem SR-Delay-Mod garnix zu tun hat:

baue mal folgendes testszenario:
1. eine oscam aus dem git@master ... ohne emu, ohne ssl, ohne sign
2. noch eine oscam aus dem git@master ... ohne emu, aber mit ssl+sign
3. eine oscam aus dem git@mbedtls-openssl ... ebenfalls ohne emu, aber hier auch mit mbedtls+sign drin!
=> fällt dir was auf ?!
und wenn du das dann registriert+verarbeitet hast, dann weiste, das dein thema nicht an den treibern liegt!
=> und auch nicht mit irgendwelchen "wunder.patches" adressierbar ist!

 

[Token]

@Token mit meiner V2 aus dem ersten Post ...

lt. @el_malto bin ich der falsche ansprech-partner, da mir ja nahegelegt wurde, ich sollte mich hier "aus dem funkverkehr raushalten!"
aber es hat sich ja hier genügend "fach-personal" geäussert, die können dir bestimmt deine frage beantworten.

für mich ist die bisherige arbeits+funktionsweise des delay.mod jedenfalls so "nicht geeignet" um nachhaltig+sicher schwankungen auszugleichen.
von daher würde ich mir das ganze eher aus der ferne weiter anschauen wollen.

 

[el_malto]

lt. @el_malto bin ich der falsche ansprech-partner, da mir ja nahegelegt wurde, ich sollte mich hier "aus dem funkverkehr raushalten!"

Lesen und verstehen...
Ich denke jeder hier freut sich über Feedback der sich auf die Funktionalität der in diesem Thread angebotenen Patches bezieht. "Funkverkehr" über Herangehensweisen der Devs die hier ihre Patches zur Verfügung stellen, sollte man hier "raushalten".

 

[Token]

"Funkverkehr" über Herangehensweisen der Devs die hier ihre Patches zur Verfügung stellen, sollte man hier "raushalten".

und da ich das etwas anders sehe, halte ich mich wunschgemäss nun zurück!

 

[adi22]

Token, hoffenttlich.
Allein aus Respekt dem Dev gegenüber!
Du machst es nur schlecht weil es nicht von aus einer bestimmten Ecke kommt.

Am besten sollten man diese Kommentare alle löschen.

 

[Alex]

Der nächste der irgendjemand hier persönlich angreift, bekommt Urlaub!
Jetzt isess mal gut!

 

[BugSpencer]

Fertige V4
Source im 1. Beitrag.
Es sind keine Timeout Zeiten mehr nötig.
Wenn der ECM Intervall 6s oder 10s ist, Egal es geht immer.

Es ist nicht die letzte Anpassung.

 

[latte0815]

NEIN, dein thema liegt nicht an den treibern!

mal abgesehen, das es hier nicht reingehört, weil es mit dem SR-Delay-Mod garnix zu tun hat:

baue mal folgendes testszenario:
1. eine oscam aus dem git@master ... ohne emu, ohne ssl, ohne sign
2. noch eine oscam aus dem git@master ... ohne emu, aber mit ssl+sign
3. eine oscam aus dem git@mbedtls-openssl ... ebenfalls ohne emu, aber hier auch mit mbedtls+sign drin!
=> fällt dir was auf ?!
und wenn du das dann registriert+verarbeitet hast, dann weiste, das dein thema nicht an den treibern liegt!
=> und auch nicht mit irgendwelchen "wunder.patches" adressierbar ist!

Dreimal darfst du raten was ich alles schon versucht habe. Bis vor kurzem lief auf der Wohnzimmer 920er die von dir in Punkt 1 genannte Version. Was ich grundsätzlich nicht mit baue ist sign, verstehe auch nicht was es mit den Bild und oder Tonproblem zu tun haben soll.
Und um auf deine Frage zu kommen, nein mir fällt nichts auf außer das es mit keiner Version vernünftig funktioniert und immer irgendwelche Probleme auftrete.
Ich verstehe auch nicht warum du immer um den heißen Brei schreiben musst, schreib doch mal einfach was zu sagen ist und bitte las das von oben herab Geschreibe.

 

[60plus]

Hi,

ein kurzer Bericht, auf meiner Dreamone mit AIO, läuft die v4 mit s4 gebaut, sehr gut.