[ddci2] Patch um CAMs dynamisch mit jedem Device verwenden zu können

    Hi!


    Ich war ja lange weg vom VDR und auch fast 2 Monate auf den Philippinen auf Urlaub.
    Ich hatte im Urlaub Kontakt zu 3PO und Klaus bez. SatIP und ddci2 Plugin, konnte aber nichts machen, da zu schlechtes iNet.


    Ich hab dann nach meiner Rückkehr meinen VDR auf die neue yaVDR 0.6.0 Distribution aufgerüstet, damit ich am ddci2 Plugin weiter basteln kann.


    Vor ein paar Tagen hat mich ein User wg. dem CI Plugin angesprochen und seit damals werkle ich an dem Ding wieder.
    Ich habe von diesem Thread nichts gewusst, weil ich nicht so viel im Forum bin.


    Na wie auch immer, ich habe unabhängig von diesem Patch eine fast identische Lösung gebaut. Die macht nur jetzt alles richtig im Assign und loggt auch was da passiert (Debug Logging).


    Ihr findet die Version 0.0.14 im git.


    Quote from kls

    Mir gefällt der Ansatz auch insofern nicht so ganz, weil da für jedes Device ein (virtueller) cCiCamSlot angelegt wird. Das hat zur Folge, daß z.B. im Setup/CAM-Menü alle diese CAMs separat auftauchen, und VDR bei der Suche nach einem geeigneten CAM um einen Kanal zu entschlüsseln diese alle durchprobiert, obwohl es letztlich immer die gleiche Smartcard ist und ein Versuch reichen würde.

    Das ging anno dazumal, als ich das Plugin geschrieben habe, nicht anders, ob der internen Struktur im VDR und seit damals schläft die Sache. Ist erst mit VDR 2.1.7 ermöglicht worden (da hab ich einen Patch an Klaus gesendet), hatte aber dann keine Zeit und auch keinen 2ten VDR, um mich damit zu beschäftigt :O


    Quote from kls

    Mir schwebt da eher sowas vor:


    - für jedes physikalische Interface gibt es einen cCiAdapter
    - für jedes physikalische CAM gibt es einen cCiCamSlot
    - wenn ein cCiCamSlot MTD kann, dann legt er zur Laufzeit in cCiCamSlot::Assign() einen virtuellen cCiCamSlot an, der die eigentliche Arbeit übernimmt
    - im Setup/CAM-Menü erscheinen nur die physikalischen CAMs (bzw. cCiCamSlots)

    Das klingt sehr gut und sollte sich auch nur im Plugin so bauen lassen. Bin nur nicht sicher, ob die VDR Basisklassen das so zulassen. Das sieht man aber erst bei der Implementierung, ob man da was im VDR ändern muss.


    Quote from kls

    Ich kann mir eigentlich nicht vorstellen, daß es dazu Änderungen auf Treiberseite bedarf, denn der Datenfluß zu und vom CAM funktioniert ja bereits.

    Nein, im Treiber muss man nichts machen. Da gehört es auch nicht hin, weil das dem Konzept "Treiber macht nur LowLevel/Userspace macht Logik" zuwieder laufen würde. Man könnte aber eine Library machen, die dann von anderen Programmen und ddci2 verwendet werden kann. Das aber ist viel Aufwand und der VDR selbst macht schon sehr viel, was in so einer Library sein würde.


    LG,
    Jasmin

    Edited once, last by jasminj ().

    Quote from jasminj

    Das klingt sehr gut und sollte sich auch nur im Plugin so bauen lassen. Bin nur nicht sicher, ob die VDR Basisklassen das so zulassen. Das sieht man aber erst bei der Implementierung, ob man da was im VDR ändern muss.

    Update: Klaus ist dabei das MTD nun doch in den VDR einzubauen. Das Plugin macht dann nur die Anbindung an die DD Hardware über die Kernel Schnittstelle. Er sagte es wären zu viele Änderungen im VDR notwendig gewesen und dann hat er es lieber gleich dort eingebaut.


    Er hat auch einen Bug im ddci2 Plugin gefunden, der sich nur bei MTD auswirkt.
    Die neue Version 0.0.15 findet ihr im git.

    Kurze Zwischenfrage, lässt sich das Plugin auch für eine OctopusNet S2 MAX nutzen? Das darin verbaute CI dürfte ja das Gleiche sein, wie das externe PCIe Modell...

    Hi!


    Das Plugin ist für den VDR und nur für diesen tut es irgend etwas.
    Läuft auf deiner OctopusNet S2 MAX ein VDR?


    LG,
    Jasmin


    PS: Die original SW der Octopus Net findet man hier.

    sicher, so wie es jetzt implementiert ist das Plugin für den VDR.


    Ihr legt aber immer einen so großen Wert darauf, dass das CI ein eigenes Stück HW ist und man sich von dem Gedanken lösen muss das es einer DVB Karte fix zuzuordnen ist. Ok, das der MTD Support nicht in den Treiber gehört wurde ja hinreichend diskutiert, aber wäre es hier nicht konsequent das Ganze trotzdem separat, bspw in einem Daemon mit einer API hinzustellen damit auch andere Programme, zB vdr, minisatip, konkurrierend zugreifen können.


    Oder verkompliziert dies das Unterfangen zu sehr?


    Christian

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    CKthree: yavdr-ansible/22.04 LTS/2.6.1/kodi19.3 auf Intel NUC, Celeron J4005, UHD Graphics 600, 4GB Crucial DDR4, Ocz Vertex2 50 GB, Harmony 350

    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5



    Es geht ja nicht nur darum, dass das CI mit den DVB-Daten gefüttert werden muss, es muss ja nebenbei auch noch ein paar Steuerbefehle bekommen. Deshalb kann es nicht so ohne weiteres extern betrieben werden.


    Und wenn, dann müsste man wieder ein neues vdr-Plugin schreiben, welches dann den "ddcidaemon" benutzt. Da hat man also nichts gewonnen. Es muss halt ein "DVB-Master-Programm" geben, welches die DVB-Daten fertig für die nutzenden Programme abliefert. Und das kann der vdr genauso gut erledigen.


    Lars.

    Ich habe es, um den Aufwand minimal zu halten und möglichst wenig Code zu duplizieren, jetzt einfach mal an strategischen Stellen im VDR eingebaut. Das ddci2-Plugin braucht nur einige wenige zusätzliche Aufrufe zu machen, um MTD zu nutzen. Es wäre auf diese Weise auch leicht möglich, Plugins für andere CI-Adapter zu schreiben, die MTD können, denn um die eigentlichen Probleme kümmert sich VDR.
    Freilich steht es jedem frei, alles was für MTD notwendig ist aus dem VDR-Code zu nehmen und eine entsprechende Lib zu schreiben. Die Hauptarbeit war ja erstmal herauszufinden, an welchen Stellen die PIDs, SIDs und CATs angepasst werden müssen, damit das funktioniert, und die Datenströme geeignet zusammen- und wieder auseinanderzuführen. Dieses Wissen steht dann allgemein zur Verfügung und kann beliebig weitergenutzt werden (the beauty of open source ;-).


    Konkret: das Entschlüsseln von mehreren Kanälen von unterschiedlichen Transpondern habe ich bereits hinbekommen. Momentan arbeite ich noch daran, den Gesamtablauf sauber hinzubekommen (zur Zeit läuft es noch unter recht "kontrollierten Bedingungen" ;-). Sobald alles stabil läuft gibt's die Version 2.3.3 ;-).


    Klaus

    Quote from CKone

    Ihr legt aber immer einen so großen Wert darauf, dass das CI ein eigenes Stück HW ist und man sich von dem Gedanken lösen muss das es einer DVB Karte fix zuzuordnen ist.

    Mit Verlaub, das ist wirklich genial und man kann damit auch Tuner von anderen Herstellern benutzen (weiter verwenden) und dennoch verschlüsselte Programme schauen.


    Quote from CKone

    ... aber wäre es hier nicht konsequent das Ganze trotzdem separat, bspw in einem Daemon mit einer API hinzustellen damit auch andere Programme, zB vdr, minisatip, konkurrierend zugreifen können.

    So etwas ähnliches hatte ich mal vor, aber ich habe es dann gelassen, weil der VDR das ganze CAM Handling bereits implementiert hatte. Man hätte im Grunde ein neues CAM API erfinden müssen und alle Programme hätten ihren CAM Code darauf anpassen müssen. Und konkurrierend über mehrere Programme hinweg ..., na viel Spaß. Da würde man viel in den Programme umbauen (ersetzen/löschen) müssen.


    Quote from CKone

    Oder verkompliziert dies das Unterfangen zu sehr?

    Ja!


    Es ist halt so, dass jedes Programm das selbst implementieren muss. Und auf lange Sicht kann es gut sein, dass CI Module nicht mehr verfügbar sind, oder durch den CI+ Schmarrn ersetzt werden. Es gibt da zwar alternativen, aber ... . Also lohnt sich der Aufwand jetzt nicht mehr.


    LG,
    Jasmin

    Hallo,


    funktioniert die aktuelle Version (0.0.15) noch mit VDR 2.2?


    Weil ich habe eine Octopus mini V2 + DuoFlex S2 + Duoflex CI + FlexCI
    Mit der alten Version vom ddci2 zeigt VDR alle CI Slots an, mit der neuen nur noch das erste.


    Muss man noch irgendwas einstellen?



    Gruß Karl



    Edit: Mit dem Patch von Klaus, funktioniert es wie es soll

    Quote from nanohcv

    funktioniert die aktuelle Version (0.0.15) noch mit VDR 2.2?

    Ja, sollte es, nur ...


    Quote from nanohcv

    Mit der alten Version vom ddci2 zeigt VDR alle CI Slots an, mit der neuen nur noch das erste.

    ... da hat die Jasmin anscheinend was vermurkst, weil sie mal wieder nur auf dem VDR mit einem CI getestet hat. Der andere VDR zeigt mir das gleiche Verhalten wie bei dir:

    Scheint so, als ob ich das was in der Initialisierungschleife vergessen habe, weil es da wird auch "/dev/dvb/adapter3/ci0" vergessen.
    Ich schau mir das gleich an.


    Quote from nanohcv

    Edit: Mit dem Patch von Klaus, funktioniert es wie es soll

    Klaus hat im Grunde nur ein "return true" bool in die Assign Funktion gemacht. Ich hab aber auch an der Initialisierung gedreht.

    Eine neue Version 0.0.16 ist im git.


    Wem interessiert was es war (klick:(
    In Version 0.0.14 hat das Plugin nur so viele logische CAMs für den VDR angelegt, wie Devices gefunden wurden. Jetzt ist aber die Anzahl der Devices nicht unbedingt gleich der Anzahl der vorhandenen CI Slots. Deshalb habe ich das geändert.
    Dummerweise habe ich die Schleife über alle Devices ersatzlos gestrichen, weshalb nur immer der erste CI Slot initialisiert wurde.


    LG,
    Jasmin

    Grunsätzlich funktionieren tut es,



    leider aber bekomme ich beim Beenden des VDR einen segfault:


    Code
    ....
Mar 11 21:14:28 [vdr] [10157] deleting plugin: softhddevice
Mar 11 21:14:28 [root] Focus: 1
Mar 11 21:14:28 [vdr] [10157] deleting plugin: ddci2
Mar 11 21:14:28 [G2V gg_switchhook.sh] /_config/bin/gg_switchhook.sh -switch ActWin <(1058, 1888) 0(Gg_launcher)>
Mar 11 21:14:28 [kernel] DDCI adapter /d[10214]: segfault at 7f6fbb77bb82 ip 00007f6fbb77bb82 sp 00007f6fa1469630 error 14 in ISO8859-9.so[7f6fbb981000+2000]
Mar 11 21:14:30 [root] Focus: (1058, 1888) 0(Gg_launcher) - 11104
Mar 11 21:14:31 [su] pam_unix(su:session): session closed for user root
...

    Eine neue Version 0.0.17 ist im git.


    Der Code von 0.0.14 hatte eine "for" Schleife, die einen Variable automatisch hochgezählt hat.
    Beim Umbau auf eine "while" Schleife (0.0.16), hab ich das Hochzählen vergessen. :wand


    Jetzt sollte aber wirklich alles wieder funktionieren. :O

    Quote from jasminj

    [...] Jetzt sollte aber wirklich alles wieder funktionieren. :O


    Ja, jetzt lässt sich der VDR wieder sauber beenden. :thumbup:


    Das gehört vlt. nicht unbedingt hierher, aber kann mir Jemand die Syntax für das "Redirecten" erklären?


    Ich versuche gerade mit meinem Test-SATIP-Server mit einer Cine S2 + DuoFlex C/T + FlexCI, das CAM mit der Flex C/T zu "pipen", aber leider verstehe ich diese Anleitung nicht.


    Das Setup sieht so aus:


    dmesg


    /dev/dvb


    Wie müssen denn die Werte für A, B, C, D sein, wenn ich "frontend2", dem "ca0" zuordnen will?


    echo "AB CD" > /sys/class/ddbridge/ddbridge0/redirect

    Vielleicht 02 02? Welche Kombinationen hast du schon ausprobiert? Ich meine, dass man den redirect vor dem ersten Zugriff setzen muss, also vdr stoppen, Treiber neu laden, redirect setzen, vdr starten.


    Aber das sollte mit ddci2 ja eigentlich nicht mehr nötig sein.


    Lars

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login