Beiträge von nst

    Ehrlich gesagt frag' ich mich an der Stelle ja, ob die Effekte beim/im IRQ Handling auch auf Windows-Setups auftreten, alleine schon, um feststellen zu können, ob hier 'ne Inkompatibilität zwischen Karte/FPGA-Code und Boardchipsatz oder ein Problem im IRQ Handling in ddbridge vorliegt...

    Als Teil der "Verbesserungen" durch den VideoPlayer Kram wurde aus sonstwelchen Gründen die Passthrough-Unterstützung bei Livestreams (= u.a. LiveTV) gestrichen. Wenn Du experimentierfreudig bist und Binaries für Dein Zielsystem selber compilen kannst, probier' https://github.com/herrnst/xbm…a00dcf675ef3defdaae.patch aus, funktioniert bei mir im Wohnzimmer mit NVIDIA/VDPAU Output und anständiger 50Hz-Config usw. wunderbar (in den Settings dann "Force Realtime Passthrough" einschalten). Viel Glück, Support gibts für den Patch nicht. Und: Bitte bei den Kodi Devs beschweren.

    Konkret heisst das für den Augenblick, so banal das klingen mag: Die Karte läuft nicht, ausser, Du kriegst UFO's media-build-experimental ans Laufen. Die notwendigen Patches müssten halt auf aktuelle Kernel bzw. auf aktuellen media_tree hochgezogen werden, und auf die im Kernel für DD-Hardware erweiterten Demod-Treiber adaptiert werden. Das ist in Summe nicht schwer, und ich könnte das machen, aber ich habe keine ngene-Hardware zum Entwickeln hier.

    Laut dem Link versuchst Du, ein C2T2 DuoFlex (Sony CXD28xx-basierend) an die ngene-Bridge anzuklemmen. Das unterstützt der ngene-Bridge Treiber aber nicht (es fehlt die XO2-Erkennung, die CXD-Erkennung und die Attach-Logik für Demod und Tuner). ngene unterstützt - im Kernel - nur die ältere S2-Generation (stv090x) und C/T auf DRXK-Basis, sowie das CI Single Flex auf CXD2099-Basis (und irgendwas mit Terratec-Branding). Elektrisch passen die ngene's und die neuen Flex-Module, den Code könnte man also nachrüsten, und in media_build_experimental von UFO habe ich auch passende Patches dafür gesehen.

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

    Die CTv6 (und DuoFlex CTv2, jeweils stv0367-basierend) machen DVB-C und DVB-T, aber kein T2 oder gar C2 (liegt C2 eigentlich schon irgendwo an?). Die V7 und aktuelle Flexmodule machen C/T/T2, einige noch C2, und einige obendrauf noch ISDB-T (betitelt als DuoFlex CT2 - cxd2837-Chip, DuoFlex C2T2 - cxd2843-Chip und DuoFlex C2T2I - cxd2854-Chip).


    TL;DR: Wenn Du nur DVB-C brauchst, sind die CTv6 top. Für T2 brauchst Du die neueren Boards (ausser, Du lebst in einer Region, wo noch altes DVB-T ausgestrahlt wird, das kannst Du mit der V6 empfangen).


    EDIT: Beim erneuten Lesen könnte auch Sat-Empfang in Frage kommen, da ists AFAIK egal. Die stv090x (v6) und stv0910 (v7) können gleichermassen S und S2 empfangen. DuoFlex CI-Addons funktionieren an allen genannten (CT/S) Karten.

    EDIT2: Im Topic steht "CT" (Montag und so...), daher die DVB-S info ggf. gedanklich streichen (lass ich trotzdem für die Nachwelt stehen).


    HTH,

    nst

    Servus zusammen!


    So, wie es seit ca. 1,5 Stunden aussieht, kann dieser Thread dann jetzt wohl beerdigt oder zumindest in seinen wohlverdienten Ruhestand geschickt werden.


    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!


    Ausgenommen vom Treiber ist - und so war's von vornherein geplant - Unterstützung für die DVB-C Modulator Karten, sowie Support für die Octopus SATIP Boxen. Ausserdem (das ist die Kleinigkeit) hatte der Maintainer ein Problem mit der Art und Weise, wie der Treiber die IOCTLs bereitstellt. Diese werden derzeit (mWn) ausschliesslich dazu verwendet, das FPGA auf den Bridge-Karten zu updaten, und ich glaube, das musste in der Praxis noch nie jemand wirklich machen. Die Funktionalität ist aber aus den Patches "nur" ausgegliedert und ist derzeit in Besprechung, wie man das "Richtig" macht, ist also nicht verloren und könnte durchaus später nachgereicht werden.


    An dieser Stelle möchte ich mich nochmals bei allen (ich möchte bewusst niemanden besonders hervorheben - ihr wisst, wer ihr seid!) Bedanken, die sich durch Tests, Feedback, Zuarbeit, (zum Ende) Politik und Überzeugungsarbeit beteiligt und eingesetzt haben - das Vorhaben wäre vermutlich sonst nicht zu einem derart positiven Ergebnis resultiert!


    Noch was: Ich habe gleichzeitig den Maintainership für die neuen Demod-Treiber sowie ddbridge übernommen, und werde mich in Zukunft entsprechend darum kümmern, den Code in mainline mit dddvb als Quelle uptodate zu halten, damit die Codestände nicht nochmal in derartiger Form ausseinanderlaufen.


    Und jetzt erstmal aufräumen, und dann sind erstmal andere Dinge dran - es ist viiieeel liegengeblieben :)


    Schönen Sonntag und viel Spass mit Kernel 4.14,

    nst

    Das Femon-Plugin zeigt 34 % für SNR an - mit dem originalen ddbridge-kompilierten Treiber sind's 76 %.


    Randnotiz und Vorsicht bei dem Vergleich: stv090x@mainline liefert hier die ursprünglich implementierte SCALE_RELATIVE (Prozentzahl) zurück. stv090x@dddvb ist erweitert (der "Auslesecode" ist derselbe!) um eine Konvertierung in SCALE_DECIBEL. femon konvertiert Dir das wieder in einen wie-auch-immer interpretierten Prozentwert zurück. Das KANN man nicht vergleichen :)

    Meine USB-Tuner (August und pctv gehen auch).


    Und genau DAS ist der Grund, der für mich "damals" Stein des Anstosses war, den Code zu zerlegen, und warum der Kram gemerged gehört.


    STR zeigt einen gewohnten Wert an, SNR zeigt den halben Wert an als sonst. BER und UNC sind vermutlich nicht implementiert.
    Ist das nur bei mir so?


    S2 6.2 klingt nach stv090x-Demodulator. DD hat in ihrer Kopie noch etwas an den Signalstatistiken gedreht, was (noch) nicht rückportiert ist (genau genommen kommt der "Vanilla" Treiber aus Mainline zum Einsatz). Was bedeutet denn "halber Wert" konkret in Zahlen, und im Vergleich?


    2. Frage: Wo muss ich nochmal hinterlegen, dass mit meiner Cine S2 6.2 alles geht? Der Test mit der Max S8 folgt bei Gelegenheit.


    Auf die linux-media Mailingliste unter linux-media@vger.kernel.org als Reply an alle auf genau dieses Posting, damit die Maintainer sehen, dass durch den Codebump niemand in Gefahr gerät oder Häuser abfackeln. Um dorthin zu posten, muss man die Liste nicht abonnieren. Vermutlich fehlt die Original-Nachricht in der Inbox für "Antwort an alle", daher hier ein Tipp für NNTP-fähige Mailprogramme (funktioniert mit Thunderbird und Claws Mail):


    • NNTP-Server hinzufügen, Adresse: news.gmane.org / Port: 119, restliche Einstellungen sind egal, es wird nur read-only Betrieb benötigt
    • Die Gruppe gmane.linux.drivers.video-input-infrastructure abonnieren bzw. öffnen
    • Nach der oben genannten Mail suchen ("ddbridge" als Suchwort reicht schon)
    • Die Mail mit dem Subject "[PATCH v2 00/14] ddbridge: bump to ddbridge-0.9.29" markieren und "Antwort an alle" klicken
    • Im Absender des Editorfensters jetzt die normale Mailadresse auswählen, Post verfassen (sinnvoll quoten!), abschicken


    Inhalt sollte sein: Verwendete Kartentypen, Verwendete Software, OS, wie getestet, Einsatzszenario (24/7-Betrieb oder "für 1 Stunde zum TV-Schauen an"), und dazu abschliessend "Tested-by: Vorname Zuname <mail@address>" (Body komplett auf Englisch verfassen!) Im Zweifelsfall bei Fragen mir 'ne PM schicken.


    Danke für Deinen (und aller anderen Tester) Support!


    nst

    Es liegt vielleicht auch daran, dass der 4.8.x vom Ubuntu Patches enthält die im Vanilla nicht enthalten sind:


    Nein:


    Code
    ...
    /mnt/sda2/dddvb/media_build/v4l/ov5670.c:2579:2: error: unknown field 'probe_new' specified in initializer
      .probe_new = ov5670_probe,
      ^
    /mnt/sda2/dddvb/media_build/v4l/ov5670.c:2579:15: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
      .probe_new = ov5670_probe,
                   ^


    Der Member probe_new wurde mit 4.10 hinzugefügt. Das aktuelle media_build (sowohl upstream als auch aus meinem Fork) berücksichtigt das mittlerweile. Bitte neu Clonen (dabei am besten dddvb-linux-kernel nochmal mit updaten) und nochmal probieren.

    Sehr schön, offenbar haben die OpenSUSE Kernel Maintainer Patches aus 4.5 oder gar 4.9 in 4.4 rückportiert, und nennen das weiterhin 4.4: https://github.com/herrnst/ddd…rnel/commit/768ae309a9610 z.B. verändert die Funktionssignatur und taucht erstmals in 4.9-rc2 auf. Da hier ein Funktionsargument wegfällt, passt das ganz gut zu "too many arguments", was durch Rückportierungspatches in media_build entsprechend umgepatcht wird, um eben mit 4.4 kompatibel zu sein. Immerhin, Ubuntu 16 mit Kernel 4.4 scheint das Problem nicht zu haben, "VER=4.4.0-87-generic ./build_all.sh" lief auf dem Notebook grad sauber durch. Und ja, die Info hilft Dir bei dem Problem gerade nicht :)


    TL;DR: Ich kann Dir nicht wirklich mit dem Problem helfen. Am besten aus 'nem Thirdparty-Repo ein aktuelles Kernel-Image installieren und dann nochmal von vorne.

    Ganz einfach:


    Per media_build (HOWTO hier im Thread oder unter https://github.com/herrnst/ddd…ile-using-media_build.git dokumentiert) jetzt den Branch "mediatree/master-ddbridge" compilen und installieren, testen, und (Miss)Erfolg auf linux-media hinterlassen, zusammen mit einer

    Code
    Tested-by: Real Name <email@address>


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

    Hm, klingt erstmal "befremdlich", weil alle mit dem CI-Kram in Zusammenhang stehenden Änderungen in gleicher Form bereits im 0.9.28er Branch (v4.12-ddbridge) drin sind. Verglichen mit v4.12-ddbridge-edge (0.9.29) sind keine weiteren Änderungen rund um CI/EN50221 dazugekommen. Kannst Du die Continuity Errors an irgendwas festmachen? Gibts irgendein Muster, wie die auftreten? Wie sieht sowas denn im Syslog aus?