Digital Eliteboard - Das Digitale Technik Forum

Registriere dich noch heute kostenloses um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereiche, welche für Gäste verwehrt bleiben

Oscam Versuch V13/NDS

AW: Oscam Versuch V13/NDS

in einem ersten Schritt mach ich erstmal eine Quick&Dirty Umsetzung eines cardclients auf PC-Basis/FTDI-Usb-Serial (wg.76800 b/s)/Season-Interface im Unicam, als proof-of-concept ob das kritische Timing überhaupt machbar ist. Erst wenn das sauber läuft, werd ich mich an die Oscam-Integration ranmachen.
BTW, hast du irgendwelche Infos zu dem SOC der auf dem MAtrix-Einschub vebaut ist-es geht mir um die Möglichkeiten der integrierten Uarts...
 
AW: Oscam Versuch V13/NDS

Hi,

eine Beobachtung "Verhalten Diablo>Oscam mit Gbox Protocoll" möchte ich euch noch mitteilen,
Diablo 1.3 kann der Delayer bei NDS gegen null gesetzt und die bekannten Störungen treten nicht auf.
Der MCA Test steht noch aus "oscam>oscam mit Gbox".


mfg
60plus
 
AW: Oscam Versuch V13/NDS

@KixKa
Könnte man nicht gleich auf Raspberry mit Season-Interface ein eigenes System aufbauen?
Wäre dann zu allen TV's kompatibel.
 
AW: Oscam Versuch V13/NDS

@60plus : Kannst Du das mal etwas elaborieren was Du meinst ?

P.S.: Entsprechende Configs zum vergleich hier posten bitte, ich habe alle Karten, und Module, so dass ich corosstesten kann.
 
AW: Oscam Versuch V13/NDS

Ich quote mal aus dem Anderen Beitrag der hier oberhalb verlinkt is, weil es ja hierher gehoert :

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!

Ja den MCAM task haben wir schon lange im Verdacht. Deswegen auch die Intention es ohne den zu versuchen, allerdings ist die Frage, das kann auch vom Handschaeke des CAMs selber herruehren, oder eben auch von schlechter Programmierung, die a apparent ist. Jedenfalls sind 500ms wenn man alle anderen delays dazurechnet eindeutig zu viel, es gibt ja einiges an latency im path, 180 ~300 ms auf dem OSCAM Server, Network latency mit Handshakes, OSCAM auf dem MCA (auch nochmal gut und gerne und vor allem variable 100~400 ms), ab ca. 1200 ms delay kommt es auch bei allen anderen Systemen (also z.B. ProgDVB + Acamd + selber OSCAM Server) zu den Freezern...

/Gompf
 
AW: Oscam Versuch V13/NDS

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!


Ganz so ist es nun aber doch nicht, auch wenn es sicherlich nicht die root cause des Problems ist, denn die unterschiedlichen Protokolle haben durchaus auch selbst eine verschiedene Latenz. Sprich was 60Plus ueber das Diablo sagt kann schon stimmen, deswegen interessiere ich mich auch fuer die Konfigs, denn mit meinem Setup kann man das genau vermessen und dann sehen um wieviel Zeit es sich eigentlich dreht (also ich meine eine Vergleichsmessung mit dem Diablo)

/Gompf
 
AW: Oscam Versuch V13/NDS

Für geringe Latenz würde ich dir das Camd35 (UDP) -Protokoll empfehlen ;-) damit klappt V13 sogar übers Inet...
 
Zuletzt bearbeitet von einem Moderator:
AW: Oscam Versuch V13/NDS

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!
Völlig außer acht gelassen sind bisher die Latenzen in der Senderichtung, sprich inwieweit bereits der ECM-Empfang vom CAM-Modul schon verzögert ist. Wenn da nochmal 300-400 ms durch die grottige Programmierung dazukommen, kann das prinzipiell nie richtig funktionieren. Eine weitere Möglichkeit besteht in der verwendeten Protokollart zwischen CAM und MCA, wenn dass ein simples Polling-Protokoll ist, kommen da noch weitere Seiteneffekte dazu...
 
