Dies ist eine mobil optimierte Seite, die schnell lädt. Wenn Sie die Seite ohne Optimierung laden möchten, dann klicken Sie auf diesen Text.

ICAM Patch oscam-emu

Status
Für weitere Antworten geschlossen.
So wie er das geschrieben hat und so wie ich es verstehe, meint er, wer über payserver guckt, hat die ecm Länge b7 und wer die karte lokal hat a7. Was normalerweise Blödsinn ist. Sky hat vor ca 2 Wochen die ecm Länge geändert und da spielt es keine Rolle ob man über lokal guckt oder über payserver. Für alle sind die ecm längen nämlich gleich. Vieleicht irre ich mich ja auch nur, aber so verstehe ich seinen post in verbindung mit Ps und lokal am ende der jeweiligen Zeile.
 
Zuletzt bearbeitet:
Das ist richtig und sollte Allgemeinwissen sein - geht hier aber völlig am Thema vorbei.

Mein Post bezog sich auf die Aussage man solle einen "ecm fix 400" setzen und zwar im stream relay:
[streamrelay]
stream_ecm_delay = 400

Das ist einfach Blödsinn... und da gibts auch keine zwei Meinungen.

Ist aber auch egal. Habe gerade nochmal nachgeschaut und festgestellt, dass der hier herumgereichte patch den stream relay internen delayer garnicht (mehr) benutzt.
Von daher möge man meinen Post getrost ignorieren und stattdessen - welche Zahl auch immer man erotisch anziehend findet - im stream relay config eintragen.
 
@TuzlaDVB
Frage hierzu:
macht es denn Sinn, den ECM-Delayer in einer V10 zu fixen - oder ist das fürs iCam völlig irrelevant?
wobei wir natürlich jetzt nicht wissen, ob @icb den absichtlich aussen vor gelassen hat ?!
 
Ich hatte noch nie Freezer, warum sollte man dann am Patch was patchen? Der läuft doch
 
@TuzlaDVB
Frage hierzu:
macht es denn Sinn, den ECM-Delayer in einer V10 zu fixen - oder ist das fürs iCam völlig irrelevant?
wobei wir natürlich jetzt nicht wissen, ob @icb den absichtlich aussen vor gelassen hat ?!
Nein macht keinen Sinn - es ist gut so wie es ist.

Sollte jemand trotz Softwaredescrambler und vermutlich nicht lokaler Karte tatsächlich das Problem haben das seine DCW zu schnell reinkommen hat man immer die Möglichkeit das über die 'normale' oscam zu fixen - z.B. per dvbapi. Aber ganz ehrlich, das Konstrukt ist so theoretisch, das ist wirklich keine große Mühe wert.
 
@TuzlaDVB
Danke für die Ausführungen - dann lassen wir es so (und ignorieren den ECM-Delayer)!
 
Zu schnelle CW Antworten kann man hier doch auch nur beim Umschalten erhalten. Da ist das CW beim Spender schon im Cache und kann innerhalb ein paar ms (man sagt ja pro Hop ca. 50ms) geschickt werden. Die normalen zyklischen CW Anfragen/Antworten können ja gar nicht schneller kommen, da die Quelle der CWs hier immer noch eine reale Karte ist und kein Emu der innerhalb <10 ms ein CW errechnen kann. Und waren die zu schnellen CWs nicht eher ein Problem bei Hardware Descrambler? Der ICAM Descrambler ist ja ein Software Descrambler.
 
Dann empfehle ich an der Stelle 666
 
@Schimmelreiter
Ich frage mich ernsthaft, ob du überhaupt weisst, was diese Zahl bedeutet!?

Willst du das wirklich!? Ich jedenfalls auf KEINEN Fall!
 
Falsch! Es ist die Zahl für den Antichristen, der mit dem Teufel inkarniert ist (lies die Offenbarung Jesu Christi)

Bevor man solchen Quatsch von sich gibt, sollte man schon etwas seine grauen Hirnzellen aktivieren!
Und - nun genug davon.
 
Zuletzt bearbeitet von einem Moderator:
Status
Für weitere Antworten geschlossen.
Für die Nutzung dieser Website sind Cookies erforderlich. Du musst diese akzeptieren, um die Website weiter nutzen zu können. Erfahre mehr…