Treiber der Cine-CTv6/DDBridge/CI in den Kernel integrieren

  • nst


    Super Job, großartige Arbeit, vielen Dank für Deine Mühen, die hier vmtl, wörtlich zu nehmen sind ... :tup


    Regards

    fnu

    HowTo: APT pinning

  • Hi nst


    Der linux-media Maintainer hat - bis auf eine Kleinigkeit, die aber keinem in der Praxis wirklich weh tun wird - ALLE(!) Patches, die sich im Laufe der Zeit "entwickelt" haben, in den Kernel gemerged. Mit anderen Worten: Linux Kernel 4.14, beginnend ab rc1, wird ddbridge in Version 0.9.31 mit vollständigem (CI-Bridge und MaxS8(!) inklusive) Kartensupport enthalten. Alle Digital Devices Tunerkarten und Flexmodule werden dadurch OotB funktionieren!


    Chapeau!


    Ich werde versuchen, die Sachen mal in einen 4.12 Kernel rückzuportieren, weil hier meine ganze Familie schon am Rad dreht wegen einer MaxS8, die nach Kernel-Update nicht mehr richtig funktioniert.


    Nachdem ich die MaxS8 seit 2 Jahren mit einem selbstgebackenen 4.2.5 und Oliver Endriss' experimental driver (ddbridge 0.9.18) weitgehend problemfrei einsetzte, war es aus verschiedenen Gründen an der Zeit, den Kernel zu aktualisieren. Da die experimental driver für aktuelle Kernel nicht mehr passen, fiel die Wahl auf dddvb 0.9.29 mit Kernel 4.11.11. Und siehe da, das Ergebnis war unbrauchbar. Kontinuierliche Pixelstörungen und Bewegungsartefakte im Sekundentakt. Zurück zu 4.2.5: alles bestens.


    Damit habe ich mich an den DD Support gewendet. Der hat nach einigem Hin und Her die Lösung gefunden: Firmware-Update!


    Vorher: DDBridge: HW 01010004 REGMAP 00010001

    Nachher: DDBridge: HW 0101000c REGMAP 00010002


    Es kam, wie es kommen musste. Nach der FW-Aktualisierung gab es die Störungen jetzt auch unter 4.2.5. :( Vielleicht wäre besser gewesen, Deinen Treiber zu verwenden, der z.Z. keine FW-Aktualisierung zulässt. 8o (Kidding)


    Aus nicht nachvollziehbaren Gründen versagt der DD Support nun aber den FW downgrade, sodass ich jetzt mit einem dysfunktionalen VDR dastehe (naja, der VDR funktioniert, nur sind die Sendungen/Aufnahmen hat nicht genießbar ;(). Ich baue gerade einen 4.12.8 mit ddbridge 0.9.31. Mal sehen, was da rauskommt.


    Ach ja, DD Support, Herr McPherson kann meine Argumentation, dass etwas faul im aktuellen FW-Stand ist, nicht nachvollziehen, und vermutet einen woanders gelagerten Software Fehler. ?(


    @* Kennt hier schon jemand dieses Verhalten? Welche FW Stände benutzt ihr? Ist vielleicht nur der letzte/die letzten DD FW Stand/Stände problematisch. Natürlich veröffentlicht DD nicht das Revisionslog der FW, somit bleibt nur trail & error.

    Wie verhält sich eure MaxS8, wenn der Rechner unter Last steht?


    HW: Xeon X3460, 24 GB RAM, ASUS P7F-E Motherboard, Areca ARC 1882IX-16 Hardware-RAID 5 mit HGST-Server Platten

    SW: heavily tweaked openSUSE 13.2, Kernel s.o., XFS FS, vdr 2.2.0

    VDR und vieles andere baue ich selbst auf dem OBS: z.B hier: https://build.opensuse.org/project/monitor/home:frispete:vdr


    Cheers,

    Pete

  • Bau die MaxS8 in einen Octopus Net Kit für SAT>IP ein, ist dann auch flexibler:


    - DigitalDevices DVB-S2 MaxS8 goes Octopus NET (SAT>IP mit 4/8 Tunern)


    Herr McPherson respektiert leider nur die Meinung von Herrn McPherson ...


    Regards

    fnu

    HowTo: APT pinning

  • Bau die MaxS8 in einen Octopus Net Kit für SAT>IP ein, ist dann auch flexibler:


    - DigitalDevices DVB-S2 MaxS8 goes Octopus NET (SAT>IP mit 4/8 Tunern)

    Danke für den Link. Das Produkt kannte ich noch nicht.


    DIe Idee, daraus eine SAT>IP Lösung zu bauen ist schon sehr verlockend. ;)


    Herr McPherson respektiert leider nur die Meinung von Herrn McPherson ..

    Nach einem längeren Telefonat mit ihm kann ich sagen: er ist sehr nett, kompetent, und hat letztlich die entscheidende Idee geliefert. :thumbup:Nach Umstecken von einem PCIe x4 in einen PCIe x 16 Port funzt die MaxS8 wieder einwandfrei. :rolleyes:


    Warum sie jahrelang im anderen Port problemlos funktionierte und mit dem neuen Kernel nach einem x16 Port verlangt, bleibt wohl den Untiefen der PC-Architektur geschuldet. (Hier mit msi=0). Funktioniert MSI hier bei euch (mit älteren MaxS8 Revisionen) und bringt es einen Vorteil?


    @DD-Developer: was an der Sache noch verbesserungswürdig ist: ich gehe mal davon aus, dass der Treiber sehr wohl irgendwo gemerkt hat, dass etwas nicht stimmt (sieht ja stark nach frame-losts aus). Schön wäre es, wenn er dann (rate-limited) Fehler/Hinweise ausgeben könnte, am Besten aktivierbar per Modul-Option... Solche Fehler können einen in den Wahnsinn treiben.


    nst: Ich freue mich mich sehr darauf, diesen Treiber bald im Mainline Kernel zu finden.

    Das ist ein Meilenstein in der fortgeschrittenen Linux-Multimedia Unterstützung und irre viel Arbeit, die Du da hineingesteckt hast.


    Cheers,

    Pete

  • frispete

    Für dein spezielles Problem machst du besser einen eigenen Thread auf, damit es hier nicht untergeht.

    Hehe, ist "schon" gelöst.


    Dieser Thread ist ja der Hammer. nst vollendet hier gerade eine Arbeit, die Du und andere vor 4 Jahren gestartet haben! :wow


    Nicht zu fassen. Daran sieht man, welche Mammutaufgabe Daniel hier geleistet hat. :cool1


    UND dann mal ein DANKE an euch alle! :applaus

  • Ich versuch gerade für meine ältere Cine S2 v5.5 die Treiber gem. Anleitung aus dem Wiki zu aktualisieren. Leider bricht das Kompilieren immer mit der folgenden Fehlermeldung ab:

    Code
    In file included from /usr/src/dvbdev.new/media_build/v4l/ddbridge-core.c:42:0:
    /usr/src/dvbdev.new/media_build/v4l/ddbridge-ioctl.h:22:34: fatal error: linux/ddbridge-ioctl.h: No such file or directory
    compilation terminated.

    noch vor ca. 1 Woche hat es mit dem zu der Zeit aktuellen Code geklappt. Habe den Kernel unter Ubuntu 16.04 schon auf 4.10. aktualisiert,

    Hat jemand noch einen Tipp für mich?

  • ihm fehlt die "linux/ddbridge-ioctl.h"


    schau mal ob die da ist. wenn nicht, beide "git clone" wiederholen.

    Dirk

  • ihm fehlt die "linux/ddbridge-ioctl.h"


    schau mal ob die da ist. wenn nicht, beide "git clone" wiederholen.

    Die Datei ist vorhanden:

    Code
    root@kodi-mc:/usr/src/dvbdev.new# find | grep "ddbridge-ioctl.h"
    ./media_build/v4l/ddbridge-ioctl.h
    ./media_build/linux/drivers/media/pci/ddbridge/ddbridge-ioctl.h
    ./dddvb-linux-kernel/include/uapi/linux/ddbridge-ioctl.h
    ./dddvb-linux-kernel/drivers/media/pci/ddbridge/ddbridge-ioctl.h

    Hab sie sogar händisch mittels

    Code
    cp ./dddvb-linux-kernel/include/uapi/linux/ddbridge-ioctl.h ./dddvb-linux-kernel/include/linux/ddbridge-ioctl.h


    in das include-Verzeichnis kopiert, wo die anderen Header-Dateien liegen. Trotzdem hängt es immer an derselben Stelle.

  • hmm, in dem Bereich wurde laut git vor 6 tagen geschraubt.


    aber wenn die meldung kommt, fehlt ihm die datei oder er sucht die an der falschen stelle.

    Dirk

  • Und was genau hat Dein Problem mit dem Topic, "Treiber der Cine-CTv6/DDBridge/CI in den Kernel integrieren" zu tun??

    Naja, unter anderem weil die Anleitung hier aus dem Thread kommt und auch weil hier schon vorher Probleme beim Kompilieren der Sources aus dem git von herrnst diskutiert wurden (z.B. Post #506ff). Wo würde es denn besser passen?


    Edit:

    Problem gelöst. Man muss die Datei nach media-build/v4l/linux kopieren. Dann geht es.


    Code
    cp ./dddvb-linux-kernel/include/uapi/linux/ddbridge-ioctl.h ./media_build/v4l/linux/ddbridge-ioctl.h
  • @All,


    bis einschliesslich heute sind noch diverse "Hotfixes" (übrige Patches) in linux-media gemerged worden (hauptsächlich Stabilitäts- und Stylefixes, und die alte CTv6 funktioniert jetzt auch problemlos mit w_scan) - alles Material für 4.14(rc1+).


    Basierend darauf wurden auch alle derzeit bekannten Probleme mit dem Buildsystem (media_build) gefixt. Die Doku im Wiki wurde entsprechend upgedated (neuer Branch beim media_build clone). Hinweis: Da keine "speziellen" Patches mehr für ddbridge notwendig sind, wurden die media_build Branches "ddb-alt" und "ddbridge" entfernt.


    Glückwunsch! Wer die linux-media ML kennt, weiss, dass das bestimmt kein leichtes Stück Arbeit war.

    Ehrlich gesagt: Weder die Liste noch die Maintainer waren in irgendeiner Form ein Problem. Das Einzige, was wirklich mürbe gemacht hat, war, dass der erste Satz Patches über vier Monate ohne Grund "vergammeln" musste, und der Rest auch mit gewissem Delay behandelt wurde (das nervt, wenn Patches pending sind, die auf den geposteten basieren, da das die Weiterarbeit behindert, wenn man nicht das Patchtracking-System vollmüllen will). Ansonsten alles gut, nix besonderes, was man nicht von anderen OSS-Projekten kennt, und die Maintainer waren zu jeder Zeit hilfreich und konstruktiv.


    Nicht zu fassen. Daran sieht man, welche Mammutaufgabe Daniel hier geleistet hat.

    Frag' besser nicht nach dem Gesamtzeitaufwand und der investierten Freizeit (in irgendeinem Post steht dazu glaube ich was)...

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

  • Damit es in Zukunft leichter für nicht so versierte Anwender ist die Treiber für ältere Kernel Versionen zu bauen, habe ich ein DKMS Paket gebaut.

    Details findet ihr in diesem Thread.

  • Abend zusammen,


    und - Ping Grillbert  Olsche (ich zieh die I2C Timeout Diskussion mal vom dkms Thread weg, das gehört da nicht hin)


    Ich würde Euch Zwei bitten, etwas Testcode auf Euren I2C-Timeout-geplagten Systemen auszuprobieren. Ich hab das IRQ Handling etwas refaktoriert, ob es allerdings wirklich was bringt, weiss ich nicht (und mittlerweile zweifel' ich immer mehr dran), aber die kleine Chance und so... Also:


    Code
    # git clone --branch buildall https://github.com/herrnst/media_build.git
    # git clone --branch mediatree/master-ddb0932-tryfixirq3 https://github.com/herrnst/dddvb-linux-kernel.git
    # cd media_build
    # ./build_all.sh ../dddvb-linux-kernel/
    # make install
    # reboot


    Bitte haltet ein Backup von /lib/modules/kernelversion bereit, was Ihr bei Bedarf zurückkopieren könnt, oder sorgt sonstirgendwie dafür, dass Ihr die Kernelmodule vom laufenden Kernel wiederherstellen könnt. Am Besten Auf jeden Fall vorher jegliche DVB-Treiber DKMS-Pakete deinstallieren. Und bitte auch sowohl msi=0 als auch msi=1 testen.


    Ich bin gespannt...

    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)

  • Hi,


    ich habe jetzt Kernel 4.14.0-041400rc5-generic am laufen. Nach anfänglichen Problemen mit Apparmor und Mysql sieht es jetzt ganz gut aus.


    VDR läuft jetzt seit 3 Stunden mit MSI=0 und beiden Tunern ohne Probleme. Auch heftiges hin und her schalten konnte die Karte bisher nicht aus dem Tritt bringen. Teste jetzt noch ein bisschen weiter und stelle dann mal auf MSI=1 um. Feedback folgt....


    Edit:

    Man soll nicht schneller schreiben als man lesen kann. Hatte den Beitrag mit dem GIT komplett überlesen und nur den neuen Kernel aus dem letzten Post installiert :-). MIttlerweile läuft der download aus dem GIT. Feedback zu den geänderten Treibern folgt.

    VDR1: YaVDR 0.6; OrigenAE S14V; ASUS M2N-PV VM; Mystique SaTiX-S2 V2 CI Dual; Athlon X2 5600+; Asus EN210 1GB DDR3; OCZ Vertex 32GB; WD Caviar Green 1,5 TB GB; 1GB Ram
    VDR Streaming Server: Debian 16.04; Ahanix D5 modded; Asrock j3455m, 4GB RAM; VDR-2.3.8; TVHeadend-4.2.3;

    Client 1-3: RPI2 mit MLD-5.4 unstable

    Einmal editiert, zuletzt von Olsche ()

Jetzt mitmachen!

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