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

  • Ich gehe davon aus, dass es NULL-Pakete sind, sonst hätte ihr Fehlen mit dem Patch von hier ja Aussetzern führen müssen.


    Nach dem Log von hier hat aber der VDR keine solchen Pakete an das CAM geschickt, denn sonst wären sie ja in der Form "CAM 1/1: mapped PID 6657 (1A01) to 256 (0100)" gelistet worden.


    Freilich könnte man jetzt einfach den Patch einbauen, aber ohne wirklich zu wissen, woher diese Pakete kommen, würde ich das gerne vermeiden. Ausserdem hat j anscheinend tatsächlich sonst niemand dieses Problem.


    Klaus

  • Na ja, TVH ignoriert solche Pakete auch, allerdings nur beim Lesen vom DVB Device.

    Auf der anderen Seite könnten diese aber auch vom ngene Treiber hinzugefügt werden, weil sonst keiner das Problem hat. Und wenn es das CAM erzeugen würde, dann würde das auch bei anderen auftreten.

    DD wird das im ngene Treiber nicht fixen und ich kann das nicht suchen, weil ich weder die Hardware, noch ein Datenblatt von der Karte und den verbauten Chips habe.


    Selbst wenn es ein Treiber Problem ist, so kann man keine existierenden alten Kernels patchen, somit sollte es das UserSpace Program entfernen, so wie TVH das auch tut.


    Man könnte es auch ins ddci2 Plugin einbauen, aber:

    Ich weiß jetzt nicht ob der ngene Treiber auch das redirect unterstützt, aber falls ja, dann muss man das im VDR filtern, weil man dann ohne ddci2 Plugin arbeitet.


    LG,

    Jasmin

  • Nach dem Umstieg auf die Cine-S2 V6.5 läuft es bei mir super stabil. Da ich nur dieses eine System habe, kann ich leider nur mit Mühe zurückbauen. Wenn jemand mehr Möglichkeiten/weitere Systeme zum Testen hat, stelle ich meine V5.5 gerne zur Verfügung.

  • Ich kann gerne ein Droppen dieser Pakete beim Lesen vom DVB-Device einbauen.

    Hat eigentlich jemand getestet ob die NULL Pakete aus dem DVR Device gekommen sind oder vom CI/SEC Device, also nach dem CAM?


    Aber anscheinend haben wir inzwischen kein System mehr, auf dem dieses Problem auftritt und mit dem wir es testen könnten.

    Na ja, Daniel bekommt eine ngene Karte, aber ich weiß nicht ob er Zeit hat sich das anzuschauen.
    Wichtig wäre eben zu wissen woher die NULL Pakete kommen, weil im TS Stream vom Satelliten sind die nicht drinnen.

    Und wenn du den Filter nur nach dem DVR Device lesen einbaust, es wird aber vom CI/SEC Device produziert, dann haben wir die Pakete immer noch. Man müsste also auch die Pakete die aus Decrypt heraus purzeln auf NULL Pakete untersuchen.


    LG,
    Jasmin

  • Decrypt() sollte aber doch nur die Pakete, die reingehen, ggf. entschlüsseln und wieder zurückgeben, und nicht neue "dazuerfinden" ;-).


    Wenn wir genau wissen, was passiert, und der Fehler nicht anderweitig gefixt werden kann, dann sehen wir weiter mit dem Löschen von NULL-Paketen im VDR.


    Klaus

  • Ich habe zwar keine entspechende Hardware, aber wenn ich den ngene-Treiber richtig lese werden die

    TS-Null Pakete in ngene-core.c von der Funktion "FillTSBuffers()" erzeugt.


    Diese Funktion wird einerseits von "clear_buffers(struct ngene_channel *chan)" zum initialisieren der Ringbuffer aufgerufen, zum anderen wird sie in ngene-dvb.c von "tsout_exchange(void *priv, void *buf, u32 len, u32 clock, u32 flags)" zum Auffüllen eines TS Buffers bis zur gewünschten Größe verwendet bevor dieser dann zum CI gesendet wird.


    Die Funktion "tsin_exchange(void *priv, void *buf, u32 len, u32 clock, u32 flags)" versucht dann die TS-Null Pakete die vom CI

    kommen wieder zu entfernen.


    Hier die Funktion FillTSBuffer, die den Buffer zuerst mit dem Wert 0x6F (TS_FILLER) füllt und dann in gewissen Abständen des 4-byte TS-Null Header 0x47, 0x1F, 0xFF, 0x10 einfügt.


    Hier kommt mir allerdings seltsam vor, dass der Pointer für den TS-Null Header um 188/4 - also 47 bytes verschoben wird, der Längenzähler aber um die Länge eines ganze TS-Pakets mit 188 bytes verringert wird..

    Das würde bedeuten, das nur das 1. Viertel der erzeugten TS-Null Paktete eine gültigen Header hat, der Rest besteht nur aus den Werten 0x6F die tsin_exchange() dann nicht als Null-Paket erkennt und durchlässt.


    Falls jemand den Treiber verwendet, ev. könnte ein "ptr += 188;" etwas verbessern.

    LG

    Helmut

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

  • Nein das passt so, weil "ptr" ein "u32 *" ist und somit ein += 1 in wirklichkeit den Pointer um 4 Byte verschiebt.

    Deshalb muss man eben "+= (188/4)" schreiben, wenn man den Pointer um 188 Bytes verschieben möchte.

    Die Length ist aber die Länge in Bytes und deshalb gehört dort ein "+= 188".


    Einer der Pitfalls bei der Pointer Arithmetik in C ;)


    LG,

    Jasmin

  • Da hast du natürlich recht - es war dann doch schon zu spät um noch klar zu denken.


    Es hätte das Problem aber eh nicht gelöst, da die selbst erzeugten Null-Pakete ja von tsin_exchange() wieder entfert werden und es keines bis zum VDR schaffen sollte.


    Man müsste sich in mdt.c beim einer PID von 0x1FFF das 5. Byte des Pakets ansehen - bei enem Wert von 0x6F würde kommt es definitiv vom ngene Treiber - aber wie ?


    LG

    Helmut

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

  • Das ist der Treiber für die schon ältere Cine Dual -S2 PCI Sat-Karte mit unterstützung für ein Digital-Devices CI-Interface (über caX und secX).

    Soweit ich den Treiber verstehe:

    Das schreiben zum CI-Interface erfolgt immer mit genau 4096 TS-Paketen. Wenn im TSout-Buffer nicht genügend Pakete vorhanden sind wird mit TS-Null Paketen aufgefüllt, diese Null-Pakete haben eine beondere Kennung am Datenblock - 0x6F.

    Beim Lesen vom CI werden diese selbst generierten Null-Pakete dann wieder verworfen.

    Warum es genau 4096 Pakete sein müssen ist mir nicht ganz klar, ich sehe nur das die TSin/TSout Ringbuffer auch 4096*188 bytes groß sind.


    LG

    Helmut

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

  • Moin,


    ich hab jetzt hier 'ne

    Code
    [  112.602687] nGene PCIE bridge driver, Copyright (C) 2005-2007 Micronas
    [  112.602788] ngene: Found Linux4Media cineS2 DVB-S2 Twin Tuner (v5)
    [  112.605245] ngene: Device version 1
    [  112.605290] ngene: Loading firmware file ngene_18.fw.
    
    PCI ID: 18c3:0720 (rev 01) Subsystem: 18c3:dd00

    in der Bastelkiste stecken. Die Onboard-Tuner haben offenbar keine Lust (No STV0900 found - ist das irgendwie fixbar, z.b. durch neuere Firmware, oder hat die Karte dann 'ne Macke? Anderen PCIe Slot schon probiert, mit/ohne Stromversorgung, mit/ohne angeklemmtes Addon; Ein Test mit Windows wird definitiv nicht passieren! EDIT: Spontane Selbstheilung oder Fix durch passende I2C Caps im Adapter? Die zwei STV090x sind jetzt plötzlich da...), mein CXD2099 wird aber erkannt, meldet ein gestecktes ACL R2.2@One4All2.4 und ich kann im CAM Menü (gnutv, VDR UI) rumspielen.


    TVH+DDCI bringt aber so ziemlich gar keinen Output, VDR+DDCI kotzt sich mit "ERROR: invalid MTD number (31) in PID 8191 (1FFF)" im VDR Log aus, aber zumindest gibts am VNSI-Client (Kodi) Pixelmatsch mit Andeutungen von 'nem entschlüsselten Bild. Ich vermute, dass die "Rückfilterei" in tsin_exchange() nicht das tut, was sie soll. Ich hab' im Moment nicht wirklich Zeit (und auch nicht wirklich Lust; ich will die Karte bzw. die Treiber lediglich mit neueren Flexmodulen - STV C/T, CXD C2T2, ggf. DuoFlex S2 V4, das muss aber wer gegentesten) kompatibel machen. Wenn sich jemand mit dem Code beschäftigen mag und Dinge getestet haben möchte, kann der/diejenige mir aber gerne Patches zukommen lassen, ich kann das dann zwischendurch testen.

    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)

    Einmal editiert, zuletzt von nst ()

  • Nachtrag (Cc/Ping kls dazu):


    Wenig überraschend funktionierts mit dem NULL Packet PID Filter Patch in mtd.c (kein Pixelbrei, kein Spam in vdr.log). Stream-Kette: DVB-C/Kabel an CineCTv6 STV0367@ddbridge, Entschlüsselung via cxd2099 Flex am ngene Expansion Port. EDIT: MTD mit zwei Services auf unterschiedlichen Muxen (1x Playback, 1x Record) funktioniert sauber.

    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,

    wenn man sich die Daten der TS-Null Pakete ansehen könnte, hätte man vielleich einen Hinweis auf dei Quelle.

    Hier eine Erweitern der MTD Fehlermeldung in der originalen mtd.c :

    Die ersten 8 Bytes werden dabei nach der Pid als zwei 32-Bit Werte ausgegeben.

    Vielleicht willst du das einmal probieren.


    Helmut

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

  • Ich bin da schon 'n Stück weiter. Das NULL Zeugs wird definitiv im Treiber generiert, damit der Ringbuffer und das ganze Zeugs immer was zu tun hat. In ngene-dvb.c:tsout_exchange() werden dazu die Daten abgeholt und in die Transferbuffer geschrieben. Wenn nicht genug Daten da sind, um so 'nen Buffer vollzuschreiben, wird mit ngene-core.c:FillTSBuffer() der Rest mit den hier diskutierten NULL Frames aufgefüllt, und der komplette Buffer dann zur Hardware geschickt.


    Das Zeugs wird dann via ngene-dvb.c:tsin_exchange() wieder Richtung Treiber und DVB Core zurückgeschickt. Der Check mit dem memcmp() sollte eigentlich dafür sorgen, dass die eingefügten NULL Frames nicht rücktransportiert werden. Das funktioniert aber nicht, weil das memcmp() Konstrukt erwartet, dass die gelieferten Buffer immer mit einem kompletten TS Frame (beginnend mit TS Sync 0x47) anfangen, dies aber nicht der Fall ist. Ein Kurztest hat hier schon gezeigt, dass das Syncbyte *irgendwo* liegen kann. Man könnte jetzt hingehen und beim ersten Erreichen von tsin_exchange() das Offset ermitteln, und das dann irgendwie in den Datentransport einwurschteln. Da ergibt sich aber ein weiteres Problem: Beim Test hat ein simples "systemctl restart vdr" dafür gesorgt, dass sich das Offset einfach mal an eine andere Stelle verschoben hat, also irgendwo irgendwie eine Art Gap entstanden ist. Das wird also nicht sauber funktionieren, und dauerhaft die Buffer durchscannen dürfte zu Performance-Penalties führen.

    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)

  • Sehr eigenartig.

    Ist der Offset gleich zu Beginn und bleibt dann gleich (also immer +188 bytes) , oder "bewegt" sich das SYNC byte ?

    Auf jedenfall ist irgendwann der tsin-Ringbuffer nicht auf SYNC ausgerichtet , dann sollte es doch zumindest einmal eine Fehlermeldung von ddci2 mit "skipped xx bytes to sync on start of TS packet" geben. Hier wird immer nur die MTD Meldung erwähnt - oder habe ich sie überlesen.


    Helmut

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

  • Aktuelle Erkenntnisse hierzu:


    • Unmittelbar, nachdem der Treiber geladen wurde (modprobe/insmod ngene), passt das TS SYNC Byte auf Offset 0. Die Schleife mit dem FillTSBuffer geht direkt los, wenn die Hardware den Status "Running" erreicht.
    • Sobald das gesteckte CAM gefunden und erstmalig vom EN50221 DVB Subsystem initialisiert wurde (VDR läuft zu der Zeit noch nicht! Kernellog: "dvb_ca_en50221: dvb_ca adapter 10: DVB CAM detected and initialised successfully"), "shifted" das Offset das erste mal. Das sind bisher immer vier Bytes, TS Sync ist also immer an Offset 4 im Kernellog-Hexdump des Buffers
    • VDR Start mit DDCI: Es shifted nochmal, diesmal um deutlich größere Happen. %*ph dumpt nur max. 64 Bytes, da ist manchmal kein TS Sync mehr enthalten (ist also um mehr als 64 Byte verschoben). Das Offset, was hier entsteht, ist aber variabel.
    • Channel Playback/Decryption ändert das Offset dann nicht.
    • Nochmal Treiber entladen und neu laden, warten, bis CAM initialisiert ist (Offset dann wieder bei 0x04). "gnutv -adapter 10 -cammenu" (also auf der Shell das CAM Menü aufmachen) schiebt das Offset dann wieder sonstwohin. Das CAM Menü durch"zappen" hat keinen weiteren Einfluss

    Das sieht für mich ziemlich deutlich danach aus, als würde der Transport vom CAM Control (?) Einfluss auf den Ringbuffer haben. Ich frage mich derzeit, ob sich das irgendwo in den Transfer-Funktionen von ngene wiederfindet, und man 1.) sich entweder so entstehende Offsets merkt und in tsin_exchange() berücksichtigt, oder 2.) (wäre wesentlich cooler) derartige CAM Control Transfers auf durch 188-Byte teilbare Häppchen strecken lässt und so erst gar kein Offset entsteht, weil immer konstant 188 Byte vom/zum Ringbuffer transportiert werden. Ich hatte dazu zwischenzeitlich in tsout_exchange() und tsin_exchange() Debug eingebaut, der sich meldet, wenn die zu übertragenen Buffergrössen nicht glatt durch 188 teilbar sind. Resultat: Nix im Kernellog...

    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)

  • Ah, jetzt weiß ich wofür dieser Idle-Buffer gut ist - er beschäftigt das CAM obwohl es eigentlich gar nichts zu tun gibt.

    Hilft jetzt aber auch nicht weiter.


    Von der CAM-Control habe ich eigentlich nicht entdeckt - das läuft ja über den cxd2099, und ob das den selben Speicher/Buffer nutzt wie die TS-Daten würde mich wundern - möglich ist natürlich alles.

    Den Offset in tsin_exchange() einfach zu überspringen wird auch nicht gut funktionieren da dann zwangsläufig das unvollständige (<188 byte) TS-Paket am Ende nicht mehr in den Tsin Ringbuffer geschrieben wird. Man verliert also bei jedem exchange 1 TS-Paket.

    Im Moment fällt mir auch nicht mehr ein, außer noch einmal über den Code zu schauen.


    Vielleicht kannst Du noch vergleichen ob es sich mit einem anderen CA-Modul genau gleich verhält.


    Helmut


    Edit:

    Doch noch was eingefallen: Kann man aus den 4 oder mehr Bytes vor SYNC irgendetwas erkennen - z.B Reste des NULL-Pakets (0x6F) oder Fragmente einer Control - Kommunikation?

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

    Einmal editiert, zuletzt von HelmutB ()

  • Ah, jetzt weiß ich wofür dieser Idle-Buffer gut ist - er beschäftigt das CAM obwohl es eigentlich gar nichts zu tun gibt.

    Nein das ist nicht der Grund.
    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.


    Den Offset in tsin_exchange() einfach zu überspringen wird auch nicht gut funktionieren da dann zwangsläufig das unvollständige (<188 byte) TS-Paket am Ende nicht mehr in den Tsin Ringbuffer geschrieben wird. Man verliert also bei jedem exchange 1 TS-Paket.

    Ein Paket verlieren geht gar nicht, dann ist der Stream kaputt!

    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 der Offset noch passt. Das kann man aber recht billig lösen und macht das ddci2 Plugin auch.


    LG,
    Jasmin

    Einmal editiert, zuletzt von jasminj ()

  • Ah, jetzt weiß ich wofür dieser Idle-Buffer gut ist - er beschäftigt das CAM obwohl es eigentlich gar nichts zu tun gibt.

    Hilft jetzt aber auch nicht weiter.

    Ich hatte BTW mal testhalber das Auffüllen des Buffers wegrationalisiert. Das sah beim Entschlüsseln nicht wirklich toll aus auf dem Monitor (Verpixelung/Matsche vom feinsten), und beim Idlen hat das CXD2099 irgendwann "NO CAM" gemeldet, das CAM hatte da wohl keine Lust mehr... Ohne gehts also nicht.


    Den Offset in tsin_exchange() einfach zu überspringen wird auch nicht gut funktionieren da dann zwangsläufig das unvollständige (<188 byte) TS-Paket am Ende nicht mehr in den Tsin Ringbuffer geschrieben wird. Man verliert also bei jedem exchange 1 TS-Paket.

    Ja. Die Variante hatte ich hier vorhin mal implementiert. Jedes 512te TS Paket wird dadurch beschnitten und der resultierende Datenstrom dadurch unbrauchbar. Man müsste jetzt optimalerweise noch 'nen weiteren Buffer-Layer ontop stricken, der über zwei tsin_exchange() Aufrufe hinweg den Strom wieder richtet und den Rest vom ersten Buffer vom Anfang des zweiten einsammelt und an den rekonstruierten Buffer setzt, und das dann zum nächsten (DVB) Layer weiterschickt. Da hörts aber ehrlich gesagt dann auch mal auf...


    Vielleicht kannst Du noch vergleichen ob es sich mit einem anderen CA-Modul genau gleich verhält.

    Hab nur das eine CAM hier (ACL R2.2 mit One4all 2.4).


    Doch noch was eingefallen: Kann man aus den 4 oder mehr Bytes vor SYNC irgendetwas erkennen - z.B Reste des NULL-Pakets (0x6F) oder Fragmente einer Control - Kommunikation?

    Ja: Nach dem ersten Shift (beim CAM Detect/Init, um vier Bytes) sind die vier Bytes mit den TSFILL-Bytes (0x6f) aufgefüllt, als wäre das gesamte TS-Päckchen 192 Bytes lang

    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)

Jetzt mitmachen!

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