CI-Unterstützung für CineS2, Mystique SaTiX-S2 Dual usw.

Hi,

ich bin ziemlich eingerostet was die ganze CI Materie angeht, aber vieleicht ergeben sich ein paar Ansatzpunkte um das CI-Interface für alle Tuner gängig zu machen.

Zuerstmal, die eigentliche Entschlüsselung eines verschlüsselten Kanals findet in einer Komponente "Common Descrambler" statt. Und dieser muss nicht zwingend im CI-Modul sitzen, vielmehr besitzt nahezu jeder DVB Chip der letzten 15 Jahre diese Komponente (selbst die alte TT FF oder viele FTA Receiver). Wird der Descrambler mit den richtigen Control Words (even/odd) gefüttert, "entschlüsselt" er den DVB Datenstrom. Die Control Words selbst werden über das CI in Verbindung mit der Karte berechnet. Das CI filtert im Grunde erstmal nur die zur Karte/System passenden Daten aus dem TS und versucht über den Algo des Cryptsystems mit dem angeforderten Key auf der Karte diese Control Words zu berechnen. Um dann damit einen (irgendeinen) im System befindlichen Common Descrambler zu füttern.

Da die (neueren) CineS2 in Verbindung mit dem CI Interface ja Multitransponder Decoding können sollen, nehme ich stark an das auch hier das CI nur die CW's berechnet und diese an einen Common Descrambler auf der CineS2 weiterreicht. Das Reduziert den Datenstrom zum/vom CI erheblich. Vieleicht wäre es auch hilfreich, etwas über den Tellerrand zu schauen und ein hier nicht erlaubtes Plugin anzusehen, um das CI Interface der CineS2 richtig zum laufen zu bringen. Falls jemand einen guten Draht zu den CineS2 Devs hat wäre es auch interessant zu erfahren, ob die Karte (multi) common Descrambler besitzt und diese unter Windows auch genutzt werden.

Andy

Hi,

für Windows scheint es ja mit einem speziellen Treiber zu funktionieren CI4ALL

vielleicht kann man ja so was wie einen DVB Proxy ala VSTB VDR bauen, oder den Ansatz von Reel verfolgen.

ein ander Beispiel unter Windows ist das WinTV CI oder Cinergy CI. siehe auch hier WinTV CI Linux

CU
9000h

Hi UFO

ich wollte nie auf Hacking oder sowas raus....ich sagte ja das ich etwas eingerostet bin;)

Ich war mir allerdings nicht sicher ob in Verbindung mit einem CAM die Entschlüsselung im Descrambler des Cam's oder auf eventuell integrieten der CineS2 stattfindet.

Worauf ich aber hinaus wollte....das von mir angesproche Plugin macht grundsätzlich das gleiche, vieleicht ließe sich hierüber ein Plugin für das CI Interface ableiten.

Andy

Zitat von Andy.2k

Worauf ich aber hinaus wollte....das von mir angesproche Plugin macht grundsätzlich das gleiche, vieleicht ließe sich hierüber ein Plugin für das CI Interface ableiten.

mini73 hat irgendwo im Forum mal auf eine Anfrage geantwortet, warum das so nicht geht. Ich finde den Post einfach nicht. Aus dem Gedächtnis weiß ich noch ungefähr das: Das böse Plugin erzeugt für jeden Tuner ein virtuelles CAM Modul. Der VDR ordnet dann jedem Tuner ein solches zu. D. H., es gibt eine 1:1 Beziehung zw. einem CAM umd einen Tuner. Dieses Konzept ist derzeit im VDR so implementiert, weil bis jetzt alle Karten immer ein CI Interface On-Board hatten und es automatisch benutzt haben.

Die CineS2 und auch die Octupus Karten von DD verfolgen ein anderes Konzept. Das CI Interface ist einfach da und ein CAM das man rein steckt, könnte jeder Tuner benutzen. Sprich die 1:1 Zuordnung ist nicht mehr gegeben. Das kann der VDR so nicht. Deshalb ist auch das Konzept des bösen Plugins nicht als Muster verwendbar.

Ich weiß ja nicht, ob du dir den ganzen Thread durchgelesen hast. Falls nicht, dann lies mal ab hier nach.

Bez. der Probleme mit dem CI Interface für die CineS2 könntest du hier mal zu lesen anfangen und alles was danach kommt.

LG
Jasmin

