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

    Zitat von TimUx

    Die privaten HD Sender werden natürlich über die Sky v14 Karte mit entschlüsselt.
    Somit ist kein CI+ nötig.

    Zitat von TimUx

    Wäre es etwas für dieses Forum, wenn ich ein offizielles SKY CAM nutze?

    Soweit ich weiß gibt es von Sky nur ein CI+ CAM für die neueren Karten und das funktioniert (gewollt) nicht in einem normalen CI-Steckplatz. Damit ist die Frage von sehr sehr sehr hypothetischer Natur...

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Zitat von TimUx

    Wäre es etwas für dieses Forum, wenn ich ein offizielles SKY CAM nutze?


    Wenn es ein Problem mit dem ddci2-Plugin gibt, dann wohl ja, weil das nichts anderes macht, als die Hardware anzusteuern, wie es der vdr selbst auch schon tut.


    Lars.

    OK,
    also kein Sky CAM. ;)


    Wie gesagt, spontan kann ich erst mal keinen Fehler finden.


    Werde mich mal anderweitig umhören.


    Trotzdem Danke!


    Gruß TImo

    VDR: MLD 5.1.0 Testing
    Server: ASUS TROOPER B150 D3 -- Intel i5 6400T -- 4GB RAM -- 2x 8TB Seagte HDD -- RAID 1 -- 2x L4M-Twin S2 ver 6.5 -- 1x L4M-Twin S2 ver 5.4 --
    Clients: Rasperry pi B + Rasperry pi 2 + Rasperry pi 2 + Samsung BD 75000 + Nvidia Shield + Sony TV X8505C

    Hi,
    Seahawk hat doch schon den echt großen Zaunpfahl gewählt...


    Generell kann HD+ unter Linux nicht gehen, unter Win komischerweise schon... Von hier nicht zu diskutierenden Lösungen rede ich nicht!


    Das finde ich halt auch interessant, dass unter Win USB CAMs problemlos beworben und verwendet werden. Aber der zu große nötige Umbau scheit der Knackpunkt zu sein, sonst könnte ja echt mal wer die unerwünschten Dateifunktionen entfernen... So das wars dazu...


    MfG,
    Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente
    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte     GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:     Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

    Das mag sein, aber bevor wir uns hier in komische Grauzonen begeben, überlassen wir die Diskussion lieber anderen Boards.


    Lars

    Hab eine neue Version den Plugins ins git gestellt (Nein MTD geht noch nicht!). Dazu auch der Post hier und hier.


    LG
    Jasmin

    Einmal editiert, zuletzt von jasminj ()

    VDR 2.3.3 ist da und damit MTD support!
    Das dazu passende ddci2 Plugin mit MTD Support findet ihr im git.


    Damit ist das Hauptziel von ddci2 erreicht worden. Man kann jetzt die CAMs im DD CI Adapter mehreren Tunern dynamisch zuordnen, sofern das eingesteckte CAM mehrere Channels gleichzeitig entschlüsseln kann.


    Ich möchte die Gelegenheit nutzen Klaus S. für die Implementierung von MTD im VDR zu danken. Es ließ sich dort einfacher realisieren, als im Plugin.
    Die Zusammenarbeit war sehr nett und produktiv.


    LG,
    Jasmin

    Zitat von jasminj

    [...] Damit ist das Hauptziel von ddci2 erreicht worden. Man kann jetzt die CAMs im DD CI Adapter mehreren Tunern dynamisch zuordnen, sofern das eingesteckte CAM mehrere Channels gleichzeitig entschlüsseln kann.


    Was die "hartem" CAMs angeht, funktioniert es recht gut, leider aber geht das das Zusammenspiel mit "weichen" CAMs (noch) nicht. :(

    Das musste ich leider auch zu einem ungünstigen Zeitpunkt auch erfahren. Bei dem neueren bösen plugin gibt es diesbez. Änderungen, ich konnte sie aber noch nicht Testen.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

    Hallo Jasmin,


    irgendwie schreibt das ddci2 Plugin (1.01) haufenweise Fehlermeldung ins Log.
    Ich habe eine Octopus mini V2 mit Duoflex S2 + 3 CI Slots (Duoflex CI und FlexCi)


    Funktionieren tut alles, aber diese vielen Fehlermeldungen pro Sekunde machen das Log doch recht unübersichtlich.


    Zitat von nanohcv

    irgendwie schreibt das ddci2 Plugin (1.01) haufenweise Fehlermeldung ins Log.
    Ich habe eine Octopus mini V2 mit Duoflex S2 + 3 CI Slots (Duoflex CI und FlexCi)

    Ich habe auch von einem anderen Nutzer auf GitHub diesbezüglich einen Issue erhalten.
    Klaus und ich haben das natürlich getestet und nichts dergleichen feststellen können.
    Was bei eurer HW anders ist als meiner, ihr habt mehr als ein CAM im Rechner stecken.


    Zitat von nanohcv

    Funktionieren tut alles ...

    DAS verstehe ich bei der Fehlermeldung nun überhaupt nicht. Ich habe eine Octopus Duo CI im produktiv VDR ... müsste also das System mal updaten ... aber ob es dann dort auftritt ... .


    Ich hab mir das mal im Code angesehen:
    Die Fehlemeldung kommt aus "DdCiTsRecv :: Deliver" und zwar dann, wenn die entschlüsselten Daten nicht in den Buffer geschrieben werden können.
    Ich versuche das 3x mit einem Timeout von 100ms (=300ms), was normalerweise eine Ewigkeit für einen Prozessor ist, und dann verwerfe ich das Paket. Das müsste dann aber zu Bildfehlern führen, du sagst aber es geht alles ?( ... das glaub ich dir einfach ned :wow


    Wir müssen jetzt mal herausfinden, welchen Zweig es geht. Sprich ist es ein MCD fähiges CAM oder nicht. Weil wenn es das nicht kann, dann geht es in den Plugin internen Buffer (siehe "DdCiCamSlot :: DataRecv").


    Bei Starten des VDR sagt dieser, ob er MTD einschaltet oder nicht. Findest du das im LOG:

    Code
    CAM 1: replies to QUERY - multi channel decryption (MCD) possible
CAM 1: supports multi transponder decryption (MTD)
CAM 1: activating MTD support

    Ich vermute mal nicht, weil der User mit der Fehlermeldung auf GitHub hat auch ein CAM, dass kein MCD kann. Dann hätten wir eine Gemeinsamkeit!
    Noch eine Info: Ein MCD fähiges CAM reagiert auf "QUERY".


    Du könntest in dem Fall wenn dein CAM kein MCD kann, auch gleich noch ein paar Dinge testen:

    • in "ddcirecvbuf.h" und "ddcitsrecv.h" BUF_NUM auf 10000 setzen
    • in "ddcitsrecv.cpp" Zeile 169 "if (retry++ < 3) {" die Zahl 3 auf 5 oder 7 erhöhen

    Bitte nicht gleichzeitig sondern hintereinander! Ich möchte wissen ob die Buffergröße alleine ausreicht!


    Wenn beides nicht hilft und da ich keinen Fehler im Code ("DdCiCamSlot :: DataRecv") finden kann, heißt das schlicht und ergreifend, dass dein Rechner zu langsam für MTD ist! Der muss nämlich die Pakete per CPU zum CAM kopieren und wieder zurück. Bei 3 CAMs kann das schon recht viel Daten sein.
    Und dieses Problem könnte auch bei einem MCD fähigen CAM auftreten, weil da ist der Buffer in der VDR Klasse "cMtdCamSlot" versteckt. Dort zwar mit MEGABYTE(1) definiert, aber das ist nur 2,7x größer als mein Buffer (367kByte). Die 10000 wären dann übrigens knapp 1,8MByte, also 1,8x mehr als im VDR.


    LG,
    Jasmin

    Also laut Log kann das Cam MTD:


    Zitat


    Apr 01 12:25:24 BM639 vdr[16336]: [16355] CAM 3: replies to QUERY - multi channel decryption (MCD) possible
    Apr 01 12:25:24 BM639 vdr[16336]: [16355] CAM 3: supports multi transponder decryption (MTD)
    Apr 01 12:25:24 BM639 vdr[16336]: [16355] CAM 3: activating MTD support


    Ich denke die Fehlermeldungen beziehen sich nur auf die Slots, in den kein Modul drin streckt.
    Vermutlich ist /dev/dvb/adapter1 das DuoFlex S2 Modul


    /dev/dvb/adapter2 und adapter3 das DuoFlexCi in dem keine Module drin sind
    /dev/dvb/adapter4 ist das das FlexCi in dem das AlphaCrypt drin ist.


    Hier sieht man dass das Plugin da paar Threads für adapter4 startet.

    Zitat


    DDCI adapter /dev/dvb/adapter4/ca0 thread started (pid=16438, tid=16460, prio=high)
    DDCI Recv (/dev/dvb/adapter4/ci0) thread started (pid=16438, tid=16462, prio=high)
    DDCI Recv Deliver (/dev/dvb/adapter4/ci0) thread started (pid=16438, tid=16463, prio=high)
    DDCI Send (/dev/dvb/adapter4/ci0) thread started (pid=16438, tid=16461, prio=high)


    Die Fehlermeldungen beziehen sich aber alle auf Adapter2 und 3:

    Zitat


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

    Zitat von nanohcv

    Ich denke die Fehlermeldungen beziehen sich nur auf die Slots, in den kein Modul drin streckt.

    Danke für diesen Hinweis!
    Um das zu debuggen, muss ich also doch meinen produktiv VDR benützen :angst


    Ich werde das irgendwann am WE machen.
    Du kannst ja mal die Fehlermeldung auskommentieren bis ich eine Lösung habe.


    LG,
    Jasmin

    Also das versteh ich nun auch wieder nicht ?(
    Das würde nämlich bedeuten, dass eine CI Schnittstelle Daten liefert obwohl keine da sind!


    Ich habe jetzt ohne ein CAM im CI Slot stecken zu haben getestet und auch Log-Ausgaben dazu gebaut. Da kommt nix! Es kommt auch nix wenn ein CAM drinnen steckt und es nicht Decryptet. Hmm ...


    Es muss was mit deiner HW zu tun haben! Der Treiber für das Duoflex CI scheint sich hier anders zu verhalten als der für das FlexCI, dass ich habe.
    Wenn ich das mal annehme, dann kommen also Daten von einem leeren CI Slot. Diese werden dann in den ersten Buffer geschrieben, um dann später an die Funktion "DdCiCamSlot :: DataRecv" weiter gegeben zu werden. Da kein CAM drinnen steckt, müsste "MtdActive" false returnen und es müsste in den Plugin internen Buffer gelangen. Nachdem aber kein CAM gefunden wurde, wird auch nicht "DdCiCamSlot :: Decrypt" aufgerufen und der Buffer läuft voll. Somit laufen die Buffer wieder irgendwann über, egal wie groß man sie definiert!
    Du müsstest also irgendwann wieder diese Log Ausgaben bekommen.


    Nachdem ich diese HW derzeit nicht habe, würde ich dich bitten das für mich zu debuggen, falls du die Zeit hast :O
    Trag mal in die Datei "/etc/vdr/conf.avail/ddci2.conf" einen anderen Debug Level ein:

    Code
    [ddci2]
-l 3
-d 0x0001
-d 0x1000


    Damit sollten wir sehen, ob Daten in die CAM Snd/Recv Buffer geschrieben werden:

    Code
    DDCI-Dbg: DdCiTsSend for /dev/dvb/adapter2/ci0 CAM buff rd(-> CAM):4513, wr:4723
DDCI-Dbg: DdCiTsRecv for /dev/dvb/adapter2/ci0 CAM buff wr(CAM ->):4030, rd:4032


    Du kannst die nervige Zeile für diesen Test ja deaktivieren.
    Wenn da bei den Adaptern ohne CAM was steht, dann haben wir es ja schon.


    Mich würde dann noch interessieren was passiert, wenn man das CAM in einen derzeit unbenutzten CI Schacht steckt und auf einen Sender geht der nicht verschlüsselt ist. Dann sollten von dem Adapter mit dem CAM keine Daten mehr kommen.


    Und für den Adapter wo das CAM vorher war, sollte dann überhaupt niemals etwas ausgegeben werden. Zumindest ist das bei mir so.


    Der Grund warum das jetzt übrigens auftritt ist, dass wir das "active" Flag im letzten Comit ausgebaut haben, damit ein Kanalwechsel schneller geht. Damit kann das Plugin Daten, die fälschlicherweise von einem leeren CI Schacht, kommen nicht mehr verwerfen.


    LG,
    Jasmin

    Also :] .


    ich hab mal diverse Logs von allen Slots erstellt.


    Für unverschlüsselte Sender heißen die Slot1-3.txt
    Für Logs mit einem verschlüsselten Sender heißen die Logs e_slot1.txt und e_slot2-3.txt


    Rausgefiltert habe ich diverse softhddevice Meldungen und die "DDCI-Err: Can't write packet VDR CamSlot for CI adapter" Meldungen.


    Manchmal aber nicht immer kommen auch noch solche Meldungen (egal ob ein verschlüsselter Sender oder ein unverschlüsselter Sender eingestellt ist):


    Zitat


    ERROR: invalid MTD number (1) in PID 262 (0106)


    Selbst wenn in keinem Slot irgend ein Modul steckt, kommen solche Meldungen:




    Als Treiber verwende ich den dddvb 0.9.28-v7a .


    dmesg Output:


    Ich hoffe das hilft die weiter

    nanohcv: Danke für die Logfiles!
    Es freut mich, dass hier alle so toll unterstützen! :tup
    Ich bin mir jetzt relativ sicher, dass das ein Problem im Treiber ist. Habe dazu mal eine Frage an Ralph gestellt.


    Natürlich gibt es in der Zwischenzeit einen Workarround im git V 1.0.2 8)
    Man kann jetzt die Buffergröße und die Wartezeiten auch per Optionen einstellen.


    Nachdem ich nur das activate Flag im DdCiCamSlot wieder eingebaut habe, welches die Daten vom CAM solange verwirft, bis der VDR das Decrypten aktiviert, habe ich auch eine neue Option "-A" eingebaut mit der man das active Flag ignorieren kann. Sprich den Status von Version 1.0.1 herstellen kann. Damit kann man die Kanal Umschaltezeit bei mancher DD CI Hardware, wie bei mir (Flex CI), schneller machen.


    Sobald der Kernel repariert ist, oder Ralph mir sagt das geht nicht anders, werde ich das wieder angreifen.


    Ich hoffe es funktioniert jetzt wieder bei allen.


    LG,
    Jasmin

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden