Beiträge von nst

Was sagt denn "modinfo dvb-core", "modinfo videbuf2-vmalloc", "modinfo ngene", "modinfo ddbridge", "modinfo media", und im Vergleich modinfo eines anderen Modules, das derzeit geladen ist (eins aus lsmod), nachdem Du den media_tree mit media_build durchcompiled und installiert hast? Das riecht alles ein bisschen nach fehlenden oder falschen Headern zum Kernel...

Die ganzen Changes wurden im Upstream bereits akzeptiert und merged, und sind für das 4.17er Kernel Merge Window queued. Du kannst einfach aus dem upstream master Branch (per media_build) compilen:

# git clone --branch buildall https://github.com/herrnst/media_build.git
# git clone --branch mediatree/master https://github.com/herrnst/dddvb-linux-kernel.git
# cd media_build
# ./build_all.sh ../dddvb-linux-kernel/
(als root)
# make install ; depmod -a
# reboot

Zitat von cyjoe

ich habe auf Kernel 4.15 geupdatet (arch mit vdr4arch). Seitdem beschwert sich ddci2 mit:
DDCI-Inf: no DD CI adapter found

[...]

vdr-ddci2 1.0.1-2

Auch wenns hier um die alten ngene-Karten geht: ddci2 >= 1.0.4 installieren, ältere Versionen erkennen das vom Kernel-Treiber verwendete secX Devicenode nicht.

Wird interessant zu sehen, wie der PCIe Bus bei den Dingern mit den DD DVB-Karten zusammenspielt, v.a. wohl mit den CineS2 V7(A). Als Plattform für Mediaplayer und HTPCs auf jeden Fall hochinteressant, die Boards.

