Beiträge von jasminj

    Hallo!


    Ich habe es endlich geschafft ein DKMS Paket für media_tree/media_build zu machen.

    Es funktioniert zwar bei mir und nst, aber es ist trotzdem Alpha-SW. Ich brauche noch einige Freiwillige die das Paket testen.


    Dieses neue DKMS kann eine bestimmte Kombination von media_tree (genauer dddvb-linux-kernel) und media_build auf einem System installieren. Welche Kombination das ist legt man beim Erzeugen des DKMS Source Paketes fest. Das fertige Source und auch Binary Paket enthält bereits die ganzen Treiber aus media_tree und es muss nichts mehr aus dem iNet geladen werden, wenn man das DKMS installiert.


    Auch wenn ich oben dddvb-linux-kernel erwähnt habe, so beinhaltet das Paket alle(!) derzeit in media_tree verfügbaren Treiber und ein paar Zusätze für die DD Karten, die noch nicht in media_tree integriert wurden. media_build muss ja auf den verwendeten media_tree angepasst werden und deshalb ist die Kombination wichtig. Die derzeit erste verfügbare Kombination ist für alle Kernels bis 2.6.36 zurück fehlerfrei compilierbar!


    Der normale User braucht nur das DKMS Paket aus meinem PPA zu installieren. Es ersetzt automatisch alle anderen verfügbaren DVB Treiber Pakete.

    Das sind:

    s2-liplianin-dkms, v4l-dvb-dkms, linux-tbs-drivers-dkms, linux-media-tbs-dkms, linux-media-dkms, media-build-experimental-dkms, dddvb-dkms


    Falls irgend jemand wissen will wie das alles genau funktioniert, also wie man das DKMS aus einer media_tree und media_build Version bauen kann, bitte ich die entsprechende Doku (README_DKMS) in den entsprechenden Git Repos auf GitHub zu lesen.


    Die fertigen Pakete für die Ubuntu LTS Pakete sind in meinem PPA zu finden:

    https://launchpad.net/~jasmin-…e/ubuntu/media-build-dkms


    Zur Installation sind diese Schritte erforderlich:

    Code
    add-apt-repository ppa:jasmin-jessich/media-build-dkms
    apt-get update
    apt-get install media-build-dkms

    Nicht wundern, das compilieren und installieren der Module dauert wirklich lange! Es wird auch versucht die vorhandenen CPU-Cores ans Limit zu fahren, aber auf meinem Single Core AMD Sempron dauert das doch über eine Stunde.

    Man darf nicht vergessen, dass für Kernel 3.13 616 Module gebaut werden und für Kernel 4.12 sind es noch mehr.

    Nach der Installation sollte man rebooten, weil alle DVB Module getauscht werden und ev. noch in Verwendung befindliche Module nicht automatisch entladen werden.


    Es wird mit diesem DKMS keine Firmware installiert!

    Wenn man DVB Karten hat die eine Firmware benötigen, so muss man diese über andere Pakete installieren!


    Ein "dkms uninstall media-build ..." dauert sehr sehr lange. Das bekommt man dann zu spüren, wenn man einen älteren Kernel deinstalliert, für den irgendwann die Module gebaut wurden. Vielleicht finde ich dafür ja noch eine Lösung.



    ACHTUNG:

    Man benötigt eine DKMS Version, die das "POST_BUILD" Macro unterstützt!

    Siehe DKMS Git (https://github.com/dell/dkms)

    Code
    Commit 8653e9f44145bbf von
    Darik Horn am 27. Feb. 2012
    Add POST_BUILD to the dkms_conf_variables list.

    Die derzeit in yaVDR stable verfügbaren Version kann das nicht!

    Man muss das Ubuntu Paket über das yaVDR Paket installieren (downgraden) und danach das update desselben verhindern

    Code
    apt-get install dkms=2.2.0.3-1.1ubuntu5.14.04.9
    apt-mark hold dkms

    Ich würde die yaVDR Maintainer bitten auf eine neuere DKMS Version umzusteigen oder das Paket ganz aus dem Repo zu entfernen.


    Wenn die yaVDR Maintainer dieses Problem gelöst habe, kann man das Updaten des Pakets wieder erlauben

    Code
    apt-mark unhold dkms
    apt-get upgrade

    Für die noch ältere Ubuntu Version Precise, muss man angehängten Patch auf das installierte dkms Script anwenden. Das muss aber als root gemacht werden!


    Angehängten Patch nach "/tmp/dkms.patch" speichern und mit folgenden Kommandos anwenden:

    Code
    $ cd /usr/sbin
    $ sudo patch -p1 < /tmp/dkms.patch
    $ sudo chmod a+x dkms



    Wo findet man die Sourcen:


    Die Scripte um Ubuntu/Debian Pakete zu bauen:

    https://github.com/jasmin-j/media-build-dkms


    Die DKMS Variante von media_build:

    https://github.com/jasmin-j/media_build/tree/dkms-master

    bzw. https://github.com/jasmin-j/me…ree/dkms/0003-08_Sep_2017


    Die im DKMS verwendete media_tree Variante:

    https://github.com/jasmin-j/dd…rnel/tree/master-ddbridge

    bzw. https://github.com/jasmin-j/dd…ree/dkms/0003-29_Aug_2017


    Die Versionen von dddvb-linux-kernel für die DKMS Pakete werden immer auf einem Branch "dkms/????-" abgelegt. Selbiges gilt auch für die Versionen von media_build. Der Ursprung aller dkms Branches in media_build ist aber dkms-master.

    Warum es Branches für die einzelnen DKMS Versionen gibt steht in README_DKMS.



    Insiderwissen für Interessierte:


    Die Problematik an der ganzen Geschichte war DKMS zu überlisten eine beliebige Anzahl von Modulen zu installieren. Das deshalb, weil media-build abhängig von der Kernel Version verschieden viele Kernel Module erzeugt. Normalerweise würde man in dkms.conf jedes einzelne Kernel Modul aufzählen, das funktioniert nur bei media-build nicht, weil eben die Anzahl der Module von der Kernel Version abhängt.


    Der Trick ist mit einem POST_BUILD Script (gen_dkms_dyn_conf.sh) die erzeugten Module nach dem Build Step zu finden und dkms.conf entsprechend zu ändern. Um genauer zu sein, es wird eine Datei dkms_dyn.conf generiert, welche von dkms.conf includiert wird, wenn sie existiert. Außerdem müssen die compilierten Kernel Module auch noch von einem Script in das module Verzeichnis kopiert werden, weil DKMS das in dem Fall nicht automatisch tut.


    Beim install Step von DKMS existiert das File dkms_dyn.conf dann und DKMS installiert schön brav alle Module die in dkms_dyn.conf stehen. Das ist auch die Erklärung warum eine DKMS Version mit POST_BUILD Support gebraucht wird.


    LG,

    Jasmin


    Updates (2017-Sep-10):

    lirc_serial wurde auf serial_ir umbenannt. Es muss also die Lirc Konfiguration angepasst werden.

    Siehe hierzu den Beitrag von Paulaner.


    Updates (2017-Dez-28):

    Vor der Installation solltest ihr unbedingt alle nicht mehr benötigten Kernel Versionen entfernen, weil das DKMS für jede installierte Kernel Version gebaut wird und das wirklich Stunden braucht!


    Und das De-Installieren braucht ohne dem DKMS Speed Patch extrem lange!

    Aha, der Treiber wuerde also die Zukunft des Kernels gefaehrden!?

    So hab ich das nicht gemeint!

    Ich lese ja mit was Mauro schreibt und ein wenig kommt mir vor, er würde die alten APIs irgendwie loswerden wollen. Ich hoffe schon, dass der Treiber rein kommt, weil ich für die Integration existierender Treiber bin.

    Du musst dich halt auf eine längere Diskussion einlassen. Haben wir beim DD Treiber auch müssen.


    Ich haette die Updates doch fuer mich behalten sollen...

    Also diese Reaktion verstehe ich jetzt nicht.

    Es ist großartig, dass du das angegangen bist!!!

    Es ist sehr mühsam zu versuchen einen Treiber in den Kernel zu bekommen, aber wichtig für alle diejenigen, die solche Karten noch verwenden.


    LG,

    Jasmin

    Ich hoffe der Treiber für die FF HD 6400 wird demnächst im Kernel landen.

    Na schau ma mal, ob das jemals in den Kernel kommt. Mauro muss ja auch die Zukunft im Auge behalten.


    Ich bastle gerade an einem DKMS für media-build und bin damit eigentlich schon fertig, aber es muss noch auf Launchpad. Wenn man mich ganz lieb bittet und die Patches von Sören problemlos passen, dann könnte ich das in das media-build-dkms dazu nehmen.


    LG,

    Jasmin

    Welcher Unterschied besteht zwischen den Treibern, die aus den unterschiedlichen Repositories gebaut werden und welches ist für welchen Fall zu empfehlen?

    Die offiziellen Kernel Treiber werden in media-tree gehostet. Das ist so etwas wie ein Release Branch. Das kommt von Zeit zu Zeit in den Linux Kernel rein.

    Dazu passend gibt es dann media-build. Das wird benötigt um die Treiber von media-tree parallel zu einem installierten Kernel zu bauen. Das muss immer zu den Sourcen in media-tree passen.


    Das Repo von herrnst ist die Quelle für die Kernel Version des DD Treibers und ist damit so etwas wie ein Integration Branch. Dort findest du die neuesten Dinge bevor sie in media-tree akzeptiert werden. Dazu passend gibt es auch ein media-build. Und dann gibt es auch noch meine Kopie des Repos von herrnst, wo ich dann die CI Treiber für media-tree vorbereite.


    nst und ich arbeiten hier sehr eng zusammen und ich bin erstaunt wie gut das funktioniert hat.


    Und zum Schluss gibt es noch den Ursprung von allem, das offizielle DD Repo. Von dort kommen die Treiber ursprünglich, wurden dann an den DVB Core in media-tree angepasst und eben in den Kernel integriert.

    Die Treiber in dem Repo können aber nur DD Karten und keine anderen parallel.


    LG,

    Jasmin

    Ich vermute daher, dass es meine alte v5.5 einfach nicht gut mit dem ddci2 tut.

    Ich habe den ngene Code mal kurz überflogen, aber was gefunden hab ich nicht.

    Ich kann dir aber sagen, dass der ddbridge Treiber auch ein paar Verbesserungen meinerseits gebraucht hat, bevor der so funktioniert hat wie gedacht. Diese speziellen Dinge hab ich zwar im ngene Treiber nicht gefunden, aber ich vermute trotzdem, dass es am Treiber und nicht an der Karte liegt.


    Auf der anderen Seite ist ein neue DD Karte nicht so teuer und sowohl die Octopus CI, als auch die Cine V6.x funktionieren alle mit ddci zusammen. Wie gesagt, die Treiber wurden eben verbessert, um das ciX/secX Device richtig zu bedienen.


    Auch die Verwendung der nst-Treiber hat zwar weniger Fehler, aber letztlich doch nicht die gewünschte Stabilität gebracht. Seit dem Umstieg auf CI und ddci2-Plugin häufen sich die Bild- und Aufnahmefehler auf meinem System.

    Wie hast du denn bisher geschaut?


    Leider wird die v6.5 nicht konstant von meinem Mainboard erkannt (bekanntes Problem mit Intel MB DH61AG, was sich leider nicht lösen lässt - wie sich erst jetzt heraus stellte) und so bleibt mir aktuell wohl keine andere Option als mich erstmal mit dem jetzigen Zustand anzufreunden

    Scharrn! Das klingt nicht nach eine Lösung!

    Und das MB tauschen?

    Weil wenn das MB mit der Cine Probleme hat, dann wird es diese sehr wahrscheinlich auch mit einer Octopus CI haben, sind da doch sehr ähnliche Komponenten verbaut.


    Mich würde trotzdem weiterhin interessieren, ob diese Combo hier irgendjemand anderes stabil am Laufen hat.

    Bei mir läuft eine Cine S2 V6 mit einem DuoFlex CI (single) und auch wahlweise mit einem DuoFlex CI (dual). Das ist mein Entwicklungssystem und auch bei längeren Aufnahmen habe ich keine Probleme bemerkt.


    LG,

    Jasmin

    Aber wenn man das will muss man schon Enthusiast sein - denn sind wir mal ehrlich Tvheadend bietet da mehr und einfacher.

    Wer ein CAM für die Entschlüsselung der Sender benötigt und zugleich Schauen und aufnehmen will und dafür nur ein CAM verwenden möchte, der kommt unter Linux an VDR nicht vorbei!


    Mir ist derzeit keine andere SW unter Linux bekannt, die MTD (Multi Tuner Decoding) unterstützen würde.


    Und ja es gibt einen Request das in Tvheadend zu implementieren, aber das wird wohl noch länger dauern und ich habe schlicht keine Bock das zu machen. Ich würde zwar einen ev. Entwickler bei Frage unterstützen, aber wozu soll ich VDR den Rücken kehren, wenn man mit VDR als PVR Backend mit Kodi alles tun kann?

    Und Aufnahmen oder Live Bild schaue ich immer über VDR. yaVDR als Distribution bietet alles was ich brauche und das schnelle Umschalten auf Kodi geht dort per Taste auf der FB.


    LG,

    Jasmin

    2. Mit der Einstellung "--bufsz 500" scheinen auch die Fehlermeldungen aus dem syslog verschwunden zu sein.

    Also das verstehe ich jetzt nicht!

    Der Buffer im Plugin ist 1500 Pakete groß und du hast diesen jetzt kleiner gemacht. Warum das helfen sollte ist mir total unklar.

    Hast du ev. das "-A" Flag gesetzt? Das würde nämliche den Buffer nicht löschen, wenn der VDR ein Stop/StartDecrypting macht und dann könnten alte Daten in den Buffern stehen.

    Falls ja, dann nimm das Flag und die bufsz aus den Parametern wieder raus und beobachte es.


    LG,

    Jasmin

    Du hast keinen log vom Booten dabei, aber ich sehe

    "Aug 8 20:05:07 localhost kernel: [ 214.427474] i2c i2c-9: enable cam buffer mode"

    also wissen wir das der neuen Treiber von nst geladen wurden.


    Das Skip kommt immer einmal nach dem Tunen und Re-Tunen und bedeutet, dass die TS Daten nicht mit dem Beginn Marker kommen.

    Das mit der "invalid MTD number" bedeutet, dass im Datenstrom etwas nicht stimmt.


    Wenn du noch den LogLevel in ddci2 aufdrehst (siehe README), dann sehen wir vielleicht noch mehr. Allerdings glaube ich, dass wir ein Treiber Problem mit der ngene haben. Diese HW ist recht alt und im Treiber von nst zwar dabei, aber nur sehr wenig getestet und mit CI weiß ich nicht ob das wer am laufen hat.


    Du könntest ev. noch das yavdr dddvb-dkms versuchen. Habe eine recht neue Version in dem Post verlinkt.

    In dem Paket sind die alten Patches von UFO für die ngene dabei. Wenn es damit geht, dann müssen wir in den Treibern von nst noch nachbessern. Wenn nicht, dann kannst du das nur selbst debuggen, oder dir eine neue Cine V7 kaufen. Ich glaube nicht, dass DD die Treiber für die ngene noch angreift.


    Wobei ... ev. könnte es funktionieren, wenn man die alte ngene und eine neue Octopus Bridge zusammen verwendet. Die ngene liefert die TS Daten und das Duoflex CI an der Octopus Bridge sollte den Stream dekodieren können.

    Schau ma mal was deine Tests ergeben.


    LG,

    Jasmin

    In dem Post ist in der Signatur ein Link. Dieser wurde von der ForenSW nicht auf die neuen Links umgeändert.

    Da muss man wohl noch ein Script über die Foren SQL Datenbank laufen lassen, falls das das Forum nicht automatisch kann. Habe ich mal in einem Forum so gelöst.


    Das Problem ist nicht nur in Signaturen, sondern auch in alten Posts!!!

    Kann man in dem Post sehen.


    Ist derzeit ein wenig nervig, aber ich denke Genka wird das schon noch reparieren in naher Zukunft.


    LG,

    Jasmin

    Funktionieren alte Lesezeichen zu Beitägen aus dem Forum nicht mehr?

    Das wäre sehr schade. :(

    Die URLs haben sich alle geändert!

    Alter Link:

    http://www.vdr-portal.de/******/101149-ci-unterst%C3%BCtzung-f%C3%BCr-cines2-mystique-satix-s2-dual-usw/index18.html


    Neuer Link:

    https://www.vdr-portal.de/forum/index.php?thread/101149-ci-unterst%C3%BCtzung-f%C3%BCr-cines2-mystique-satix-s2-dual-usw/&pageNo=18


    Also generisch:

    https://www.vdr-portal.de/forum/index.php?thread/<old_thread_id-name>/&pageNo=<old_index_number>


    Ich weiß nicht, ob ich dazu ein Perl Script schreiben soll oder es für jede alte Seite in meinem Browser manuell ändern werde.


    Aber die neuen Funktionen sind ja sehr schön.


    LG,

    Jasmin

    Die Treiber ngene und cxd2099 sind, die die im aktuellen Kernel von Ubuntu 16.04.03 enthalten sind

    MANN, DAS GEHT NED!!!!
    Bitte lies dir das README vom ddci2 Plugin durch (GIT Version 05dd98824092859afd2aa7a4996c8f258affd975) und besonders den Kasten mit NOTE NOTE NOTE ... . Ich weiß wirklich nicht, wie ich es noch mehr hervorheben soll. Lesen müsst ihr schon!


    Und auch in diesem Thread waren die Treiber immer ein Thema. Ich bin sehr verwundert, dass die Kommunikation mit dem CAM überhaupt mit der Kernel Version von Ubuntu funktioniert! Es gibt in den originalen Kernel Treibern einige Fehler, die erst in letzter Zeit behoben wurden oder durch DKMS Treiber Pakete ausgetauscht wurden.


    Zu den Treibern:
    Hier im Forum gibt es einen Thread dazu. In diesem Post steht wo es weiter geht und ein Hinweis auf ein HOWTO in dem Thread (mehr hab ich auf die Schnelle nicht gefunden).


    Wenn du diese Treiber nicht kompilieren kannst, dann tut es auch das DKMS Paket media-build-experimental (Google!). In dem ist zwar mein letzter Patch für den cxd2099 Buffer Mode ned drinnen, aber den braucht man beim Alphacrypt nicht unbedingt.


    Sollte ich ggfs. andere Treiber verwenden?

    Ja, solange du keinen Kernel 4.14 hast, sofern wir es schaffen für diese Version die Treiber gemerged zu bekommen, sonst wird es 4.15.


    Jasmin

    seit ein paar Tagen nutze ich nun auch das ddci2-Plugin mit vdr 2.3.8 unter Ubuntu 16.04 64-bit.

    Ich nehme mal die ddci2 Plugin Version ist 1.0.5.


    Meine Hardware ist eine schon etwas ältere Cine-S2 v5.5 (ngene) mit einem Single-CI-Modul.

    Welcher Treiber wird verwendet?


    Hab jetzt nicht in den VDR Code geschaut, aber soweit ich mich erinnere kommt das dann, wenn im TS Stream vom CAM die Umgeschriebene PID nicht der echten PID zuordenbar ist.


    Das passiert, wenn der Kernel den Kontakt zum CAM verliert. Ein längeres Logging von dem Problem wäre sehr hilfreich.


    Außerdem scheint der VDR gelegentlich - aus für mich bisher nicht bachvollziehbaren/reproduzierbaren Gründen - den Kontakt zum CI/CAM zu verlieren.

    Na das ist ja klar, wenn der Kernel das CAM nicht mehr sieht und dann ddci2 nicht mehr schreiben kann und auch keine Antwort vom CAM mehr kommt.


    Ich hab gelesen, dass unter früheren Versionen des Plugins bzw. vdr auch schon mal ein User Probleme damit hatte, zumindest interpretiere ich die Posts #339 - #341 dieses Threads entsprechend.

    Das sollte alles behoben sein.


    Liegt es evtl. an meiner älteren HW- & Treiberkombo, dass diese Fehler bei mir auftreten oder läuft die Cine-S2 v5.5 mit CI bei anderen problemlos?

    Welchen Treiber verwendest du?
    Ich habe erst vor einem Monat im Treiber für den cxd20099 (der ist am DD DuoFlex Ci single drauf) den Buffer Mode aktiviert. Ist aber bis jetzt nur im Treiber von nst drinnen.
    Im übrigen habe ich solche ähnlichen Probleme mit einem Uralt-CAM auf der DD Octupus CI (dual) und bin am Kernel Treiber debuggen. Ist alles ned so einfach ohne Unterlagen und wenn der Produktiv VDR jeden Abend vom Schatzi belegt ist.


    LG,
    Jasmin

    Damit kommt:

    Code
    vdr-mobil:/home/stefan # dvb-fe-tool --femon
    Lock   (0x1f) Signal= 72,00% C/N= 34,20% postBER= 1
    Lock   (0x1f) Signal= 72,00% C/N= 34,00% postBER= 1
    Lock   (0x1f) Signal= 72,00% C/N= 34,00% postBER= 1
    Lock   (0x1f) Signal= 72,00% C/N= 34,00% postBER= 1
    Lock   (0x1f) Signal= 72,00% C/N= 34,20% postBER= 1

    Sollen das 34 dB und nicht % sein?

    Der Treiber von nst liefert nur % Werte.
    Nachdem du einen stv090x hast, könntest du mal den DD Treiber wieder verwenden, dann müsste dvb-fe-tool dBm Werte ausspucken. Zumindest tut es das bei mir.


    LG,
    Jasmin

    Bei mir bricht das Kompilieren leider mit einem Error ab ;( - siehe ausführlichen Log-Eintrag unten:
    ...videobuf-dma-sg.o' failed

    Daniel hat es ja schon geschrieben, die SUSE Leute haben da kein Sternderl verdient, sowas geht gar nicht!


    Wenn du keinen Third Party Kernel verwenden möchtest, könntest du die Ursache beheben.
    Im Verzeichnis "media_build/backports" gibt es 4 Patches die in Frage kommen in denen videobuf-dma-sg.c vorkommt (grep videobuf-dma-sg.c *).
    Du könntest einen nach dem anderen in "backports.txt" auskommentieren und schauen ob es besser wird.
    Wenn nicht, dann muss man eben gezielt die Paar Zeilen anpassen und den Patch verändern.
    Sollte das deine Fähigkeiten übersteigen, dann kann ich dir leider auch nicht helfen, solange mein DKMS Paket für die neuen Treiber nicht fertig ist.


    LG,
    Jasmin

    Na ja, Jasmin hat sich breit schlagen lassen das live Plugin zu übernehmen und das ist doch viel aufwändiger, als ich dachte.
    Aber ich hoffe bald die V2 des Kernel Patches fertig zu haben. Ich musste ja ned 4 Monate auf eine Antwort warten :rolleyes:

    Meine beiden Patch Serien für den cxd2099 und für das CAM Protokoll sind jetzt auch im Kernel:
    https://www.spinics.net/lists/linux-media/msg117560.html
    http://www.spinics.net/lists/linux-media/msg118585.html


    Geht sich also auch noch für Linux Kernel 4.14 aus.


    LG,
    Jasmin

    Das wird gefühlt derzeit wohl noch wichtiger, weil Mauro (Maintainer vom linux media Subsystem) gerne einen Weg sehen möchte, wie die Treiberstände (mainline vs. dddvb) "synchroner" sind...

    Ich habe dazu eine Mail geschrieben:
    https://www.spinics.net/lists/linux-media/msg118977.html


    Es wäre wirklich wichtig, dass noch mehr Leute ihr "Tested-by" senden würden, dass der Maintainer sieht wir verwenden die neuen Treiber.
    Ich hab es leider bis jetzt nicht geschafft ein DKMS zu machen, aber man kann es ja auch mit media-build compilieren.


    LG,
    Jasmin