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

  • Wenn man ohne zusätzlichen Buffer auskommen will, dann muss man eben den Rest (immer <188 Bytes) in ein kurzes Array umkopieren und beim nächsten Pakerl dann als erstes in den Output Buffer schreiben. Und man müsste immer überprüfen, ob dar Offset noch passt. Das kann man aber recht billig lösen und macht das ddci2 Plugin auch.

    Die Frage ist, wie lange willst Du da umkopieren? Das Offset dürfte auch über die 188 Bytes hinweg gehen (CAM oft genug neu initialisieren dürfte das ganz schnell bewerkstelligen). Und wenn man das Spielchen heftig genug treibt, hat man irgendwann auch die 512*188 Bytes als Sekundärbuffer ausgeschöpft. Immer weiter Kernel Memory ranholen und bis zur Bewusstlosigkeit das Offset fixen ist Unsinn, irgendwann muss man was droppen. Das kann man 1x beim Init machen, wo's keinen stört, um das Offset glattzuziehen, aber dafür müsste die Hardware bzw. deren Buffer auch resettet werden, sonst wird man das nicht los.

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • Nabend zusammen,


    so - hier (https://github.com/herrnst/ddd…iatree/master-ngene-tsfix) gibts 'n Workaround für die Offsetverschiebung. Der Patch von Klaus ist damit nicht notwendig, es herrscht jetzt Ruhe im vdr.log. MTD funktioniert auch. Da das komplett experimentell ist, muss ngene mit ci_tsfix=1 geladen werden. Da hier weiterhin (nur mit variablem Offset) selektiv aus den Buffern kopiert wird, die die Hardware liefert, ist der stetige Datentransport von der/zur Hardware nicht gestört, die Puffer laufen also nicht trocken bzw. laufen über.


    Wenn das mal jemand testen möchte und Hilfe braucht, aus media_tree mittels media_build zu compilen, bitte melden.

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • Bravo, und clever mit den TS-Fragmenten.
    Testen kann ich es mangels entsprechender Hardware leider nicht.


    interessant finde ich, dass die SYNC Verschiebung genau vor einem NULL-Paket stattfindet, und - da du ja keine Fehlermeldungen oder Bildfehler hast - tsin_find_offset() offenbar immer erfolgreich ist, Anderenfalls würden ja TS-Pakete ohne dem SYNC-Byte im tsout-Ringbuffer landen.


    Das liegt am Ngene Chip der eigentlich für Audio gedacht ist und immer etwas erwartet, weil bei Audio ist das einfach so. Man hat das dann mit den leeren TS Paketen im Treiber gebastelt.

    Alles klar, habe ich nicht gewusst. Und ohne die Idle-Pakete geht es wie von nst gestestet ja wirklich nicht.



    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

  • Bravo, und clever mit den TS-Fragmenten.
    Testen kann ich es mangels entsprechender Hardware leider nicht.

    Was das Testen angeht, denke ich hier v.a. an Grumpy (von ihm kam im Ursprung ja die Problemmeldung mit den NULL Frames). Da ist aber natürlich jeder herzlich zu eingeladen, der ngene+CI Hardware verwendet ;)


    interessant finde ich, dass die SYNC Verschiebung genau vor einem NULL-Paket stattfindet, und - da du ja keine Fehlermeldungen oder Bildfehler hast - tsin_find_offset() offenbar immer erfolgreich ist, Anderenfalls würden ja TS-Pakete ohne dem SYNC-Byte im tsout-Ringbuffer landen.

    Die Verschiebung passiert mit ziemlicher Sicherheit immer nur dann, wenn irgendwelches CAM Control Zeugs transportiert wird (CAM Init usw.). Das ist aber eh der Zustand, wo noch keine "Echt"-Daten transportiert werden, d.h. direkt, nachdem das Kernel Modul geladen wurde und/oder VDR gestartet wurde und das CI-Modul hochgefahren wird. Zu der Zeit gibts eh nur NULL Packets. Wenn das aus irgendwelchen Gründen "mittendrin" passiert (konnte ich bislang nicht feststellen) und gerade ein echter Datenblock transportiert wird, wird das im schlimmsten Fall unaligned zum DVB Subsystem kopiert. Das scheint aber unproblematisch zu sein (ich hab auch mit "Invalid PID 0x1fff" Bildfragmente sehen können), offenbar wird das nochmal "nachsortiert". Spätestens beim nächsten NULL Frame (und der wird garantiert auftauchen!) wird der Datentransport wieder glattgezogen.


    Man könnte in tsin_find_offset() noch den ganzen Buffer anstatt der ersten 188+sizeof(fill_ts) scannen, damit das schneller anschlägt, ist dann wieder die Frage nach der Performance.


    Nebenbei gibts mit dem Check auf 0x47 eh noch ein Problem: Spätestens, wenn irgendwas CI+ 1.4 Multistream Support beherrscht (und ich hab dazu schon was in einem hier jetzt nicht näher spezifizierten GIT Branch gesehen - Forum Rules und so), kann man die SYNC Byte Detection vergessen, weil das als "Local TS Identifier" genutzt wird und einen anderen Wert als 0x47 annehmen kann. Siehe dazu https://www.dvb.org/resources/…/a165_dvb_ci_plus_1_4.pdf Chapter 6...

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • Ich weiß es wirklich zu schätzen, dass hier nochmal explizit auf das Problem mit den ngene Tribern eingegangen wird. Allerdings hab ich mittlerweile komplett auf neue Hardware, d.h. neues ASUS Mainboard und Cine-S2 v6.5 umgestellt (ddbridge-Treiber), womit es problemlos läuft. Ich kann versuchen, am Wochenende nochmal das alte System zu reaktivieren, muss dazu aber ubuntu, vdr und kodi komplett neu aufsetzen, Wenn ich das hinkriege teste ich und werde berichten ....

  • muss dazu aber ubuntu, vdr und kodi komplett neu aufsetzen, Wenn ich das hinkriege teste ich und werde berichten ....

    Das klingt ja mega aufwändig!

    Also ich will dich ja nicht bremsen, aber Daniel hat das schon sehr ausgiebig getestet und wenn das bei dir bedeutet das System nochmals umzustellen, dann würde ich das lassen.


    Auf der anderen Seite müsste es ja reichen die alten Karten in das neue System zu stecken und mal mit den orignal Treibern zu testen. Da müsste es dann Fehler geben. Dann steigst auf die neuen Treiber von nst um und dann sollte es gehen.


    LG,

    Jasmin

  • Ich kann versuchen, am Wochenende nochmal das alte System zu reaktivieren, muss dazu aber ubuntu, vdr und kodi komplett neu aufsetzen,

    Du brauchst da nichts neu aufsetzen. Karte ein- bzw. umstecken, cxd2099 anklemmen (oder umgekehrt), booten, Kernel-Module aus media_build generieren, ggf. /lib/modules/kernelversion backup'en, make install, (reboot, ) testen. Danach Backup wiederherstellen, Karte raus, neue Karte zurück, fertig.

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • Okay, vermute, das mit dem EInbau der alte Karte in das neue System sollte sich mit der Vorgehensweise bewerkstelligen lassen. Probeweise hab ich schon mal die Kernelmodule mittels

    Code
    git clone --branch buildall https://github.com/herrnst/media_build.gitst/dddvb-linux-kernel.git
    git clone --branch mediatree/master-ngene-tsfix https://github.com/herrnst/dddvb-linux-kernel.git
    
    cd media_build
    
    ./build_all.sh ../dddvb-linux-kernel/

    bauen lassen, was auch fehlerfrei durchgelaufen ist.


    Mal ne Frage wegen des Backups: Reicht es aus, das /lib/modules/4.13.0-36-generic Verzeichnis vor dem make install zu kopieren und hinterher wieder zurückzukopieren oder ist es besser nochmal die Kernel-Module für ddbridge zu erstellen und per make install die Dateien einfach zu überschreiben?


    P.S.: Hab jetzt mit "--branch buildall" erfolgreich bauen können. Vorher musste ich i.d.R. "--branch buildall-ioctl" nutzen, da es sonst nicht durchlief. Was ist der Unterschied und wie ist der aktuelle (empfohlene) Weg? Nutze Ubuntu 16.04.03 LTS (GNU/Linux 4.13.0-36-generic x86_64).

  • Mal ne Frage wegen des Backups: Reicht es aus, das /lib/modules/4.13.0-36-generic Verzeichnis vor dem make install zu kopieren und hinterher wieder zurückzukopieren oder ist es besser nochmal die Kernel-Module für ddbridge zu erstellen und per make install die Dateien einfach zu überschreiben?

    Mach einfach 'cp -pR /lib/modules/4.13.0-36-generic /lib/modules/4.13.0-36-generic.orig', dann hast Du 'n Komplettbackup vom funktionierenden Zustand. Dann 'make install', ggf. 'depmod -a' hinterher. Danach reboot, dann sind definitiv die neu kompilierten Module aktiv, "modprobe ddbridge" sollte Dir dann auch 'ne Version "0.9.32-integrated" ausgeben.


    Nach allen Tests kannst Du dann, wenn Du magst bzw. wenn notwendig, das .orig Verzeichnis zurückkopieren, rebooten und alles ist beim alten.


    P.S.: Hab jetzt mit "--branch buildall" erfolgreich bauen können. Vorher musste ich i.d.R. "--branch buildall-ioctl" nutzen, da es sonst nicht durchlief. Was ist der Unterschied und wie ist der aktuelle (empfohlene) Weg? Nutze Ubuntu 16.04.03 LTS (GNU/Linux 4.13.0-36-generic x86_64).

    buildall-ioctl hat einen Zusatzpatch/Buildfix für die Branches, die die IOCTL-Unterstützung (noch in Entwicklung) mitbringen, die zugehörigen Patches sind aber in den ngene-Branches nicht enthalten. Daher funktioniert buildall-ioctl hier nicht (sondern buildall), dafür funktioniert buildall nicht mit den IOCTL-gepatchten Sourcen :)


    EDIT: Oh, WICHTIG (ganz vergessen): Leg' Dir in /etc/modprobe.d/ unbedingt 'ne "ngene.conf" mit dem Inhalt "options ngene ci_tsfix=2" an, bevor Du rebootest, damit der Fix auch aktiv wird (da das direkt in den TS Transport eingreift, hab ich das vorab hinter 'ner Moduloption "versteckt").

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • 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.

    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.

    Diff
    --- 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.


    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?

  • VDR ist ein wirklich tolles Framework und seit der MTD-Unterstützung von Jasmin im ddci2 Plugin

    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.


    Das Problem liegt an einem TsIsScrambled() Aufruf, der bei den genannten Sendern tatsächlich häufiger true zurückliefert.

    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 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.

    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.


    Vielleicht sollte aber eher die Ursache des Problems analysiert werden, anstatt es nur zu kaschieren.

    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.


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

    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.


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


    LG,

    Jasmin

  • Danke für deine schnelle Antwort!


    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. :)


    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.


    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.


    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.


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

  • FYI, die hier zuletzt diskutierten TS Buffer Fixups wurden in linux-media gemerged und somit für Kernel 4.17 queued, siehe Treiber der Cine-CTv6/DDBridge/CI in den Kernel integrieren

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • Beide vorgeschlagenen Patches lösen das Problem.

    Sorry, aber Bits einfach löschen die ist keine Lösung. Man muss die Ursache finden.


    Ich habe mir mal schnell ddci2 nochmals angesehen und bei MTD ist die Erkennung von verschlüsselten Paketen nicht aktiv.

    Also ist mal sicher, dass es tatsächlich nicht entschlüsselte Pakete gibt. Nachdem der Audio/Video Strom bei Streamdev aber funktioniert, sind das wahrscheinlich andere Pakete.


    Jetzt wird es schwierig, weil ich nicht so sattelfest bin mit den Paket Typen.

    Ich würde mal eine Debug Ausgabe im VNSI Plugin dazu basteln, die die PID ausgibt, wenn TsIsScrambled true liefert (bekommst du mit dem Macro "TsPid"). Wenn die unter 0x20 ist, dann kann ich was damit anfangen.


    Allerdings nutzt uns das nicht viel ohne die PMT für das eingestellte Programm, wenn die PID >=20 ist.

    Wenn man den ganzen Stream irgendwie auf die Disk speichern würde, dann könntest du den mit "DVBinspector-1.9.0" analysieren. Der sagt dir dann auch welche PIDs was sind.

    Auf die Disk speichern bedeutet im VNSI Plugin an der Stelle wo die Daten rein kommen, alles in ein File zu schreiben. Musst googeln wie man ein File aufmacht und dann drauf schreibt (sorry, aber mehr kann ich dir nicht sagen, weil ich kaum Zeit habe und auch krank werde/bin).

    Ich vermute, dass da einfach irgendeine PID keine ECMs bekommt, weil VDR die zugehörige ECM PID nicht vom Mux bestellt und das CAM diese dann nicht entschlüsseln kann.

    Wenn diese noch immer verschlüsselte PID unwichtig ist, dann kann man die auch einfach im VNSI Plugin filtern. Wobei es besser wäre zu ergründen warum die überhaupt vom VDR kommt.


    Edit:

    Noch ne Idee: Das CAM braucht Zeit! Vielleicht ist VNSI nur zu ungeduldig.

    Ich hab jetzt nach dem ganzen geschreibsel nochmal darüber nachgedacht und verstehe nicht warum VNSI überhaupt TsIsScrambled so verwendet, dass es das CAM resetiert. Es mag ja sein, dass man verschlüsselte Pakete nicht via VNSI übertragen darf, also würde ich den Returnwert so ändern, dass dieses eine Paket schlicht verworfen wird und Punkt. Dann hat das keine Konsequenzen, weil der VNSI Client könnte damit sowieso nichts anfangen.

    Dann verkraftet das VNSI Plugin auch die anfänglich kommenden verschlüsselten Pakete. Und wenn die zwischendurch auch kommen sollten (siehe Hinweis zur PID Ausgabe weiter oben), dann kann man ja immer noch weiter untersuchen warum.


    LG,

    Jasmin


  • Ich kann mittlerweile auch bestätigen, dass der Fehler mit der Offsetverschiebung durch die Anpassung nicht mehr auftritt. Klaus Patch ist somit nicht mehr notwendig.

    Hatte allerdings einige Schwierigkeiten, das ganze für Kernel 4.14.12 zu kompilieren. Es gab hier Probleme mit em28xx-dvb.o. Bin dem aber nicht weiter nachgegangen und habe den Stand inkl. mitgeliefertem Kernel 4.15 kompiliert.

    ASRock J3455M | 8GB Ram | CineS2 v5.5 | Libreelec 9 | MLD4 als chroot in Libreelec

  • Ich kann mittlerweile auch bestätigen, dass der Fehler mit der Offsetverschiebung durch die Anpassung nicht mehr auftritt. Klaus Patch ist somit nicht mehr notwendig.

    Nun ja so einfach ist das nicht.

    Der Patch ist nur dann nicht mehr notwendig, wenn man einen ganz neuen Treiber aus dem media-git verwendet. Sprich The Bleeding Edge und noch nicht mal released.

    Hat jemand aber einen alten Kernel (Ubuntu 14.04 verwendet 3.13), dann braucht man den Patch schon.

    Und ich habe momentan keine Zeit mein media-build DKMS auf Stand zu bringen.

    Hatte allerdings einige Schwierigkeiten, das ganze für Kernel 4.14.12 zu kompilieren. Es gab hier Probleme mit em28xx-dvb.o.

    Der media-build ist wieder einmal kaputt. Ich arbeite aber daran, sonst kann ich kein neues DKMS releasen, weil das hätte ich geplant nach den ganzen tollen Erweiterungen im Kernel.


    LG,

    Jasmin

  • du hast natürlich recht, der VDR-Patch ist mit dem Stand aus nsts tsfix-Branch nicht mehr notwendig.

    Du solltest optimalerweise nochmal aus "mediatree/master" compilen und installieren, es ist mittlerweile alles im Upstream, und es gab noch ein paar Changes am Code. Sollte sich mit Deinem 4.14 oder 4.15 eigentlich derzeit sauber compilen lassen (ich compile selber gegen 4.15). EDIT: Achso, den ci_tsfix Modulparameter kannst Du dann auch streichen, das ist jetzt "Default an".


    Danke für Dein Feedback!

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • vnsiserver resettet den CAM, weil es CAMs gibt, die das brauchen. Das Auftauchen von verschlüsselten Paketen nachdem bereits unverschlüsselte angekommen sind, ist ein Indikator, des sich solche CAMs nicht mehr eigenständig regenerieren. Zugegeben ein workaround.

    Interessant wäre mal zu wissen, bei welchen streams das hier vorkommt. Vielleicht kann ja jemand m_streamContent, m_streamType in parser.c mit loggen. Dann wissen wir mehr.

Jetzt mitmachen!

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