Wenn Du media_build von meinem GitHub Account geklont hast (https//github.com/herrnst/media_build.git), dann einfach nochmal frisch klonen, es ist alles rebased und alle Fixes von Jasmin, die den Tag über so reingewandert sind, sind da jetzt drin, sollte also alles klappen.

Zitat von Friedl

ich habe nochmal mit mediatree/master kompiliert und funktioniert ohne Modulparameter. Danke. Ich nutze aktuell den im master enthaltenen 4.16.

Super, danke Dir fürs Gegentesten (und viel Spass mit 'nem funktionierenden CI an der ngene-Karte ). D.h. Du hast jetzt direkt aus media_tree ein Kernel Image compiled und in Verwendung?

Zitat von Friedl

Allerdings klappt es mit Kernel 4.14 noch nicht. Hier hat es Probleme bei "apply_patches" gegeben, was ich aber noch nicht genauer analysiert habe.

Ja, in media_build ist derzeit ein bisschen was im Argen, bedingt durch die ganzen neuen Dinge, die im media Linux Tree gelandet sind.

EDIT: Nebenbei, das Problem mit der Pufferverschiebung ist wohl schon seit 2011(!) bekannt, siehe https://www.mail-archive.com/l….kernel.org/msg31736.html - ich finde es Bemerkenswert, dass sich da bislang niemand drum gekümmert hat, vor allem zu einer Zeit, als die Karten populärer waren...

Zitat von Friedl

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!

Der Support für die zusätzliche Hardware wurde heute in linux-media merged, siehe Treiber der Cine-CTv6/DDBridge/CI in den Kernel integrieren

Grillbert Wenn Du immernoch Dein DuoFlex S2 V4 testen magst (das wäre hochinteressant), dann bitte einfach den üblichen/bekannten media_build Vorgang anwerfen, aber beim Checkout von den Kernel Sourcen den Basis-Branch "mediatree/master" verwenden. Und, Hint: Das Flachbandkabel an der V5.5 mit der Farbmarkierung LINKS aufstecken - ich war mir da anfangs nicht sicher

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

Nabend zusammen,

da gerade sowas wie der "merge day" auf linux-media stattgefunden hat, hier mal die für ddbridge (und ngene) relevanten Dinge, die in Kernel 4.17 landen werden:

• Der cxd2099 Treiber (Flex CI Single Support) ist jetzt ein "sauberer" I2C Client Treiber, der obendrein die Regmap API verwendet - dadurch fallen die eigenen i2c_*() Funktionen komplett weg und es kommt Standard Kernel API zum Einsatz.
• cxd2099: Der Treiber ist aus staging/ jetzt zu den "stabilen" Frontends in dvb-frontends/ eingezogen. nanohcv und hoppel118 bzw. mindestens alle Debian und Fedora User bekommen den Treiber daher jetzt auch in den regulären Kernel Images mit
• Physical Layer Scrambling Support für den mxl5xx (MaxS8 4/8).
• Die MiniDiSEqC Burst Übertragung im stv0910 ist repariert.
• ngene: Der Treiber wurde generell an diversen Stellen etwas angehübscht (u.a. anständiges Kernel Logging).
• ngene: Der Treiber erkennt und unterstützt jetzt so ziemlich jede aktuelle DD DuoFlex Erweiterung, inkl. DuoFlex CT (stv0367-basiert), C(2)T2(I) (cxd2841er-basiert) und die DuoFlex S2 V4 (!) (letzteres ungetestet). Die Addons wurden an einer CineS2 v5.5 getestet. Ein Test an den alten DuoFlex PCIe (2-Port) vor allem am ersten Port steht noch aus, mehr als andere I2C Adressen für die Demods dürften aber nicht erforderlich sein (trivialer Patch). Unterstützung für die aktuellen DuoFlex CI wäre auch machbar, erfordert aber viel Codeduplizierung aus ddbridge und es ist nur einer von den CI Slots nutzbar, daher ist das NICHT implementiert.
• ngene: Das CI TS Buffer Offset Shift Problem hat einen Workaround erhalten. Die Buffer werden jetzt im Treiber dauerhaft auf TS SYNC Bytes geprüft und bei Bedarf Richtung DVB Core / Userspace neu ausgerichtet, wenn durch CAM Inits Verschiebungen stattfinden.
• ngene: Der DDCI-Support funktioniert jetzt auch mit TVheadend (jaja, das hier ist ein VDR-Forum...). TVH ist etwas penibler, was das Abholen von Daten vom CAM angeht (ts_poll). Das fehlte in ngene komplett und wurde jetzt nachgerüstet.

Die S2X Konstanten sollen laut den Maintainern mit einer Erweiterung der DVB Core API einhergehen und wurden daher zunächst nicht gemerged.

Ich push' die Tage noch 1-2 kleinere Fixups Richtung linux-media (nur kosmetische Dinge), und dann warten wir mal, was als nächstes so kommt.

Viel Spass damit,

nst

Super, dass an dem Treiber doch noch weitergearbeitet wird! Hint: Mach 'n GitHub Projekt daraus, macht das Codemanagement einfacher und ermöglicht anderen, bei Problemen direkt Fixes beizusteuern. Und Du kannst immernoch über die ganzen "magischen URIs" von GitHub Code-Tarballs bereitstellen, wenn es was zu testen gibt

Ah, die CTv6 und "NO MODULE" auf Port 0. Wenn Dir "modinfo stv0367" und "modinfo tda18212" was sinnvolles anzeigt: Power-Off, Power-Kabel ab (oder Kippschalter am Netzteil auf "aus"), 20 Sek. warten (bis sich die Kondensatoren entladen haben), dann alles wieder an. Wenn die Karte keine Macke hat, läuft dann alles.

Zitat von Grumpy

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.

Zitat von Grumpy

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

Zitat von Grumpy

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.

Zitat von HelmutB

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

Zitat von HelmutB

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

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.

Zitat von jasminj

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.

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

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.

Zitat von HelmutB

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

Zitat von HelmutB

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

Zitat von HelmutB

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

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

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.