AW: Oscam Versuch V13/NDS

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!
Darauf wirds wohl hinauslaufen. Ich für meinen Teil hab mich vom MCA selbst bereits wieder verabschiedet, da sind mir zuviele Unzulänglichkeiten drin. u.a. Probleme mit Erkennung im TV (CI-Interface)usw. Als reines Wifi-Cardeinschub ist mir das Ding zu wenig dokumentiert. Da sind mir RPI mit Wlan-USB-Stick und Season viel angenehmer. Ob der Client überhaupt was wird, steht noch in den Sternen. Nach Sichtung des Codes sind mir da einige Probleme aufgefallen, die nicht so einfach zu bewältigen sind:
-> die verschlüsselung allgemein ist eher verwirrend. jede Menge Bitschiebereien, Byte-Nibble Tauschereinen suw.
-Camcrypt-Aushandlung über InsBC/BE: Das steckt ein lonmult/partialmod drin, das sieht nach asymetrischer Verschlüsselung aus (ähnlich RSA), d.h. mangels Kentniss des Verschlüsselungskeys keine Chance auf echte Nachbildung. Abhilfe: immer mit festen Keys arbeiten und eine geloggtes Antwort BC/BE nutzen, dann sind die (AES-)Keys bekannt (das erinnert mich irgendwie an Irdeto/BC 0384 ... ;-) )
-Laufende ECMs:
-> Verschlüsselung scheint eine Mischung aus AES, Hash-Tabelle und Bitschieberei zu sein, mit zusätzlichem Störfaktor eines fortlaufenden Wertes. Augenscheinlich ist das Verfahren symetrisch aufgebaut (damit auch in Verschlüsselungsrichtung nachbildbar)-muss noch getestet werden.
-> CW-Postprocessing: Diese Art Zusatzverschlüsselung wird über den ECM-Header aktiviert-den ich an der Kartenschnittstelle nicht zur Verfügung habe. Postprocessing wird dann also nie durchgeführt und ich schicke die Antwort nativ an mein CAM (wo dann das Postprocessing gemacht wird, da mein CAM den echten ECM ja kennt...). Sollte so kein Problem sein, könnte aber zu Problemen mit dem Cache im Cardserver führen
-> bei NDS stecken in den ECMs wohl keine CW-Paare, sondern nur einzelne CWs, Die Zuordnung Even/Odd geschieht über den ECM-Header (80/81), das gerade nicht aktive CW scheint immer genullt zu sein. Daraus ergibt sich eine Art ECM-"Guessing", das erst beim nächsten Durchlauf greift, Außerdem muss ich die Manipulationen durch den Cardserver (Vertausch Even/Odd) für dem Versenden der INs54-Antwort wieder rückgängig machen (sollte aber dank der Nullung des gerade nicht aktiven CWs möglich sein). Was noch zu testen ist: Das Verhalten des ECM/CW-Caches im Cardserver, wenn in der ECM-Anfrage nur konstante SID-Pids und ECM-Pids enthalten sind (das könnte man aber durch nen Patch/Zusatzfunktion im Oscam in den Griff bekommen) Da steckt ein Denkfehler drin, muss nochmal drüber nachdenken...evt. gehts gar nicht...
 
Zuletzt bearbeitet:
AW: Oscam Versuch V13/NDS

@KixKa : Wenn dass kann man wohl nur miteinem orginal Matrix und einem Season Interface testen, wenn das geht liegt es in der grottingen Programmierung des MCA. Aber selbst wenn es 400 ms sind , geht das noch wenn alles ander zusammen mit dem in unter 1 Sec geht.

Das Problem is das ich es bis heute nicht geschafft habe ein accurates, syncrones Timing auf dem MCA hinbekommen habe um das wirklich genau vermessen zu koennen, aber ich habe das selbe Programm (einmal mit MCA und einmal mit ACAMd/ProgDVB) , beide ueber V13 dekodiert auf den selben OSCAM server gefahren, was belegte das das MCA definitiv langsamer ist, da es alle CWs immer aus dem cache bekam.


/Gompf

P.S.: das NDS decoding geht schon, das passt schon...
 
Zuletzt bearbeitet:
AW: Oscam Versuch V13/NDS

@Gompf
oscam server:


Du musst dich Anmelden oder Registrieren um diesen Inhalt sichtbar zu machen!

oscam user:


Du musst dich Anmelden oder Registrieren um diesen Inhalt sichtbar zu machen!

oscam config:


Du musst dich Anmelden oder Registrieren um diesen Inhalt sichtbar zu machen!



cwshare.cfg Diablo kommt mit inden gbox ordner


Du musst dich Anmelden oder Registrieren um diesen Inhalt sichtbar zu machen!

Die Passwörter sind Beispiele


mfg
60plus
 
Zurück
Oben