[Patch] CAM-Tweaks für Multi Channel Decryption

  • Es tut sich (et)was. Beim Einschieben des Moduls nach Start von vdr erhalte ich nun die Authentifizierungsmeldungen:

    Es kommen zwar kurz wieder die DDCI2 Fehlermeldungen, aber dann ist erstmal Ruhe. Beim Tunen auf einen privaten Kanal erscheint nun folgendes im Log:

    Code
    1. Feb 1 21:07:36 kodi-mc vdr: [1083] CAM 1: Enquiry ------------------
    2. Feb 1 21:07:36 kodi-mc vdr: [1083] CAM 1: 'Bitte geben Sie Ihre Jugendschutz-PIN ein.'

    So war es auch beim TV. Danach wurde es hell. Nur wie bekomme ich die PIN da jetzt rein?

    Ich dachte mit der DD Hard- und Software würde diese Abfrage umgangen.


    Update: Ich konnte jetzt über kodi->PVR & TV in das VDR OSD und dort im CAM Menü die Jugendschutz-Pin eingeben. ET voila :) :) :) Der Sender wurde hell!


    Leider muss ich das jetzt nach jedem Umschaltvorgang wiederholen. Hab schon versucht, die camresponses.conf zu bearbeiten, aber das hat nicht funktioniert.


    Noch ein Update: Heureka, es läuft. :) :) :) :) :) Ich hab die camresponses.conf nochmal bearbeitet und die PIN wird jetzt automatisch im Hintergrund eingegeben. Bild wird dann nach kurzer Verzögerung hell. Der Delay mach schon ein paar Sekunden aus, aber damit kann man (auch frau) leben.


    Ich vermute, der Tipp von HelmutB war hier entscheidend, so dass mit dem Einschieben der Karte nach vdr-Start der Authentifizierungsprozess re-initialisiert wurde. Auf jeden Fall liegt jetzt im Verzeichnis /var/cache/vdr/plugins/ciplus eine auth-Datei. Auch mit dem Patch und aktivierten camtweaks läuft es nun endlich.


    Danke für Eure schnelle Unterstützung und Tipps, die letztlich zur Lösung geführt haben.

  • /var/lib/vdr# cat camresponses.conf

    # 3 "Please enter your PIN" 1234

    root@roadrunner:/var/lib/vdr# cat camresponses.conf

    # Format:

    # nr: the number of the CAM this action applies to (0 = all CAMs)

    # text: the text in the CAM menu to react on (must be quoted with '"' if it contains

    # blanks, escape '"' with '\')

    # action: the action to take if the given text is encountered

    1 "Bitte geben Sie Ihre Jugendschutz-PIN ein." <PIN>


  • Die I/O Fehler sind zwar seltsam und sollte es nicht geben, und im VDR ist eigentlich eine Funktion, mit der die Abfrage der Jugendschutz-Pin erst gar nicht auftauchen sollte. Aber schön, dass es läuft - wenn auch nicht ganz astrein.

    Helmut

  • Die Abfrage der Jugenschutzpin kommt beim NDS Modul wie mir scheint, sobald irgendwas nicht funktioniert.


    Habe (teilweise) den gleichen Effekt mit dem EPG-Update (durch epg2vdr), was mir beim Update der lokalen EPG-Bilder nebst Symlinks (um 4800 Stück) meist das Modul abschießt, aber gelegentlich die Pin-Abfrage triggert:



    Offenbar ist das CAM I/O-zeitkritisch...

    Kommt sofort zurück, sobald die Bremse gelöst ist.

    Allerdings ist das in Aufnahmen eher ungünstig... VDSB -> exit.

    Geht's schnell, "überlebt" es


    Code
    1. Jan 30 17:23:54 vdr: epg2vdr: --- EPG 'update' started ---
    2. Jan 30 17:23:55 vdr: epg2vdr: Starting cleanup of images in '/var/cache/vdr/epgimages'Jan 30 17:24:39 vdr: epg2vdr: Remove old symlinks
    3. Jan 30 17:24:42 vdr: epg2vdr: Cleanup finished, removed (103) images and (283) symlinks


    Hier mal mit Pin-Abfrage:


    Kann also auch ein Firmware-Problem (oder Absicht) des Moduls sein:
    "Wenn ich kein Bild hinbekomme, frag ich mal nach der Pin..." :-)


    Das System liegt auf auf einer ext4 Disk. Außerhalb des VDR kann man treiben, was man will, da brennt nix an. Nur wenn epg2vdr losläuft, war's das meist. :-]


    42.

  • Grumpy ,


    da fällt mir gerade noch ein, als ich mit dem Sky-Modul angefangen habe, hatte ich auch Probleme mit der Erkennung.

    Ich habe dann festgestellt, das es nicht in allen PCIe Steckplätzen problemlos läuft. Ich habe dann die Steckplätze so lange durchgetestet, bis meine 3 Karten (2 x TV und 1 x CI) ohne Probleme liefen. Selbst jetzt, nach meinem Update auf Ryzen, läuft es nur stabil, wenn ich keinen Steckplatz benutze, der direkt an der CPU angeschlossen ist.

    Vielleicht hast Du ja die Möglichkeit, mal einen anderen Steckplatz auszuprobieren.


    Grüße

    kamel5

    VDR 2.6.1: ASUS Prime X470-PRO, Ryzen 7 2700, 64GB, 6TB HD, GT1030, Fedora 35 Kernel 5.16 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Zur Jugendschutz-PIN kann ich noch folgendes ergänzen. Die PIN-Abfrage basiert ausschließlich auf der EIT (EPG) im MPEG-Transportstrom. Fehlt die EIT im Stream, kommt die PIN-Abfrage bei jedem Senderwechsel. Ist die EIT mit Jugendschutzinformationen vorhanden, kommt die PIN-Abfrage nur bei Sendungen mit der Altersfreigabe ab 16 oder 18.

    Um die PIN-Abfrage zu umgehen leitet VDR nicht die originale EIT zum Modul sondern nach jedem Senderwechsel für eine kurze Zeit ein Grundgerüst (ohne Jugendschutzinformationen) einer EIT zum Modul. Damit wird dem CAM vorgegaukelt, dass die Sendung für alle Altersklassen freigegeben ist und eine PIN-Abfrage nicht erforderlich ist.


    Verwendet man aber Plugins wie VNSI oder Streamdev gibt es ein Problem, denn diese Plugins müssen ja den Stream von einem Device abrufen. Das tun diese Plugins unter anderem in ihren Ableitungen der cReceiver Klasse. In der cReceiver Klasse gibt man an anhand der PIDs an, welche Daten man aus dem Stream abrufen möchte. Das Problem an der Sache ist, dass alles was dort angegeben wird auch beim CAM landet und da diese Plugins i.d.R alle PIDs eines Kanals, also auch die PID 18 der EIT, dort abrufen, kann es wieder zur PIN-Abfrage kommen, denn jetzt bekommt das CAM einmal die Fake-EIT vom VDR und einmal die originale aus dem MPEG-Stream. Und da die Fake-EIT vom VDR nur kurz injected wird, kommt es zumindest bei Sendungen mit Altersfreigabe wieder zur PIN-Abfrage.


    D.h. entweder man lebt mit dem Workaround mit der camresponses.conf und hat längere Umschaltzeiten oder jemand erbarmt sich und passt das VNSI-Plugin an und verhindert dort, dass die PID 18 in der cReceiver Klasse abgerufen wird. Auswirkungen sollte es vermutlich keine haben, da das VNSI-Plugin das EPG nicht selbst aus dem MPEG-Stream extrahiert sondern dafür die VDR-API nutzt.

  • kamel5 , ich hab leider die Herausforderung, dass ich zwar ein uATX Board (Asus B250M-C) mit mehreren PCI Slots habe, dies aber in einem sehr flachen Streacom FC5 Alpha Gehäuse mit nur einem (horizontalen) Slot für PCI-Karten betreibe. D.h. die aktuell verwendete Riser-Card läßt da keine Auswahl, in welchen Steckplatz am Board sie gesteckt wird. Man könnte evtl. eine flexible Riser-Card nehmen. Das müsste ich mal ausprobieren.


    Aktuell läuft die Erkennung aber aus meiner Sicht relativ stabil. Ich hab gestern auch ca. 2h eine Aufnahme auf einem privaten Kanal gemacht, die problemlos durchlief. Ich kann auch nicht ausschließen, dass ich das NDS Modul bei meinen ersten Versuchen nicht sauber im CI Schacht eingesteckt hatte. Dies könnte ein weiterer Effekt des Ziehens und erneut Einstecken gewesen sein, so dass das Modul dann endlich sauber saß.


    Das Wechseln auf einen privaten Sender läuft bei mir so, dass es zunächst ein paar Sekunden schwarz bleibt, dann kommt vom VDR VNSI Client die Meldung "Channel: no data" und unmittelbar danach wird es hell. Das kann man auch im Log ganz gut nachvollziehen; nach dem VNSI Error (VNSI-Error: cParser::AddPESPacket - max buffer size reached) kommt nach 9-10 Sekunden die PIN Abfrage und danach geht es weiter:

    Ich bin zwar mit den 9-10 Sekunden Verzug bis das Bild hell wird nicht mega-happy, freu mich aber, dass es nun endlich funktioniert.


    Vielleicht sieht der ein oder andere ja noch eine Möglichkeit zur Optimierung oder weiß, woher der VNSI-Error stammt und wie man ihn ggfs. vermeidet. Kürzere Umschaltzeiten wären natürlich der "Hit".


    FernetMenta, der Maintainer des VNSI-Server-Plugins und entprechenden Kodi PVR VNSI Addons scheint ja leider nicht mehr an diesem Projekt zu arbeiten (was ich sehr bedaure), so dass man ihn nicht mehr direkt ansprechen kann.


    P.S.: Hatte bei der Arbeit an meinem Post die Antwort von nanohcv übersehen. Der Zusammenhang mit VNSI ist damit wohl erklärt.

  • Im Moment läuft bei mir eine Aufnahme auf einem privaten Kanal im Hintergrund während ich durch andere private Kanäle am TV zappe. Jetzt ist plötzlich kaum noch ein Verzug zwischen Umschalten und hell werden festzustellen und ich sehe auch keine "auto responses" mehr auf PIN Anfragen... merkwürdig.


    Ich hatte vorher mal testweise mit der VNSI Server Einstellung

    Code
    1. vnsiserver.DisableScrambleTimeout = 0

    rumgespielt, aber ohne VDR neu zu starten, da ja noch die Aufnahme läuft. Werde ich später nochmal etwas systematischer testen, ob sich dadurch noch etwas optimieren lässt oder ob es gerade nur "zufällig" besser läuft.


    Update: Auch nach einem VDR-Neustart, geht das Zappen nun flüssiger und im Log erscheint aktuell keine PIN Abfrage mehr nach dem Umschalten. Zufall oder die Änderung der vnsiserver Einstellung hat hier tatsächlich eine Verbesserung bewirkt (Aktueller Wert ist 0; bin mir nicht sicher, was hier die Default-Einstellung ist)

  • Hallo zusammen,


    leider kommt es ja bisweilen vor, daß die Entschlüsselung eines aufzunehmenden Programms nicht sofort gelingt. Insbesondere direkt nach Kanalwechsel bei bereits laufender Entschlüsselung.


    Das versaut dann durch Video Datastream Broken und Restart gleich alle laufenden Aufnahmen. Blöd.


    Nun gelingt es eigentlich immer, durch Um- und Zurückschalten die Entschlüsselung doch noch zu starten.


    Könnte man nicht - wenn keine Daten kommen, den "Emergency Exit" auf "Retune" umbiegen?

    Macht der VDR ja auch selbst, wenn sich die Kanaldaten ändern.


    42

  • Ich vermute stark, dass die CA_PMT nicht oder nur unvollständig an das CAM gesendet werden kann, weil der Zugriff auf das ca0 Device gestört ist. Damit würden auch die Informationen für die laufende Aufnahme im Modul verloren gehen und diese nicht mehr entschlüsselt werden, wass zum emergency exit führt.

    Das könnte z.B. mit epg2vdr zu tun haben. in deinem Post #127 sieht man, dass irgendwann die Komunikation mit dem Modul nicht mehr möglich ist und immer wieder ein CAM-Reset durchgeführt wird.


    ALs erstes kannst dur in camweaks.conf die Option 0x800 (DESELECT) weglassen. Diese ist nicht notwendig (sollte zwar auch nicht stören, aber wer weiß).

    Wenn sich damit nichts ändert, überprüfe ob diese Umschaltprobleme auch ohne epg2vdr auftreten.

    Helmut

  • Also... wir haben bspw. drei Timer (über das CAM):

    A auf C1, z.B. von 10:00 - 12:00

    B auf C2, z.B. von xx:xx - 11:00

    C auf C3, z.B. von 11:00 - xx:xx


    Timer A läuft ungestört, B ebenso, C "meist".

    Falls C (nach Umschalten von C2 auf C3) keine Daten liefert, ist A davon nicht betroffen (entschlüsselt weiter), wird aber natürlich durch den VDR Neustart mit "unterbrochen". Was natürlich nicht (unbedingt) bedeutet, daß die CAM-Kommunikation funktioniert hat.


    Das CAM-Reset durch das EPG-Update des epg2vdr Plugins habe ich (erstmal) in dessen update.c mit

    behoben.


    Das bremst das Update der ca. 5000 Links/Bilder von ca. 3 auf 50 Minuten; wird später optimiert. Das CAM hat seitdem keine Reset-Probleme mehr.


    Kann das aber gerne nochmal ohne epg2vdr probieren.


    42

  • Du hast ja hier - blockaden-durch-epg2vdr-oder-scraper2vdr - schon beschrieben, dass der VDR beim epg2vdr Update fast unbedienbar wird.

    Das 5ms Wait öffnet jetzt ein Zeitfenster, in dem andere - blockierte - VDR-Threads dann ausgeführt werden können.


    Damit aber ein Wait vom 5ms die Ausführung um 47 Minuten verzögert müsste diese while-Schleife über 500000 mal durchlaufen werden - sind so viele Verzeichniseinträge wirklich vorhanden? Und sollte ein Update von 5000 Bilder oder Symlinks nicht eher ein Sache von Sekunden als Minuten sein?


    Ich kenne das epg2vdr Plugin nicht und werde es am Wochenende einmal ausprobieren, vielleicht fällt mir etwas auf.

    Helmut

  • Naja, "fast" ist ein wenig untertrieben ... :-)


    Nach dem Start und ab und zu zwischendurch gibt es Phasen, wo der vdr was von >100s Latency ins Syslog schreibt. Wenn die Kiste der FB nicht folgt drückt man dann besser keine weitere Taste ... sonst siehe Satzanfang.


    Das liegt aber vermutlich an der Datenbank auf einem "anderen" Rechner. Ich bastel daher die DB-Abfragen gerade auf die "Non-Blocking" Api um. Aber dies ist keine Arbeit von ein paar Tagen...

    (Falls jemand Zeit hat, hier der Anfang MairaDB_NonBlocking.patch)


    Zur Frage der epg2vdr Dateien (kurz mit ncdu geguckt):

    427494 Links auf 7419 Bilder


    Ähem... da hat mich das "find . -type f | wc -l" wohl ausgetrickst.

    Das paßt dann zu > 35 Minuten bei 5 ms. :-)


    42.

  • Moin zusammen,

    kann mir jemand evtl. die libciplusprivate.so zur Verfügung stellen?


    Cheers,

    Ole

  • Bei der Verwendung einer "gepackten" CAPMT wie in camtweaks-2.3 wird beim Hinzufügen oder Entfernen von Programmen immer eine CAPMT Message mit den geänderten Pids an das Modul gesendet. Da aber nicht alle Module diese Pid Änderungen ohne kurze Unterbrechung der Entschlüsselung übernehmen habe ich hier eine neue Version die mit einer statischen CAPMT arbeitet.


    Dazu wird gleich nach dem Start oder einem CAM-Reset eine CAPMT für eine bestimmte Anzahl von Programmen und mit vordefinierten Pids an das Modul übergeben. Im laufenden Betrieb werden dann die Pids der zu entchlüsselten Streams einfach auf die zuvor im Modul reservierten Pids "hingebogen" und es müssen keine weiteren CAPMTs an das Modul gesendet werden. Das ganze funktioniert ähnlich wie das mappen bei MTD.


    Die Konigurationszeile in camtweaks.conf sieht für mein SimpliTV Modul nun so aus:

    0x43,3,<CAFE:BABE,Irdeto Access>,[0x69C:5:4]

    0x40 ist das Flag für sie Verwendung einer statischen CAPMT, das Limit von "3" hat jetzt keine Bedeutung mehr, die statische Konfiguration steht in "[0x69C:5:4]": 0x69C (Hex) ist die CAID, "5" ist die max. Anzahl der Programme, "4" ist die max. Anzahl der Streams-Pids je Programm (die maximale Anzahl ist derzeit 16 Programme und 15 Stream-Pids).


    Der Nachteil dieser fixen Zuordnung ist eine gewisse Pid "Verschwendung" da man sich an dem Programm mit den meisten A/V Streams orientieren sollte.

    Wenn die Pid Anzahl zu klein ist, können die überzähligen Streams nicht entschlüsselt werden (diese Pakete werden gleich verworfen und landen auch nicht in den Aufnahmen). Wenn die Pid Anzahl zu groß gewählt ist, werden möglicherweise nicht mehr alle Pids entschlüsselt und es gibt bei Aufnahmen einen Emergency Exit.


    Wenn jemand beim Umschalten mit dem Sky Modul Bildstörungen festgestellt hat, könnte diese Konfiguration ausprobiert werden: 0x43,3,<CAFE:BABE,Sky NDS CI Plus Modul>,[0x98C:2:4]


    LG Helmut