Beiträge von js9401

Danke für deine schnelle Antwort!

Zitat von jasminj

Da lassen wir mal die Kirche im Dorf! Klaus hat MTD in den VDR eingebaut, weil es da besser hin gepasst hat. ddci2 realisiert nur die Schnittstelle für die DD CI Hardware.

Da ich aber schon immer die DD Hardware verwende war dein Plugin zumindest ausschlaggebend für den Wechsel.

Zitat von jasminj

Also da frag ich mich sofort warum da verschlüsselte Pakete kommen. Wenn dem wirklich so ist, dann müsste ddci2 das auch ausspucken. Man muss ddci2 nur mit entsprechenden Debug-Flags starten (siehe README).

Wenn das wirklich vom CAM kommt, dann frag ich mich wieso und dann ist der Stream ja eigentlich unbrauchbar, weil eben ein paar Pakete fehlen und das kommt bei MPEG ned guat. Im Grunde erübrigt sich da jedes gefrickel hinterher!

Sagt ddci2 allerdings nichts, dann hat das VNSI Plugin beim Erkennen der Bits ein Problem und man muss suchen warum das so ist.

Das Löschen der Bits ist keine Lösung! Wenn das CAM nicht entschlüsselt, dann ist das Paket unbrauchbar, egal ob die Bits gelöscht wurden oder nicht.

Beide vorgeschlagenen Patches lösen das Problem. Ich habe mich nur oberflächlich in das MPEG Demultiplexing eingelesen, konnte aber das Problem im VNSI Plugin bis hin zum Aufruf der VDR Methode IsTsScrambled() nachverfolgen. Diese liefert definitiv true zurück. ddci2 meldet dagegen auch bei vollem Debug-Output keinerlei Fehler, im Log erscheinen ausschließlich die gewünschten CAM buff rd(-> CAM) ... und CAM buff wr(-> CAM) ... Meldungen.

Zitat von jasminj

Na DAS meine ich auch!

Wie gesagt, zuerst mal ddci2 ausgeben lassen, ob die Pakete tatsächlich verschlüsselt sind.

Wenn nein -> debug VNSI

Wenn ja, dann muss man mal herausfinden, ob das CAM zu langsam ist, oder was da genau mit dem ECMs passiert in dem Moment, an dem nicht entschlüsselt wird. Das ist allerdings nicht trivial.

Wenn du mir mit einem Enstiegspunkt helfen kannst, bin ich gerne bereit weiter zu debuggen.

Zitat von jasminj

Siehe oben. Man kann erst etwas fixen, wenn man weiß was das wirkliche Problem ist. Ich habe dir ein paar Hinweise gegeben und wenn deine Kombination aus DD CI und CAM das nicht entschlüsseln kann, dann wird man das nicht in Software lösen können.

Im Grunde musst du in die SW rein graben, verstehen was passiert und es dann lösen.

Alles bereits geschehen. Das CAM entschlüsselt korrekt, mit dem streamdev Plugin funktioniert alles. Das nutzt allerdings auch IsTsScrambled() nicht. Der Fehler im VNSI Plugin lässt sich direkt auf den Aufruf dieser VDR Methode zurückführen; wenn ich das Scrambling Control Bit in der MTD Decrypt() Methode des VDR manuell entferne, dann funktioniert das VNSI Plugin einwandfrei.

Zitat von jasminj

Und mal nur so beiläufig gefragt: Die Treiber von nst verwendest du?

Ich verwende das Kernel Modul aus dem aktuellen git repo von DD (Link).

Hallo zusammen!

als neuer VDR Nutzer möchte ich erst mal ein großes Lob und Dankeschön an alle Entwickler aussprechen. VDR ist ein wirklich tolles Framework und seit der MTD-Unterstützung von Jasmin im ddci2 Plugin endlich eine echte Alternative zu meinem (hassgeliebten) Windows Media Center.

Ich hatte die gleichen Probleme wie Grumpy, das AlphaCrypt wird bei einigen Sendern (RTL HD, n-tv HD) ständig durch das VNSI Plugin resetted (VDR 2.3.8, VNSI-Plugin 3.5.2). Mit dem streamdev-Plugin tritt der Fehler nicht auf.

Zitat von jasminj

Es müsste sich jetzt jemand finden, der einmal untersucht warum das VNSI Plugin der Meinung ist das CAM gehöre resetiert. (...)

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". (...)

Ich habe mir das VNSI Plugin mal etwas genauer angesehen. Das Problem liegt an einem TsIsScrambled() Aufruf, der bei den genannten Sendern tatsächlich häufiger true zurückliefert (Link).

Das manuelle Löschen des Scrambling Control Bits über --clrsct im ddci2 Plugin hat allerdings keinen Effekt, wenn MTD aktiv ist (Link).
Ich sehe zwei einfache, aber unschöne Lösungen.

Fix im VDR Code

Das Scrambling Control Bit kann bei erfolgreicher MTD-Entschlüsselung direkt im VDR Code gelöscht werden. Vielleicht sollte aber eher die Ursache des Problems analysiert werden, anstatt es nur zu kaschieren.

--- vdr/mtd.c    2018-03-05 18:44:15.051387147 +0100
+++ vdr/mtd.c    2018-03-05 18:44:16.451347364 +0100
@@ -318,6 +318,7 @@
         return NULL;
         }
      if (c >= TS_SIZE) {
+        d[3] &= ~TS_SCRAMBLING_CONTROL;
         TsSetPid(d, mtdMapper->UniqToRealPid(TsPid(d)));
         delivered = true;
         }

Fix im VNSI Plugin

Die Überprüfung des Scrambling Control Bits kann aus dem VNSI Plugin entfernt werden. Auch das kaschiert aber eigentlich nur das Problem.

--- vdr/PLUGINS/src/vnsiserver/parser.c    2018-03-05 19:09:59.314646366 +0100
+++ vdr/PLUGINS/src/vnsiserver/parser.c    2018-03-05 19:10:12.790201142 +0100
@@ -176,11 +176,11 @@
 
 int cParser::ParsePacketHeader(uint8_t *data)
 {
-  if (TsIsScrambled(data))
-  {
-    m_Error = ERROR_PES_SCRAMBLE;
-    return -1;
-  }
+  //if (TsIsScrambled(data))
+  //{
+  //  m_Error = ERROR_PES_SCRAMBLE;
+  //  return -1;
+  //}
 
   if (TsPayloadStart(data))
   {

Ein besserer Fix wäre vermutlich, wenn der --clrsct Parameter im ddci2 Plugin auch im Fall von aktiviertem MTD das Scrambling Control Bit löscht. Ob und wie das genau funktioniert kann ich (noch) nicht überblicken, dafür müsste ich mir die Plugin-Mechanik des VDR erst näher ansehen und genauer verstehen, warum im MTD-Fall die Decrypt() Methode des ddci2 Plugins nicht benötigt wird.

jasminj Kannst du das Problem besser überblicken? Was ist deiner Ansicht nach der beste Fix?