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

  • [...] Also das Plugin traut sich was, dem VDR Code in die Quere zu kommen. Ich habe mir das aber nicht angeschaut, ob das so sein darf. ...


    Ich glaube nicht, dass das Plugin den VDR "in die Quere kommt", das bedeutet einfach nur, dass wohl nicht alles entschlüsselt wurde und das Plugin der Meinung ist, dass man das CAM resetten sollte.

  • ... das bedeutet einfach nur, dass wohl nicht alles entschlüsselt wurde ...

    Und das sollte man mit den Debug Flags im ddci2 Plugin sehen.
    LG,
    Jasmin

  • Ich glaube nicht, dass das Plugin den VDR "in die Quere kommt", das bedeutet einfach nur, dass wohl nicht alles entschlüsselt wurde und das Plugin der Meinung ist, dass man das CAM resetten sollte.

    Das löst einen Neustart des Entschlüsselungsvorgangs plus Retune-Versuch aus: https://github.com/FernetMenta…e59a119c4/streamer.c#L261

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Das löst einen Neustart des Entschlüsselungsvorgangs plus Retune-Versuch aus

    Vielleicht sollte der Entwicker des Plugins mal dazu Stellung nehmen warum er das so macht und was er sich davon erhofft.


    Natürlich sollte im dekodierten TS Stream das Scrambed Bit gelöscht sein, aber wenn es aus irgendeinem Grund doch kommt, dann ist Rücksetzten nicht wirklich die Lösung denke ich. Wenn alles weiter läuft wird es schon irgendwann wieder entschlüsselt werden.


    Auf jeden Fall hat das nichts mit dem ddci2 Plugin zu tun, sondern schon eher mit Buffer Größen oder dem VDR oder was auch immer.

  • Hey , vielen Dank das sich so viele gemeldet haben !




    Habe den Entwickler mal im Kodi.tv Forum angeschrieben, mal sehen ob er sich meldet.


    Jetzt zum Debug :dösen


    Komme mir gerade ziemlich dämlich vor , aber der Debug macht bei mir absolut nichts.


    Was macht ich bitte falsch ?


    Code
    vdr -u vdr -P vnsiserver -P ddci2 -l 3 -d 0x0400



    Man sieht nicht mehr als sonst.


    Wird das möglicherweise woanders hingeloggt oder sollte das alles ins syslog gehen ?

    Software : VDR 2.3.8 | DDCI2 1.0.5 | LIVE 2.3.1 | STREAMDEV-SERVER 0.6.1 | VNSISERVER 1.5.2
    Server : ASRock J3710-ITX | 4GB RAM | 120GB SSD | Digital Devices Cine S2 V6.5 | DuoFlex CI | AlphaCrypt
    Client : Odroid C2 Kodi


  • Wenn du den VDR mit den Argumenten aufrufst, musst du die Argumente für das Plugin passend quoten:

    Code
    vdr -u vdr -P vnsiserver -P "ddci2 -l 3 -d 0x0400"

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Also manchmal frag ich mich wirklich wieso manche hier ned lesen können!!!


    In dem Post hab ich doch genau beschrieben welche Flags ich gerne hätte und da kam 0x0400 nicht vor!


    Nachdem du dem VDR die Parameter anscheinend nicht via etc/vdr/conf.d/50-ddci2.conf, sondern über die CommandLine übergibst, sieht das dann so aus:
    -P "ddci2 -l 3 -d 0x0001 -d 0x0800 -d 0x1000"
    oder
    -P "ddci2 -l 3 -d 0x1801"


    Dann spricht er nicht bei jedem (!) TS Paket.


    Im dem Logging sehe ich leider nicht was ich sehen will.
    Und du kannst mit dem Parameter "-c" die Scrambling Bits auch löschen (nur zum Test!). Ev. verhält sich dann VNSI anders, wobei eben dann auch verschlüsselte Daten zu deinem Client gesendet werden.


    LG,
    Jasmin

  • Bitte schön !



    Diesmal mit 0x1801



    Ab Zeile 192


    https://pastebin.com/AVSEjyiZ



    Und noch einer mit dem Parameter -c . Schwer zu sagen ob es besser oder schlechter ist. Wenn überhaupt minimal schlechter.


    https://pastebin.com/eSGGbbe1



    Danke ! :]

    Software : VDR 2.3.8 | DDCI2 1.0.5 | LIVE 2.3.1 | STREAMDEV-SERVER 0.6.1 | VNSISERVER 1.5.2
    Server : ASRock J3710-ITX | 4GB RAM | 120GB SSD | Digital Devices Cine S2 V6.5 | DuoFlex CI | AlphaCrypt
    Client : Odroid C2 Kodi


  • Hi!


    Code
    Jul 17 21:32:53 tv-server vdr: [7810] DDCI-Dbg: DdCiTsSend for /dev/dvb/adapter2/ci0 CAM buff rd(-> CAM):5263, wr:5386
    Jul 17 21:32:53 tv-server vdr: [7811] DDCI-Dbg: DdCiTsRecv for /dev/dvb/adapter2/ci0 CAM buff wr(CAM ->):5372, rd:5376
    Jul 17 21:33:03 tv-server vdr: [7810] DDCI-Dbg: DdCiTsSend for /dev/dvb/adapter2/ci0 CAM buff rd(-> CAM):55984, wr:55984
    Jul 17 21:33:03 tv-server vdr: [7811] DDCI-Dbg: DdCiTsRecv for /dev/dvb/adapter2/ci0 CAM buff wr(CAM ->):56410, rd:56448
    Jul 17 21:33:07 tv-server vdr: [7825] VNSI: CAM error, try reset

    Das sagt mir, das TS Pakete zum CAM gesendet werden: rd(-> CAM)
    Und das sagt mir, dass TS Pakete vom CAM kommen: wr(CAM ->)
    Und das VNSI Plugin lässt das doch einige Zeit laufen, bevor es den Reset auslöst.


    Ich habe aber keine Zeilen:

    Code
    DdCiCamSlot for /dev/dvb/adapter2/ci0 got ?? scrambled packets from CAM

    gesehen.
    Also scheint das CAM zu entschlüsseln, was auch zu deiner Beobachtung passt, dass es mit dem streamdev Plugin funktioniert.


    Es müsste sich jetzt jemand finden, der einmal untersucht warum das VNSI Plugin der Meinung ist das CAM gehöre resetiert. Und außerdem muss man sich fragen, warum ein Device das überhaupt macht und das nicht alles vom VDR steuern lässt. softhddevice macht ja auch nichts mit dem CAM.
    Du könntest mal die betreffenden Zeilen einfach auskommentieren und schauen was passiert.


    Aber: Ich mag ned noch ein Plugin analysieren, live reicht mir!
    Es wird sich ja hoffentlich jemand finden, der das mit dir debuggen kann, schließlich hat dieses Plugin ja auch einen aktiven Maintainer, oder?


    Ich hab jetzt ganz kurz geschaut, was das Plugin so tut. Wenn ein verschlüsseltes Paket kommt, wenn schon ein nicht verschlüsseltes da war, dann wird das CAM mit StopDecrypting mal abgeschalten.
    Ich weiß echt ned ob des klug ist. Ich würde das den VDR machen lassen, weil der hat da ein Timeout dafür.
    Man könnte den ganzen Code Teil mit dem "ERROR_CAM_ERROR" mal weg lassen und eben schauen was passiert.
    Und man müsste mal genau debuggen, ob da wirklich ein verschlüsseltes Paket kommt oder ob VNSI sich da irgendwo im TS Strem "verschaut".
    Klingt eben nach Debuggen und das muss der Entwickler machen. Er kann mich ja um Hilfe bitten, wo man was in ddci2 einbauen muss um das mit dem Scrambling Bits auszugeben, wenn er es nicht selbst findet.


    LG,
    Jasmin

  • Vielen Dank für die ausführliche Antwort , Jasmin !


    Mal sehen ob sich der Pluginentwickler davon etwas annimmt.

    Software : VDR 2.3.8 | DDCI2 1.0.5 | LIVE 2.3.1 | STREAMDEV-SERVER 0.6.1 | VNSISERVER 1.5.2
    Server : ASRock J3710-ITX | 4GB RAM | 120GB SSD | Digital Devices Cine S2 V6.5 | DuoFlex CI | AlphaCrypt
    Client : Odroid C2 Kodi


  • Hallo zusammen,


    seit ein paar Tagen nutze ich nun auch das ddci2-Plugin mit vdr 2.3.8 unter Ubuntu 16.04 64-bit. Meine Hardware ist eine schon etwas ältere Cine-S2 v5.5 (ngene) mit einem Single-CI-Modul. Meistens läuft die Kombo recht gut und zuverlässig. Dafür schon meinen großen Dank an Jasmin und alle, die hier geholfen haben.


    Leider füllt sich mein syslog aktuell mit folgenden Fehlermeldungen - unabhängig davon, ob ich einen (verschlüsselten) Kanal schaue oder nicht:

    Zitat

    vdr: [1466] ERROR: invalid MTD number (31) in PID 8191 (1FFF)

    und

    Zitat

    vdr: [1466] DDCI-Err: Can't write packet VDR CamSlot for CI adapter (/dev/dvb/adapter2/ca0)

    Außerdem scheint der VDR gelegentlich - aus für mich bisher nicht bachvollziehbaren/reproduzierbaren Gründen - den Kontakt zum CI/CAM zu verlieren. Unter den VDR-Einstellungen->CAM steht dann nur "1 - " satt wie sonst "1 - Alphacrypt". Im syslog finde ich dann nur

    Zitat

    kernel: [ 4555.455414] i2c i2c-9: NO CAM
    vdr: [1463] CAM 1: no module present

    Ich hab gelesen, dass unter früheren Versionen des Plugins bzw. vdr auch schon mal ein User Probleme damit hatte, zumindest interpretiere ich die Posts #339 - #341 dieses Threads entsprechend.


    Liegt es evtl. an meiner älteren HW- & Treiberkombo, dass diese Fehler bei mir auftreten oder läuft die Cine-S2 v5.5 mit CI bei anderen problemlos?
    Was kann ich tun bzw. welche Infos zur Verfügung stellen um bei der Fehlersuche/beim Fix zu unterstützen?


    Edit: Anbei noch ein Auszug aus dem syslog nach Neustart des vdr:


  • seit ein paar Tagen nutze ich nun auch das ddci2-Plugin mit vdr 2.3.8 unter Ubuntu 16.04 64-bit.

    Ich nehme mal die ddci2 Plugin Version ist 1.0.5.


    Meine Hardware ist eine schon etwas ältere Cine-S2 v5.5 (ngene) mit einem Single-CI-Modul.

    Welcher Treiber wird verwendet?


    Hab jetzt nicht in den VDR Code geschaut, aber soweit ich mich erinnere kommt das dann, wenn im TS Stream vom CAM die Umgeschriebene PID nicht der echten PID zuordenbar ist.


    Das passiert, wenn der Kernel den Kontakt zum CAM verliert. Ein längeres Logging von dem Problem wäre sehr hilfreich.


    Außerdem scheint der VDR gelegentlich - aus für mich bisher nicht bachvollziehbaren/reproduzierbaren Gründen - den Kontakt zum CI/CAM zu verlieren.

    Na das ist ja klar, wenn der Kernel das CAM nicht mehr sieht und dann ddci2 nicht mehr schreiben kann und auch keine Antwort vom CAM mehr kommt.


    Ich hab gelesen, dass unter früheren Versionen des Plugins bzw. vdr auch schon mal ein User Probleme damit hatte, zumindest interpretiere ich die Posts #339 - #341 dieses Threads entsprechend.

    Das sollte alles behoben sein.


    Liegt es evtl. an meiner älteren HW- & Treiberkombo, dass diese Fehler bei mir auftreten oder läuft die Cine-S2 v5.5 mit CI bei anderen problemlos?

    Welchen Treiber verwendest du?
    Ich habe erst vor einem Monat im Treiber für den cxd20099 (der ist am DD DuoFlex Ci single drauf) den Buffer Mode aktiviert. Ist aber bis jetzt nur im Treiber von nst drinnen.
    Im übrigen habe ich solche ähnlichen Probleme mit einem Uralt-CAM auf der DD Octupus CI (dual) und bin am Kernel Treiber debuggen. Ist alles ned so einfach ohne Unterlagen und wenn der Produktiv VDR jeden Abend vom Schatzi belegt ist.


    LG,
    Jasmin

  • Hallo Jasmin und danke für die schnelle Rückmeldung.


    Korrekt, die ddci2-Plugin Version ist 1.0.5.


    Die Treiber ngene und cxd2099 sind, die die im aktuellen Kernel von Ubuntu 16.04.03 enthalten sind:


    Damit lief es ohne CI bisher immer problemlos.


    Sollte ich ggfs. andere Treiber verwenden?


    Die Fehlermeldungen

    Code
    vdr: [5444] ERROR: invalid MTD number (31) in PID 8191 (1FFF)


    und

    Code
    DDCI-Err: Can't write packet VDR CamSlot for CI adapter (/dev/dvb/adapter2/ca0)


    kommen auch, wenn das CAM noch ansprechbar ist. Ich hab in meinem ersten Post mal einen Auszuag aus dem syslog ergänzt (nach Neustart des vdr). Zu dem Zeitpunkt konnte ich trotz der Fehlermeldungen problemlos einen verschlüsselten Kanal schauen.
    Dass der Kernel den Kontakt zum CAM verliert kommt nur sporadisch vor, während die Fehlermeldungen zurzeit permanent auftreten auch wenn scheinbar alles läuft.


    Danke


    Grumpy

  • Die Treiber ngene und cxd2099 sind, die die im aktuellen Kernel von Ubuntu 16.04.03 enthalten sind

    MANN, DAS GEHT NED!!!!
    Bitte lies dir das README vom ddci2 Plugin durch (GIT Version 05dd98824092859afd2aa7a4996c8f258affd975) und besonders den Kasten mit NOTE NOTE NOTE ... . Ich weiß wirklich nicht, wie ich es noch mehr hervorheben soll. Lesen müsst ihr schon!


    Und auch in diesem Thread waren die Treiber immer ein Thema. Ich bin sehr verwundert, dass die Kommunikation mit dem CAM überhaupt mit der Kernel Version von Ubuntu funktioniert! Es gibt in den originalen Kernel Treibern einige Fehler, die erst in letzter Zeit behoben wurden oder durch DKMS Treiber Pakete ausgetauscht wurden.


    Zu den Treibern:
    Hier im Forum gibt es einen Thread dazu. In diesem Post steht wo es weiter geht und ein Hinweis auf ein HOWTO in dem Thread (mehr hab ich auf die Schnelle nicht gefunden).


    Wenn du diese Treiber nicht kompilieren kannst, dann tut es auch das DKMS Paket media-build-experimental (Google!). In dem ist zwar mein letzter Patch für den cxd2099 Buffer Mode ned drinnen, aber den braucht man beim Alphacrypt nicht unbedingt.


    Sollte ich ggfs. andere Treiber verwenden?

    Ja, solange du keinen Kernel 4.14 hast, sofern wir es schaffen für diese Version die Treiber gemerged zu bekommen, sonst wird es 4.15.


    Jasmin

  • Hab die neuen Treiber gem. Anleitung von hier kompiliert und installiert. Nach reboot sieht es so aus:


    Leider sind die Fehlermeldungen im Log immer noch zu sehen.


    Code
    Aug  8 20:05:44 localhost vdr: [2015] ERROR: invalid MTD number (31) in PID 8191 (1FFF)


    Der DDCI-Error hat sich allerdings verändert:

    Code
    Aug  8 20:05:46 localhost vdr: [2015] DDCI-Err (ddcitsrecv.cpp,151): skipped 134 bytes to sync on start of TS packet


    Nach einem Neustart des vdr sieht es im syslog so aus:

  • Du hast keinen log vom Booten dabei, aber ich sehe

    "Aug 8 20:05:07 localhost kernel: [ 214.427474] i2c i2c-9: enable cam buffer mode"

    also wissen wir das der neuen Treiber von nst geladen wurden.


    Das Skip kommt immer einmal nach dem Tunen und Re-Tunen und bedeutet, dass die TS Daten nicht mit dem Beginn Marker kommen.

    Das mit der "invalid MTD number" bedeutet, dass im Datenstrom etwas nicht stimmt.


    Wenn du noch den LogLevel in ddci2 aufdrehst (siehe README), dann sehen wir vielleicht noch mehr. Allerdings glaube ich, dass wir ein Treiber Problem mit der ngene haben. Diese HW ist recht alt und im Treiber von nst zwar dabei, aber nur sehr wenig getestet und mit CI weiß ich nicht ob das wer am laufen hat.


    Du könntest ev. noch das yavdr dddvb-dkms versuchen. Habe eine recht neue Version in dem Post verlinkt.

    In dem Paket sind die alten Patches von UFO für die ngene dabei. Wenn es damit geht, dann müssen wir in den Treibern von nst noch nachbessern. Wenn nicht, dann kannst du das nur selbst debuggen, oder dir eine neue Cine V7 kaufen. Ich glaube nicht, dass DD die Treiber für die ngene noch angreift.


    Wobei ... ev. könnte es funktionieren, wenn man die alte ngene und eine neue Octopus Bridge zusammen verwendet. Die ngene liefert die TS Daten und das Duoflex CI an der Octopus Bridge sollte den Stream dekodieren können.

    Schau ma mal was deine Tests ergeben.


    LG,

    Jasmin

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!