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

  • Also nach Installation der neuen Treiber und ein wenig Rumspielen mit den EInstellungen des ddci2-Plugins, habe ich für mich folgendes, zufriedenstellendes Ergebnis:

    1. Mit den neuem Treibern hat vdr bisher nicht mehr den Kontakt zum CAM verloren.

    2. Mit der Einstellung "--bufsz 500" scheinen auch die Fehlermeldungen aus dem syslog verschwunden zu sein. Generell scheint es damit besser zu laufen, da ich vorher gelegentliche Bildstörungen hatte (Klötzchen), die ich jetzt nicht mehr beobachten konnte.


    Ich hoffe, das ist jetzt nicht nur eine Eintagsfliege. Wenn es so bleibt bin ich echt happy.


    Lieben Dank für den geduldigen Support :) :) :)

  • 2. Mit der Einstellung "--bufsz 500" scheinen auch die Fehlermeldungen aus dem syslog verschwunden zu sein.

    Also das verstehe ich jetzt nicht!

    Der Buffer im Plugin ist 1500 Pakete groß und du hast diesen jetzt kleiner gemacht. Warum das helfen sollte ist mir total unklar.

    Hast du ev. das "-A" Flag gesetzt? Das würde nämliche den Buffer nicht löschen, wenn der VDR ein Stop/StartDecrypting macht und dann könnten alte Daten in den Buffern stehen.

    Falls ja, dann nimm das Flag und die bufsz aus den Parametern wieder raus und beobachte es.


    LG,

    Jasmin

  • Ich weiß, klingt komisch. Aber nachdem ich feststellen musste, dass es mit Buffer > 1500 es eher (auch im Bild sichtbar) schlimmer wurde, habe ich einfach mal ausprobiert, den Buffer unter den Defaultwert zu setzen. Und bei mir hatte das den beschriebenen positiven Effekt.


    Das -A Flag habe ich übrigens nicht gesetzt. Wenn ich das Flag setze und die Buffersize auf Default lasse bzw. höher setze, bekomme ich wieder Fehlermeldungen und zwar wieder die alten bekannten:


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


    Die MTD Fehlermeldungen tauchen aktuell gar nicht mehr auf. So richtig eine reproduzierbare Systematik kann ich da leider auch nicht erkennen. Hab aber auch viel getestet, evtl. hat sich da das ein oder andere überlagert.


    So wie es im Moment mit dem verkleinerten Buffer läuft, bin ich zufrieden... :)


    Edit: Zu früh gefreut: MTD-Fehler sind wieder da. :( Läuft trotzdem insgesamt stabil und gut.


    Hab mal nach PID 8191 gesucht, die in den Fehlermeldungen ständig auftaucht und habe folgendes in Wikipedia gefunden:

    Zitat

    Nullpakete

    Bestimmte Übertragungsprotokolle wie ATSC und DVB schreiben eine konstante Bitrate vor (CBR). Um dieses sicherzustellen, kann es vorkommen, dass ein Multiplexer zusätzliche Pakete einfügen muss. Hierfür ist die PID 8191 reserviert, die dann keine Daten enthält und vom Empfänger ignoriert wird. (8191 ist die größte und somit letzte Zahl, die mit 13 Bits dargestellt werden kann.)

  • Um den Paketen mit PID 8191 auf die Spur zu kommen würde ich mal in mtd.c die Zeile


    //#define DEBUG_MTD


    aktivieren. Wenn dann im Log kein entsprechendes "...mapped PID... " auftaucht, dann muß das von woanders her kommen.


    Klaus

  • Hab die enstprechende Zeile aktiviert. Heraus kommt das:


    Kann man daraus was erkennen?

  • Man sieht zumindest, daß VDR diese PID nicht eingetragen hat. Wie die dann allerdings in den Datenstrom reinkommt kann ich mir nicht erklären.


    Füge doch mal testweise diese beiden Zeilen ein:

    Damit wird diese PID ignoriert. Sollte das helfen, dann müsste ich noch verhindern, daß VDR dorthin mappt. Aber das dürfte eh sehr unwahrscheinlich sein, denn das würde heißen, daß auf 31 verschiedenen Transpondern gleichzeitig aufgenommen wird, und vom 31. Transponder 255 PIDs verlangt werden - ein ziemlich unwahrscheinliches Szenario...


    Klaus

  • Ich nochmal ;)


    Nachdem es nun eine Weile recht gut und stabil läuft, habe ich noch folgende - evtl. zusammenhängende - Restprobleme:

    1. Speziell die Aufnahme von verschlüsselten Sendern zeigen bei mir relativ häufig Bildfehler (Verpixelung, Farbverlauf,...). Die Störungen sind immer nur kurz (< 1 Sek.) und sporadisch (max. alle 10 Min.). Beim Schauen ohne Aufnahme habe ich keine bzw. deutlich seltener Bildstörungen. Die Aufnahmen sind von SD Sendern. Im Log File (syslog, kodi.log) sind im betroffenen Zeitraum keine Fehlermeldungen zu sehen.
    2. Auf 1, machmal 2, verschlüsselten Sendern kommt es beim Schauen zu ganz extremen Aussetzern. Die Wiedergabe hält dann immer wieder an oder läuft stockend. Dies tritt ebenfalls sporadisch auf, dann aber über einen längeren Zeitraum. Manchmal hilft es auf einen anderen Sender und dann wieder zurückzuschalten. Im Log-FIle konnte ich ebenfalls nicht auffälliges dazu sehen. Da es sich um Sender handelt, die nur gelegentlich ausstrahlen, kann ich das Problem leider aktuell nicht reproduzieren.

    Da ich ja eine ältere Cine-S2 v5.5 mit ngene Treiber einsetze, habe ich schon die Befürchtung, dass es evtl. daran liegt. Bevor ich - bei den Preisen die DD für seine HW aufruft - aber anfange, planlos in neue HW zu investieren, würde mich Eure Meinung und die Erfahrung der Community interessieren.

    • Läuft es bei Euch ohne die oben beschriebenen Probleme?
    • Welche HW Kombi, welche HW-Revision läuft bei Euch zufriedenstellend?
    • Gibt es, speziell für Aufnahmen, noch Optimierungsmöglichkeiten?

    Falls ein Tausch notwendig ist, würde ich ich zunächst einmal nur die Turnerkarte durch ein neues Modell (HW-Revision 6.5 oder 7A) ersetzen und mein Flex-CI behalten wollen. Es sei denn, die Kombi ist so nicht lauffähig oder performant genug.


    Mein Setup läuft auf einem Intel H61 Board mit i3 Prozessor und 8GB RAM. OS ist Ubuntu 16.04 Desktop mit vdr 2.3.8 und kodi 17.3.

  • Hmmm, ich interpretier die Ruhe jetzt mal so, dass es bei allen anderen (mit aktuellerer) HW rund läuft. Ich hab mir in der Bucht mal ein Cine-S2 V6.5 geschossen und werde es alternativ damit versuchen und berichten.


    Dass bei den verschlüsselten Sendern die Aufnahmen aber sehr viel häufiger Bildfehler haben als das Fernsehbild finde ich merkwürdig.

  • Naja, sagen wir mal so, nach Umstellungen im BIOS (Sleep States C1E, C7 aus), Vergrößerung des DDCI2 Puffers und Einstellungen am Modul, falls Du Dasjenige mit Expertenmenü hast, läuft es recht stabil.


    Davor gab es TS-Cont. Fehler, und vor der DDCI Puffervergrößerung Klötzchen bei Mehrfachentschlüsselung und bisweilen Schwarzbild ohne Moduljustierung.


    Glaube, das Schwarzbild ist selten seit das CAM so steht:
    CAM 1: 'CA systems: SINGLE (from smartcard only)'

    CAM 1: 'CA registration: DYNAMIC (refresh always)'

    CAM 1: 'Force reading original PMT: AUTO'

    CAM 1: 'CA-PMT delete time: 1 s'

    CAM 1: 'CI-Watchdog: 1500 ms'

    CAM 1: 'dbox compatibility: ON'

    CAM 1: 'IC smartcard priority: I-Code'


    Stefan

  • Ah, danke.


    Werde das mal mit meinen Einstellungen vergleichen. Die "dbox compatibility" steht bei mir definitiv auf "AUS". Den Rest muss ich nachher mal nachschauen ...


    Den DDCI2-Buffer musste ich bei mir explizit gegenüber der Standardeinstellung verkleinern (s.o.), damit die Bildfehler weniger wurden.

    Nach einem BIOS Reset (Sleep States C1E, C7 kann ich im BIOS meines Intel Boards anscheinend nicht separat setzen) scheint es stabiler zu laufen. Bildqualität der letzten Aufnahme war zumindest 1A ohne Fehler/Aussetzer.


    Ich werde den Zustand jetzt erstmal so lassen und beobachten. Wenn es so stabil bleibt, kommt die neue Karte erstmal in die Schublade oder geht zur Auktion in die Bucht.

  • Das muss aber definitiv auf "Ein" stehen!

    Wieso? Läuft hier seit langem problemlos und war hier noch nie "Ein".

    Antec Fusion Remote black
    Asrock B150M Pro4S/D3
    Celeron G4560
    2x4 GB Ram 1600Mhz
    Kingston 60GB V300 SSD
    Zotac GT1030
    LG GH-22NS
    L4M Twin-CT V6.2
    Duoflex Dual CI
    Satelco Easywatch DVB-C
    Gen2VDR6.0

  • Leider gab es auf meine Frage nach "guten" Combos von CI und Cine S2 bisher keine Rückmeldung. Ich vermute daher, dass es meine alte v5.5 einfach nicht gut mit dem ddci2 tut. Laut der Signaturen, die ich hier so sehe, scheinen die meisten wohl eine v6.x zu nutzen, die offenbar weniger Zicken macht.


    Auch die Verwendung der nst-Treiber hat zwar weniger Fehler, aber letztlich doch nicht die gewünschte Stabilität gebracht. Seit dem Umstieg auf CI und ddci2-Plugin häufen sich die Bild- und Aufnahmefehler auf meinem System.


    Leider wird die v6.5 nicht konstant von meinem Mainboard erkannt (bekanntes Problem mit Intel MB DH61AG, was sich leider nicht lösen lässt - wie sich erst jetzt heraus stellte) und so bleibt mir aktuell wohl keine andere Option als mich erstmal mit dem jetzigen Zustand anzufreunden


    Mich würde trotzdem weiterhin interessieren, ob diese Combo hier irgendjemand anderes stabil am Laufen hat.

  • Ich vermute daher, dass es meine alte v5.5 einfach nicht gut mit dem ddci2 tut.

    Ich habe den ngene Code mal kurz überflogen, aber was gefunden hab ich nicht.

    Ich kann dir aber sagen, dass der ddbridge Treiber auch ein paar Verbesserungen meinerseits gebraucht hat, bevor der so funktioniert hat wie gedacht. Diese speziellen Dinge hab ich zwar im ngene Treiber nicht gefunden, aber ich vermute trotzdem, dass es am Treiber und nicht an der Karte liegt.


    Auf der anderen Seite ist ein neue DD Karte nicht so teuer und sowohl die Octopus CI, als auch die Cine V6.x funktionieren alle mit ddci zusammen. Wie gesagt, die Treiber wurden eben verbessert, um das ciX/secX Device richtig zu bedienen.


    Auch die Verwendung der nst-Treiber hat zwar weniger Fehler, aber letztlich doch nicht die gewünschte Stabilität gebracht. Seit dem Umstieg auf CI und ddci2-Plugin häufen sich die Bild- und Aufnahmefehler auf meinem System.

    Wie hast du denn bisher geschaut?


    Leider wird die v6.5 nicht konstant von meinem Mainboard erkannt (bekanntes Problem mit Intel MB DH61AG, was sich leider nicht lösen lässt - wie sich erst jetzt heraus stellte) und so bleibt mir aktuell wohl keine andere Option als mich erstmal mit dem jetzigen Zustand anzufreunden

    Scharrn! Das klingt nicht nach eine Lösung!

    Und das MB tauschen?

    Weil wenn das MB mit der Cine Probleme hat, dann wird es diese sehr wahrscheinlich auch mit einer Octopus CI haben, sind da doch sehr ähnliche Komponenten verbaut.


    Mich würde trotzdem weiterhin interessieren, ob diese Combo hier irgendjemand anderes stabil am Laufen hat.

    Bei mir läuft eine Cine S2 V6 mit einem DuoFlex CI (single) und auch wahlweise mit einem DuoFlex CI (dual). Das ist mein Entwicklungssystem und auch bei längeren Aufnahmen habe ich keine Probleme bemerkt.


    LG,

    Jasmin

  • Wie hast du denn bisher geschaut?

    Auch über VDR bzw. KODI/VDR und den (Standard) Kernel-Treibern von Ubuntu 16.04. Nur hab ich da ein anderes Plugin genutzt (das aber hier nicht erwähnt werden darf). Ich bin dann auf CI und DDCI2 Plugin umgestigen, da die vorige Lösung (wie bei vielen) nicht mehr lief. Wie gesagt, in der Konstellation - auch schon mit VDR 2.3.8 - lief es recht gut

    Und das MB tauschen?

    Ja, das scheint mir dann letzlich wohl der einzige Weg. Ist leider nicht nur das MB, was ersetzt werden muss: CPU, Speicher, Netzteil. Das alte Board hatte noch einen LGA1155 Sockel, S0-DIMMs und eine 19V Stromanschluss, die heute kein Board mehr unterstützt. Ich würde dann gleich auf was moderneres wie LGA 1151 setzen und das alte Board ggfs. noch irgendwo als Server oder so nutzen.


    Meine aktuelle Wunschkonfig wäre: ASUS B250M-C, I3-6100T, 8GB DDR4-RAM. Das sollte auch noch für längere Zeit passen (das alte Board hatte ich ca. 4 Jahre im Einsatz) und dann hoffentlich auch mit der v6.5 gut zusammenspielen

  • jasminj : Noch aprospros "Treiber"; Gem. Empfehlung von Dir, verwende ich die aktuellen Treiber aus dem media_build git von herrnst. Jetzt habe ich entdeckt, dass es unter linuxtv.org ebenfalls ein media_build git-Repository für linux gibt, an dem Du auch selbst mitwirkst.


    Welcher Unterschied besteht zwischen den Treibern, die aus den unterschiedlichen Repositories gebaut werden und welches ist für welchen Fall zu empfehlen?

  • Welcher Unterschied besteht zwischen den Treibern, die aus den unterschiedlichen Repositories gebaut werden und welches ist für welchen Fall zu empfehlen?

    Die offiziellen Kernel Treiber werden in media-tree gehostet. Das ist so etwas wie ein Release Branch. Das kommt von Zeit zu Zeit in den Linux Kernel rein.

    Dazu passend gibt es dann media-build. Das wird benötigt um die Treiber von media-tree parallel zu einem installierten Kernel zu bauen. Das muss immer zu den Sourcen in media-tree passen.


    Das Repo von herrnst ist die Quelle für die Kernel Version des DD Treibers und ist damit so etwas wie ein Integration Branch. Dort findest du die neuesten Dinge bevor sie in media-tree akzeptiert werden. Dazu passend gibt es auch ein media-build. Und dann gibt es auch noch meine Kopie des Repos von herrnst, wo ich dann die CI Treiber für media-tree vorbereite.


    nst und ich arbeiten hier sehr eng zusammen und ich bin erstaunt wie gut das funktioniert hat.


    Und zum Schluss gibt es noch den Ursprung von allem, das offizielle DD Repo. Von dort kommen die Treiber ursprünglich, wurden dann an den DVB Core in media-tree angepasst und eben in den Kernel integriert.

    Die Treiber in dem Repo können aber nur DD Karten und keine anderen parallel.


    LG,

    Jasmin