Posts by gentoo-vdr

    Danke Euch beiden.

    Die Kernel-Patches habe ich einfach nach /etc/portage/patches/sys-kernel/gentoo-sources/ kopiert und dann den neuesten Kernel (5.15.6) installiert. Die Patches wurden problemlos angewendet.

    Leider hat der neue Kernel auch keine Verbesserung gebracht.


    Ich habe mir dann die verlinkte Anleitung angeschaut und festgestellt, dass es nicht ausreicht die Patches anzuwenden, sondern man diese auch im configure-Schritt aktivieren muss...

    Also ffmpeg noch mal mit EXTRA_FFMPEG_CONF="--enable-v4l2-request --enable-libudev" installiert. Da es auch ein Update gab, habe ich es mit ffmpeg-4.4.1-r1 versucht. Leider funktioniert der Patch ffmpeg-001-v4l2-request.patch nicht mit Version 4.4.1, also habe ich den Patch angepasst und den Revert-Patch gleich integriert (siehe Anhang).

    Danach habe ich noch mal VDR und das Plugin kompiliert, jedoch bekomme ich nun nur noch ein grünes Bild.

    Ideen, was jetzt noch nicht passt?

    Hab gestern auch grad das Banana neu aufgesetzt. Das Problem liegt in fehlenden Patches und an der falscher Kernel Version.

    Das Plugin läuft bei Dir sauber auf einem Banana Pi? Das klingt ja super.


    FFmpeg braucht v4l2-drmprime, v4l2-request und diese ffmpeg Patches.

    Das Kernel 5.15.5 benötigt die linux patches.

    Die ffmpeg-Patches hatte ich zwischenzeitlich auch noch integriert - hat aber keine Besserung gebracht.

    Ich versuche es dann mit einem neueren Kernel. Da ich den Kernel direkt auf dem Banana Pi kompiliere, kann ich frühestens morgen berichten ;-)


    PS: Einer der ffmpeg-Patches hat bei mir zunächst für einen Fehler beim Kompilieren gesorgt (drm_fourcc.h wurde nicht gefunden). Es gibt die Datei ja zweimal. Einmal unter /usr/include/drm/ von den Kernel-Headern und unter /usr/include/libdrm/ von libdrm. ffmpeg-001-v4l2-drmprime.patch scheint beide Includes zu verwenden. Nach dem Setzen von USE=libdrm konnte ich ffmpeg erfolgreich kompilieren. Ich hoffe, das passt so.

    Hallo,


    nachdem ich letztes Jahr das Plugin schon ausprobiert hatte, dann aber aus beruflichen und privaten Gründen keine Zeit für weitere Tests hatte, habe ich nun mal wieder meinen Banana Pi rausgekramt und das Plugin an einem Kabelanschluss getestet.


    Als Kernel habe ich 5.10.61-gentoo (mit CONFIG_VIDEO_SUNXI_CEDRUS=y) und ffmpeg in der Version 4.4-r1 mit dem v4l2-request Patch verwendet.

    Leider bekomme ich nur eine Diashow mit ca. allen 5 Sekunden ein Bild. Die CPU-Last ist <10%.


    Wenn ich nun im alsamixer "Power Amplifier DAC" und "Power Amplifier Mute" aktiviere (siehe https://linux-sunxi.org/Audio_Codec#Troubleshooting) und den PA-Level hochdrehe, läuft das Bild wesentlich flüssiger, ruckelt aber immer noch (sowohl bei HD- als auch SD-Sendern) und die CPU-Last steigt auf ~150%.

    Anscheinend erfolgt die Audio-Dekodierung in Software und überfordert der Banana Pi. Gibt es die Möglichkeit ein Dummy Audio Device einzurichten, um zu prüfen, ob die Video-Dekodierung überhaupt flüssig auf dem Banana Pi läuft?


    Tonausgabe per HDMI (erfordert diesen Kernel-Patch) habe ich auch probiert. Hier sorgt das Starten des VDR aber dafür, dass das Audio Device verschwindet und der VDR-Prozess sich nicht einmal mehr mit kill -9 beenden lässt. Anbei das Log dazu (mit aktivierten DRM Debug-Meldungen).

    Files

    • vdr_log.txt

      (67.27 kB, downloaded 38 times, last: )

    @rell/@zillerbaer: Danke Euch beiden. Stimmt, der A20 ist zu alt für H265 - hätte ich auch selbst drauf kommen können...


    Speicher für CMA war Default (96M). Ich erhöhe das auf 256MB (gemäß Empfehlung unter http://linux-sunxi.org/Sunxi-cedrus) und teste demnächst an einem Kabelanschluss. Momentan kann ich nur mit DVB-T2 testen.

    Es gibt noch eine Möglichkeit. Du kannst in der Zeile die 50 durch 60 ersetzen. Dann muss aller 16 ms statt aller 20 ms ein Bild dargestellt werden. Ich hoffe der H3 schafft das. Das Bild wird auch ein bissel ruckeln da einige Bilder doppelt angezeigt werden.

    Danke. Wenn ich dort 1920x1200 und 60Hz eintrage, startet der VDR auch, wenn der Banana Pi an meinem Monitor hängt. Das OSD funktioniert einwandfrei, das Fernsehbild (DVB-T2) ruckelt aber und zeigt nur einen Teil des Bildes. Um auszuschließen, dass es am Empfang liegt, habe ich den Banana Pi an meinen Fernseher gehängt und wieder das unmodifizierte Plugin verwendet.

    Dort sehe ich nur Artefakte und der VDR crasht nach wenigen Sekunden. Hier die letzten Logmeldungen:


    Ich verwende den allerersten Banana Pi (M1). Ist der für die Wiedergabe nicht geeignet?

    Da braucht nix zu stehen. Es wird nach der Mode 1920x1080 50p gesucht und genutzt. Fehlt diese Mode kann kein OSD erstellt werden und vdr wird beendet. Es werden im Fehlerfall auch Meldungen auf der Konsole ausgegeben. Kannst Du die mal posten?

    Ich habe den Banana Pi momentan an einem Monitor mit einer Auflösung von 1920x1200@60Hz hängen. Liegt hier das Problem?


    Auf der Konsole sehe ich keine Meldungen. Ich starte den VDR über die Init-Skripte von Gentoo. Beim manuellen Start kommen folgende Meldungen:


    VDR stürzt nicht ab, es wird beendet da der drm Treiber nicht sauber initialisiert wurde. Es kann kein OSD mit der Höhe 0 und der Breite 0 angelegt werden. Da hilft nur ein Reboot. Man kann das schon beim booten an der Auflösung sehen.

    Danke. Ich hatte softhddevice.Osd.Width und softhddevice.Osd.Height nicht in /etc/vdr/setup.conf eingetragen. Das habe ich korrigiert, hat aber leider nichts gebracht. Ebensowenig ein Reboot.


    Den letzten Satz verstehe ich nicht ganz. Die Auflösung der Konsole per HDMI ist normal. Allerdings sehe ich keine Bootmeldungen beim Laden des Kernels, nur einen blinkenden Cursor.


    Ich habe aktuell den sun4i-drm und den Lima-Treiber im Kernel aktiviert. Liegt hier evtl. das Problem?


    Danke auch für den Verweis auf die notwendigen Patches. Der ffmpeg-Patch lässt sich leider nicht einfach auf Version 4.2.4 anwenden. Das versuche ich zu fixen.

    Hallo,


    ich habe nach langer Zeit mal wieder meinen Banana Pi ausgepackt, Gentoo installiert und als Streaming-Server eingerichtet. Bei der Suche nach einem geeigneten Ausgabeplugin bin ich auf softhddevice-drm gestoßen. Leider stürzt mein VDR nach dem Laden des Plugins ab. Mit aktiviertem Debugging, sehe ich folgende Meldungen im Log:



    zillerbaer : Hast Du eine Idee, woran das liegen könnte?


    Die Lima, sun4i-drm und Cedrus-Treiber habe ich im Kernel drin. libdrm und mesa mit Lima-Treiber sind installiert. Die Grafikausgabe habe ich mit kmscube getestet und funktioniert.

    Benötige ich auch noch libva-v4l2-request für das Plugin? Hier im Thread ist auch noch die Rede von einer gepatchten ffmpeg-Version sowie einem Kernelpatch. Davon steht auf der Github-Seite nichts. Falls ich das auch noch vorausgesetzt wird, gibt es auch Patches für ffmpeg-4.2.4, die ich in Gentoo integrieren kann?

    Hab ich gelesen das das geht aber nur ein tuner ist dann ja auch witzlos oder?


    Witzlos würde ich nicht sagen. Er lässt sich ja nutzen und mit etwas Glück funktioniert vielleicht irgendwann auch der zweite Tuner. So viel mehr als andere Sticks kostet er außerdem auch nicht und dafür sind vernünftige Tuner-/Demodulatorchips verbaut.
    Wenn es (funktionierende) Dual-Tuner-Alternativen für USB gäbe, würde ich die kaufen, aber die gibt es halt leider nicht (jedenfalls sind mir keine bekannt).

    TLER sollte doch nur einen Unterschied machen, wenn du ein RAID hast?


    Bei aktiviertem TLER wird IMHO ein Sektor als defekt markiert, wenn er nicht innerhalb von 7 Sekunden gelesen werden kann und die Daten sind dann verloren. Ohne TLER kann man hoffen, daß die Platte sich wieder berappelt und die Daten beim Recovery doch noch lesbar sind. Bei mir war das anscheinend der Fall. Die Sektoren, die im Log mit I/O-Error auftauchen, lassen sich jetzt alle per "hdparm --read-sector <sektor>" wieder lesen.

    Die SMART-Daten sehen eigentlich noch relativ normal aus:


    Erst 6 schwebende Sektoren. Daß die noch nicht bei Reallocated auftauchen, liegt wohl daran, daß ich noch nicht schreibend darauf zugegriffen habe. Ich habe außerdem TLER deaktiviert. Vielleicht ist das auch der Grund dafür.
    Meine Befürchtung ist halt, daß WD einen Garantieaustausch ablehnt, weil die Werte noch zu gut aussehen und die Geräusche anscheinend nur sporadisch auftreten. Ich habe keine Lust, nachher doppelte Versandkosten und evtl. noch eine Bearbeitungsgebühr bezahlen zu müssen.


    Die Daten sind schon längst gesichert (mit rsync). Ich werde die Platte demnächst noch etwas mit badblocks stressen, in der Hoffnung, daß sich die SMART-Werte dann weiter verschlechtern ;)

    Danke für Eure Antworten!


    Gut zu wissen, daß ein paar auffällige SMART-Daten für einen Austausch ausreichen.
    Meine Festplatte meldet zwar erst 6 defekte Sektoren, hat aber beim letzten Einsatz plötzlich merkwürdige hochfrequente Geräusche gemacht und es traten Lesefehler auf. Ich habe den Rechner dann schnell ausgemacht. Komischerweise waren die Geräusche ein paar Tage später beim erneuten Einschalten weg und es ließen sich alle Daten lesen. Ich werde die Platte noch mal mit badblocks testen, bevor ich sie einschicke.

    Danke!
    Ja, ich habe mit WD-Platten auch gute Erfahrungen gemacht (bisher neben der Red nur ein Ausfall einer Green nach Ablauf der Garantie) und werde auch weiter WD-Platten kaufen.
    Ersatz ist vorhanden, daher ist die Austauschzeit nicht kritisch.
    Schade ist nur, daß man die Kosten für die Rücksendung tragen muss.
    Auf meiner Conrad-Rechnung steht übrigens keine Seriennummer - könnte theoretisch also auch eine Rechnung einer anderen Platte sein. Ich hoffe, das gibt keine Probleme. Aber eigentlich sieht WD ja anhand des Herstellungsdatums, daß die Platte noch Garantie hat.

    Hallo,


    bei mir hat eine WD Red-Festplatte leider den Geist aufgegeben. DIe Festplatte hat noch ein paar Monate Garantie und ich überlege, sie für einen Garantieaustausch einzuschicken.
    Hat jemand Erfahrungen mit der Garantieabwicklung bei Western Digital? Bekommt man beim Austausch eine Refurbished-Platte oder eine neue Platte? Kann es sein, dass man evtl. gar ein anderes Modell erhält?
    Laut den Garantiebedingungen ist außerdem ein Kaufbeleg erforderlich. Ich habe zwar die Rechnung, aber auf der Rechnung steht ein anderer Name, da meine Platte aus einer Sammelbestellung stammt. Ist das ein Problem?
    Schließlich würde mich noch interessieren, wie lange ihr auf Ersatz warten musstet, wenn man keine Kreditkartendaten angibt.


    Wie oben geschrieben ist mir mit Zusatz-Init im Tuner bei Tests wieder alles abgeschmiert. Lässt Du den Rechner (VDR) mit den Karten durchlaufen oder startest Du zwischendurch neu?


    Mein VDR wird jeden Tag neu gestartet. Ich werde mal beobachten, ob es bei mir auch auf Dauer ohne den Delay funktioniert. Bis jetzt war die Anzahl der Neustarts noch überschaubar.



    Wenns keine Probleme gibt, scheints nicht notwendig. Es gibt aber wohl laut Forum diverse User, die bei aktivierter Verwendung von MSI I2C-Probleme direkt mit der Bridge kriegen (s.o., schätze, der alte ICH9 SATA Controller strengt das Konstrukt zu sehr an), daher mal per menuconfig steuerbar der Switch für msi=0 als default :-)


    OK. Aber wäre es nicht besser, MSI per Default zu aktivieren und es per menuconfig abschaltbar zu machen? In media_build_experimental von UFO ist MSI standardmäßig auch aktiviert.


    MSI bewirkt AFAIK unter anderem, dass jedes Gerät einen eigenen Interrupt (IRQ-Nr.) erhalten kann und nicht mit anderen Geräten shared ist. Mehr (technische) Details in der englischen Wikipedia.


    Das Thema MSI ist HIER recht gut erklärt. ;)


    Danke, das Grundprinzip habe ich verstanden. Mir ging es mehr um die praktischen Vor- und Nachteile. Also z.B. ob eine Karte tendenziell zuverlässiger mit oder ohne MSI funktioniert (sieht man mal von Hardware Bugs im Zusammenhang mit MSI ab). Oder ob sich am Stromverbrauch etwas ändert. Laut http://www.intel.cn/content/da…aled-interrupts-paper.pdf ist die CPU-Auslastung mit MSI geringer. Führt das Deaktivieren von MSI vielleicht dazu, daß der Prozessor häufiger aus den Stromsparmodi aufwacht?

    @gentoo-vdr, gibts bei Dir neue Erkenntnisse bzgl. i2c_write Problemen, auch mit aktuellem testing-Tree inkl. write_init_table() tryfix/workaround? Mein Server und die DD-Karte läuft jetzt mit msi=0 seit einer Woche wie gewohnt störungsfrei.


    Ich habe auch keine I2C-Fehler mehr gehabt (seit nun fast zwei Wochen). Die zusätzliche Initialisierung scheint etwas gebracht zu haben. Mein Treiber ist übrigens noch auf dem Stand von Commit 48df2f7173c693f3590071bc1108558b51131605. Die Wartezeit, die Du danach noch implementiert hast, scheint bei mir (bis jetzt) nicht erforderlich zu sein.
    Soll ich auch noch mal mit msi=0 testen? Ich hatte mit aktiviertem MSI bisher nie Probleme. Was sind denn eigentlich die Vor- und Nachteile von msi=0 bzw. msi=1?

    Ich habe jetzt mal den Init Code vom TDA18212DD aus dddvb in drivers/media/tuners/tda18212.c eingestrickt (TDA18212 ist das Stück Tuner, das an den STV0367 Demod angeklemmt ist). In dddvb passiert hier wesentlich mehr (bzw. überhaupt was, anstatt nur "identifizieren und fertig"), z.B. wird irgendwas gegeneinander kalibriert, und in Bezug auf die Master/Slave-Konstellation wird einiges gemacht (was die ganzen Register-Pokes machen, kann ich nur erraten, aber das "drumherum" lässt einiges erahnen). Möglicherweise sind dies Dinge, die - wenn sie fehlen - Einfluss auf die Stabilität des Demods nehmen und das Ding abstürzen lassen können.


    Danke! Ich werde testen, ob damit immer noch I2C-Fehler auftreten. Bis jetzt sieht es gut aus. Ich werde berichten, wie die Langzeiterfahrungen sind.


    Ich wünsche ebenfalls schöne Feiertage!