PS: In der Zwischenzeit habe ich eine Octopus Karte mit Tuner zum CI Testen bekommen. Damit kann der Treiber direkt via FPGA auf das CAM zugreifen und muss nicht den Umweg über i2c und den cxd2099ar nehmen. Damit kann ich dann meinen 2ten CAM Protokoll Patch auch auf einer anderen HW verifizieren und vor allem feststellen, ob mein CAM (siehe Links oben) tatsächlich einen SW Fehler hat.
Aufgrund meines Bandscheibenvorfalls kann ich derzeit kaum sitzen und somit auch nicht daran arbeiten. Sobald es mir besser geht und ich die Stunden für die Firma eingearbeitet habe, werde ich mich wieder damit beschäftigen.

Moin!

Zitat von jasminj

Aufgrund meines Bandscheibenvorfalls

Genesung geht vor! Nimm dir die Zeit, es gibt nichts wichtigeres als Gesundheit, noch nicht mal verschlüsseltes Fernsehen...

In letzter Zeit hatte ich nicht viel Raum, um an ddci weiter zu arbeiten, habe es aber immer noch vor.
Wer auch immer Lust hat, darf sich gerne an meinem git bedienen. Irgendwo mache ich noch einen dummen Fehler, hab den bloß noch nicht gefunden...

Lars.

Zitat von mini73

Irgendwo mache ich noch einen dummen Fehler, hab den bloß noch nicht gefunden...

Das will ich ja finden, allerdings muss zuerst der CI Patch 100% funktionieren und der VDR mit dem CI besser umgehen lernen, was dann als nächstes auf meiner TODO Liste steht.

jasminj

Auch von mir gute Besserung!

Zitat von jasminj

Die CineS2 und auch die Octupus Karten von DD verfolgen ein anderes Konzept. Das CI Interface ist einfach da und ein CAM das man rein steckt, könnte jeder Tuner benutzen. Sprich die 1:1 Zuordnung ist nicht mehr gegeben. Das kann der VDR so nicht. Deshalb ist auch das Konzept des bösen Plugins nicht als Muster verwendbar.

Ich hoffe Klaus ist damit einverstanden, er hat mir auf entsprechende Anfrage mal diese Antwort gegeben:

Zitat von kls

Vom CAM-Handling her ist VDR so ausgelegt, daß jedes CAM mit jedem Device verwendet werden kann. Das jeweilige Plugin muß halt dafür sorgen, daß das auch stattfinden kann, indem es eine von cCiAdapter abgeleitete Klasse implementiert. Im wesentlichen ist hier die Funktion cCiAdapter::Assign() von Bedeutung (siehe ci.h bzw. dvbci.[hc] für die konkrete Implementierung für DVB-Devices).

Ich überlasse es Euch das in den Kontext zu bringen.

Aber ich möchte trotzdem laienhaft nochmal fragen, warum es nicht denkbar wäre die "HW CI" per Plugin "zu virtualisieren", ähnlich wie es die Keksdose eben auch macht ... ?

Klar bliebe dann eine VDR eigene Lösung und nix für den Rest der DVB Welt ...

Regards
fnu

Zitat von fnu

Ich überlasse es Euch das in den Kontext zu bringen.

Da sollte Lars was dazu sagen. Er hat ja das DDCI Plugin geschrieben und dazu einen Patch im VDR benötigt. Scheint also so einfach im VDR nicht zu funktionieren.

Zitat von fnu

Aber ich möchte trotzdem laienhaft nochmal fragen, warum es nicht denkbar wäre die "HW CI" per Plugin "zu virtualisieren", ähnlich wie es die Keksdose eben auch macht ... ?

Wäre vielleicht ein Ansatz, aber Lars hat den sicher aus gutem Grund verworfen. Man müsste dann nämlich alle virtellen CIs so verwalten, dass man eine N:M Beziehung zw. Virt-CI und HW-CI verwalten kann und das noch mal per CAM, weil manche CAMs auch mehrere Streams gleichzeitig dekodieren können. Ich denke das war Lars zu kompliziert und er ist den anderen Weg gegangen. Lars?

Zitat von fnu

Klar bliebe dann eine VDR eigene Lösung und nix für den Rest der DVB Welt ...

Das bleibt es immer, weil es eine Lösung im Userland ist. Wenn man das im Kernel lösen wollen würde, müsste man ja eine einheitliche Schnittstelle zwischen allen Tunern und CI Modulen erfinden und das noch dynamisch machen, je nachdem ob ein Channel verschlüsselt ist oder nicht. Das ist keine Sache die in einen Kernel gehört. Dann würden sich Treiber Entwickler mit noch mehr komplexen Kram befassen müssen, als wir das derzeit tun.

Der Kernel stellt Interfaces für das Userland zur Verfügung und implementiert auch sehr schnell zu machende Dinge. Es sollte normalerweise so viel wie möglich im Userland passieren.
Was man sehr wohl machen kann, wäre eine Library zu erfinden, die alle CIs und Frontends verheiraten kann. Auf das könnten dann alle anderen Programme aufsetzen. Aber das funktioniert in Linux erfahrungsgemäß nicht, weil immer einer g'scheiter, als die anderen sein will und man solch eine Library auch vor den Programmen implementieren müsste. Außerdem müsste man das designen, Interfaces definieren und dann mit den vielen g'scheiten darüber streiten. Es gibt mittlerweile einige LibC implementierungen. Brauch ich mehr zu sagen

Moin!

Es kann sein, dass ich "damals", als ich ddci angefangen habe, das mit den Zuordnungen noch nicht richtig verstanden habe. Ich werde mich bei Gelegenheit noch mal damit auseinandersetzen.
Der erste Schritt ist, das HW-CI durch ein Software-Objekt abzubilden, das mit einem Tuner benutzt werden kann. Wenn das erst mal klappt, kann man an MTD gehen. Da muss man die CAM-Ansteuerung synchronisieren und die TS der einzelnen Tuner zusammenweben. Hauptproblem dabei ist, die PIDs evtl. anzupassen, falls sich da welche überschneiden. Da muss also ein Mapping dazwischen.

Lars.

Hi,

hier ist auch noch ein interessantes Detail in Bezug auf MTD aus den reelcam-0 Sourcen.

#define ALPHA_MAX 3
#define ALPHATC_MAX 2
#define VIACCESS_MAX 1
#define DIABLO_MAX 2
#define NAGRA_MAX 4
#define ASTON_DUAL_MAX 2
#define CANALDIGITAAL_MAX 4
#define POWERCAM_MAX 4

CU
9000h

... fuer eure arbeit und das zusammentragen aller infos zu ddbridge, redirect, Adapter_alloc usw.

Nachdem mein budget_ci an der tt3200 nach kurzem zappen auf sky immer wieder abgestuerzt ist, habe ich letzte woche mal wieder mein ci fuer die CINES2 V6 aus dem Schrank geholt.

Nachdem ich diesen Thread nun seit eineiger Zeit mit Aufmerksamkeit verfolge, dachte ich das sein nun mal der geeignete Augenblick.
Was soll ich sagen, laeuft 99% stabil mit media-build-experimental unter 0.5. Hab mir dann gleich noch eine Tunererweiterung gekauft und arbeite nun mit 4*S2 Tunern und Inverto UniCable

nur ab und an kommt die meldung

dvb_ca adapter 0: DVB CAM link initialisation failed :(

beim vdr start.

Ich bin gleich auf den Testing Zweig in de 0.5 gegangen, da ich dann schon den VDR 2 Nutzen kann

Jetzt die Preisfrage: Bei testing hat sich ddci mit eingeschlichen. Wird da gerade wieder aktiv dran gearbeitet ? Waere cool, erklaere mich auch gerne bereit als tester zu fungieren

Meine Settings fuer Unicable kann ich gerne Posten wenn interesse besteht.

Kuemmere mich jetzt mak widr um die Sporadischen Frontendprobleme beim Start ( ab und zu keine Ton )

Schoenes Wochenende,

Karsten

Zitat von bottkars

nur ab und an kommt die meldung

Code

dvb_ca adapter 0: DVB CAM link initialisation failed :(

beim vdr start.

Hast du dir den Post auch schon durchgelesen?
Da habe ich beschrieben, wie man mit "cam_debug=1" das Logging des Treibers einschalten kann. Ev. hilft dir das den Fehler weiter einzugrenzen. Ist wahrscheinlich dasselbe wie bei mir und liegt am cxd2099 Treiber in der 0.8er Version des Treibers, der im media-build-experimental dabei ist.

Meine 2te Test HW wurde von meinem Sohn wieder zurück gefordert und ich habe noch keinen neuen PC zusammen geschnorrt. Ralph hat mir schon eine Treiberversion geschickt, die den Buffer Modus des Chips aktiviert. Leider nicht auf der Version 0.8 von UFO basierend, sondern auf seiner originalen 0.8er Version, die noch nicht dem Kernel Coding Style entspricht. Somit die Änderungen zu finden mühsam ist und ich alles was UFO schon einmal umformatiert hat, nochmals umformatieren müsste. Zusammen mit meinem Bandscheibenvorfall vergeht mir da schön langsam die Lust ... .

Ich kann dir nur sagen, dass trotz des Buffer Modus es ab und zu Probleme gab. Allerdings hatte die der VDR gemacht und nicht der Treiber, wenn ich mich richtig erinnere. Das ganze hängt auch sehr vom verwendeten CAM ab. Mein uralt CAM braucht meinen Patch oder den Buffer Mode des cxd2099, damit es überhaupt funktioniert.
Mein neues CAM geht auch ohne Patch, allerdings weiß ich nicht mehr wie gut.

Wenn dich der Fehler nervt, dann schalte das Logging ein und bau bei Bedarf ein paar zusätzliche Testausgaben dazu. Ach ja, der Treiber ist dann sehr gesprächig. Du wirst ein paar Loggings auskommentieren müssen um das Problem besser zu sehen.

Zitat von bottkars

Jetzt die Preisfrage: Bei testing hat sich ddci mit eingeschlichen. Wird da gerade wieder aktiv dran gearbeitet ?

Ich bin derzeit mangels 2ter HW leider nicht dran. Aber wenn Lars wieder was tut, würde mich das auch interessieren.

LG
Jasmin

Zitat von jasminj

Ich kann dir nur sagen, dass trotz des Buffer Modus es ab und zu Probleme gab. Allerdings hatte die der VDR gemacht und nicht der Treiber, wenn ich mich richtig erinnere. Das ganze hängt auch sehr vom verwendeten CAM ab. Mein uralt CAM braucht meinen Patch oder den Buffer Mode des cxd2099, damit es überhaupt funktioniert.
Mein neues CAM geht auch ohne Patch, allerdings weiß ich nicht mehr wie gut.

Jasmin, gesundheit geht vor. ich habe / hatte das auch Chronisch, bei mir hilft da nur geistige Arbeit runterfahren und körperliche Arbeit ( sport ) hoch.
Aber Bandscheibe ist nicht gleich Bandscheibe. Auf jeden Fall Gute Besserung.

Meien CAM Probleme sind dagegen Luxusprobleme, zwischen Filterteichbau, Arbeit und dem Bestreben den VDR Anwendergerecht zu halten . . .

Ich hatte auch schon mit der TT3200 und dem Budget CI die diversen Probleme und hatte gehofft das jetzt in den Griff zu bekommen.

Ich galube also das Problem ist evtl. eine Kombination CAM mit jeweiligem CI und VDR Handling.

Ich hatte gaaanz frueher mal einenVDR mit FF Karten, dort traten die Probleme nicht so haeufig auf. Aber was hatten wir zu dieser Zeit fuer Rechner ... ist Jahre her.

Daher vermute das es schlichtweg ein Timingproblem des VDR ist. Vielleicht muss Klaus doch noch mal an die Baustelle CI ran.

Ich werde das mit dem DEBUG mal machen, wenn nicht zu viele recordings anstehen

Ich Nutze uebrigens auch ein altes Alphacrypt Modul mit S02 karte.

Ohne jetzt grossartig ein shellscript zu schreiben habe ich gestern abend mal zwischen Filterteich Einschlämmen und Pizzateig ausrollen einen Test gefahren der beim Hochfahren im Ringbuffer nachschaut ob die initialisierung fehlgeschlagen hat.
Dazu nutze ich folgenden Workaround:

root@yavdr5:~# more camreset.sh 
#!/bin/sh


#### react on dvb_ca adapter 0: DVB CAM link initialisation failed :(
#### Test fuer einen CAMRESET




if (dmesg -c | grep "dvb_ca adapter 0: DVB CAM link initialisation failed :(" ) 
then echo "CAM Failed, trying to reset"
svdrpsend hitk setup
svdrpsend hitk 5
svdrpsend hitk green
svdrpsend hitk menu
svdrpsend hitk back
svdrpsend hitk back
svdrpsend hitk back
svdrpsend hitk back
else echo "CAM seems to work"
fi

Quick and very dirty, ich loesche dabei den Ringbuffer, weil ich derzeit nicht checken will wie aktuell der Fehler ist :-), und bei einem weiteren Fehlversuch das ganze wieder mache.
Bei mir habe ich das in einer While schleife, da es manchmal 3 Versuche beoetigt hat, das CAM zu resetten.

Dummerweise laeuft es imm Moment sauber, Anscheinend ist das ein fehler der Bevorzugt am Wochenende auftritt oder zur PrimeTime

Wie Sieht eigentlich das CAM aus wenn wir mehrere CI's haben ? woher weiss ich vom Treiber, welches CAM nit initialisiert wurde ???
Fuer meinen Hausgebrauch reicht es derzeit, da ich wie gesgat den Ringbuffer lösche kann ich im Hardcorefall auch per CRON testen, ob das cam sich im laufenden Betriebverabschiedet hat.
Glücklicherweise hat es das aber heute Nacht nicht waehrend 3 Aufnahmen von SKY HD liefen.

Da gibt es bestimmt elegantere moeglichkeiten uber rsyslog Module, aber es ist ja erstmal nur fuer meinen Test. Denn neben all der Testerei wollen doch ein Paar Aufnahmen gemacht werden ( Habe leider nur auch nur einen Rechner mit CINES2, CAM und S02, und der Nimmt jeeede Menge Serien und Filme auf SKY auf ..., Vielflieger
Dabei ist mir leider wieder aufgefallen, das wir wohl immer noch keine moeglichkeit haben das CAM direct uebber eine svdrp oder REST befehl Anzusprechen ?
Daher hangel ich mich durch die Menüfolge

Wenn ich zeit habe, werde ich diesen Workaround mal versuchen sauber in ein script zu gießen, aber Warnung, berufsbedingt mache ich derzeit 100% Powershell, da gewoehnt man sich ein paar ganz andere Sachen an ...

Ich werde uch mal in meinem Alten Rechner das CAM Modul mit der TT3200 testen, da ja dort auch Ähnliche Probleme aufgetreten sind, kann ich da nochmal nchvollziehen, ob der reset hilft

Derzeit habe ich das als upstart script in /etc/init/camreset.conf geparkt:

author "Karsten Bott"
description "Check CAM Module on startup"


start on started vdr
stop on stopped vdr




script


while (dmesg -c | grep "dvb_ca adapter 0: DVB CAM link initialisation failed :(" ) 
do 
echo "CAM Failed"
svdrpsend hitk setup
svdrpsend hitk 5
svdrpsend hitk green
svdrpsend hitk menu
svdrpsend hitk back
svdrpsend hitk back
svdrpsend hitk back
svdrpsend hitk back
sleep 20
done
end script

Wie gesagt nicht schoen, aber es hilft wenn meine Bessere halfte abends den VDR started und SKY nicht will .....

Werde demnaechst mal sowas als background Prozess starten und wenn moeglich ohen den Ringbuffer zu löschen.

Timestams erscheinen mir aber schwierieg da diese wohl nach suspend / resume falsch sein können....

Zitat von mini73

sudo echo "02 02" > /sys/class/ddbridge/ddbridge0/redirect
sudo echo "03 03" > /sys/class/ddbridge/ddbridge0/redirect

Wie kann ich denn die beiden Anweisungen jedes Mal beim Systemstart ausführen lassen?

In Thread steht das ja schon.
Guckst du hier und hier.
Das mit den UDEV Regeln hab ich auf die Schnelle nicht gefunden. Das Programm wird dann von einer UDEV Regel gestartet. Kann dir meine UDEV Datei aber nicht schicken, weil ich auf den Philippinen auf Urlaub bin.

Hallo,

ich verfolge dieses Thema auch son einige Zeit und auch mir gehen die gelegentlichen Abstürze des CI der TT S 3200 auf die Nerven. Ich habe ebenfalls noch ein CI für die DD 6.0 hier rumliegen. Was muß ich machen um dieses Lauffähig zu machen ohne meinen Rechner (ist der Server) zu verschmlimmbessern und später mit meiner Regierung ärger zu bekommen, weil VL nicht mehr aufgenommen wird...

Viele Grüße

Rainer

Hab eben mal das CI eingebaut.

Es kommt die Meldung: dvb_ca adapter 2: DVB CAM detected and initialised successfully

aber im Menü des VDR wird das CAM nicht angezeigt.

Was muß ich noch einstellen?

Vielen Dank.

Rainer