Posts by cduerr

    jetzt habe ich versucht, nvidia-340 zu installieren (weil ich glaube, dass das Playbook dem irgendwie nachjagt, wie auch der Verweis auf die libvdpau_nvidia.so, wo mir eine Google-Suche sagte, dass die Datei eigentlich nur in nvidia-340, -361 etc. (unter 390) enthalten sei. Fehler bekommen, erschrocken. Also gepurged, noch mal nvidia-dkms-390 installiert, rebootet, dann habe ich in /etc/vdr/conf.avail/softhddevice.conf -v cuvid hinzugefügt, vdr-plugin-softhddevice gepurged, vdr-plugin-softhddevice-cuvid installiert, dann noch nvidia-compute-utils-390 installiert und jetzt habe ich zumindest wieder vdpau und keine Fehlermeldungen mehr beim Start von vdpau, Auflösung scheint Full HD zu sein, Gepixel hält sich in Grenzen. Könnte was sein.


    Zwischendrin dachte ich, ich verstehe das Konzept. Eigentlich hatte ich gemeint, verstanden zu haben, Ansible sollte das in Konfigurationsdateien etwas einzustellen oder Pakete zu installieren übernehmen? Jetzt erinnere ich mich wieder, warum ich in der Vergangenheit nie dem Credo "stelle das Playbook korrekt ein, dann brauchst Du Dich um nichts kümmern" gefolgt bin: weil nach dem x-ten Aufruf irgendwas kaputtgegangen ist was eigentlich schon zu meiner Zufriedenheit lief und ich nicht genug Ahnung habe, um's reparieren zu können. Ich glaube, ich hatte hier auch mehrfach gefragt, was ich denn einstellen soll, eine Liste von Ausgabeplugins. Scheint es wohl nicht zu geben, aber das und eine Doku aller Optionen bräuchte es, wenn denn das Konzept für was gut sein soll.


    Egal, es scheint jetzt zu laufen, hinreichend gut für meine Zwecke. Wieviel Zeit ich darein investiert habe (TV ist ja sowieso eine Zeitvernichtungsmaschine) darf ich überhaupt niemandem erzählen...

    Update: Ich habe das Gefühl, das Playbook jagt entweder einem Geist hinterher oder es ändert überhaupt nichts mehr, obwohl man es erneut ausführt. Wie soll denn das sein?

    Hi,

    ich habe mich leider vertan - es ist eine GT610. Aber der 390 war vorher drauf, jetzt auch wieder, wenngleich nicht vom Ansible installiert. Habe ich selber installieren müssen. Dann habe ich für beide Parameter wie von vdr_rossi ermahnt :) dasselbe eingestellt (softhddevice und vdr-plugin-softhddevice) und das Installationsskript mehrfach drüberlaufen lassen sowie rebootet. Es gab einmal eine Fehlermeldung zu dem Teil mit xorg (O-Ton no "primary" oder so ähnlich). Die Meldung habe ich dann nicht mehr gesehen. /etc/X11/xorg.conf habe ich mit der alten Version verglichen, das ist identisch. softhddevice war zweimal installiert (einmal normal, einmal mit -cuvid). Ich habe beide gepurged. Im anschließenden Installationsskript-Lauf wurde trotz Eintrag in host_vars/localhost das Plugin nicht installiert. Das musste ich wiederum händisch tun.


    Der vdr läuft jetzt (ich höre Ton), aber leider kein Bild. Logextrakt anbei.


    Da fehlt noch was! Könnt Ihr mir sagen, was?


    (Update: Ich sehe im Log, dass nouveau genommen wird, argh. - Habe nouveau jetzt geblacklistet, initramfs aktualisiert, rebootet und libvdpau-driver-all sowie libnvidia-decode-390 installiert)



    (Jetzt habe ich auch die Xorg-Fehlermeldung des Playbooks:)

    Was soll mir die Fehlermeldung sagen? Sie ist reproduzierbar, Playbook läuft auch nach Reboot und mehrfachem Ausführen nicht fehlerfrei durch an der Stelle.


    Immerhin habe ich jetzt wieder Bild - wenngleich mit sehr geringer Auflösung. Im Log steht, dass:


    (Update2: habe das selected frontend und plugin auf softhddevice-cuvid geändert; Fehlermeldung zum Xorg bleibt gleich, localhost anbei)

    Moin,


    nur mal zwei Denkanstöße:

    - Warum einmal selected_frontend: softhddevice und dann vdr_output_plugin: vdr-plugin-softhddevice-cuvid ? Das sind zwei unterschiedliche Plugins...

    das ist ja jetzt Rekursion, danach habe ich doch gefragt...

    a) Kannst Du mir mehr dazu sagen, was ich denn nehmen sollte?

    b) Und woher weiß ich, ob ich vdr_output_plugin oder selected_frontend konfigurieren sollte?

    c) Wie finde ich denn raus, was der alte vdr benutzt (ohne die falschen Angaben im Ansible anzugucken)?

    - Aus dem Gedächtnis: Geforce GT630 benötigt einen älteren NVidia Treiber. Irgendwas mit 390...

    sogar noch schlimmer (das hat ./install-yavdr.sh installiert)

    Code
    root@vdr3:~# dpkg --list | grep -i nvidia
    ii  nvidia-340                            340.108-0ubuntu5.20.04.2                         amd64        NVIDIA binary driver - version 340.108
    root@vdr3:~# 



    Ausschnitt von journalctl -xu vdr für den softhddevice/vdpau Start (scheint keine HW-Beschleunigung an zu sein):

    das hier ist die konkrete Zeile im Vergleich (links baddmesg.txt, rechts gooddmesg.txt)

    Code
    Memory: 32568156K/33379584K available (16393K kernel code, 4 |  Memory: 32568152K/33379584K available (16393K kernel code, 4...

    ich hätte nicht gedacht, dass da was unterschiedliches stehen kann. Aber der Rechner ist stabil, Speicherhardware habe ich eigentlich nicht befürchtet (und glaube es auch nach wie vor nicht). Nur halt komisch. Bin auf eine Erklärung gestoßen, nach der der Speicher dort eben nicht der installierte Hardwarespeicher ist, sondern der zu dem im Augenblick verfügbare Speicher (und wenn überhaupt hätte ich es auch noch falsch gelesen, links ist ja der verfügbare, rechts neben dem Schrägstrich der gesamte). Anyway: Wer den genauen RAM will soll im OS unter /proc/meminfo gucken und da den Total.


    Ich boote einfach mal dieselbe Distro (Clonezilla) zum Test (der Varianz) der SSD/der Netzwerkgeschwindigkeit.

    Ich vermute: Es muss irgendwas softwareseitiges sein, was die Werte runtergehen lässt (erste Benutzung der TV-Karte?). Aber während das bei der SSD z.B. irgendeine Dauernutzung sein könnte, was die serielle Datenübertragungsrate einfach reduziert, fällt mir bei der NIC nichts mehr ein. Oder Power Management.


    Gestern habe ich einfach mal einen ganzen Schwank auf allen Frontends aufgenommen - und bin fehlerfrei. Fast jedenfalls. Die meisten reklamieren Abweichung von der EPG-Zeit, geschenkt. Aber in 4 von 11 Aufnahmen habe ich jeweils einen Fehler und ich vermute, dass das vielleicht derselbe Fehlerzeitpunkt sein könnte bzw. sich da irgendwas beeinflusst.

    Weiß jemand, ob

    a) sich die Fehlerzeitpunkte in Logs befinden oder

    b) ich die Aufnahmen mit einem TS-Analyzer prüfen kann, der mir zumindest die relative Zeit von Prio1-Fehlern ausspuckt?


    (Update:

    Ich habe /usr/local/bin/vdr-checkts gefunden und obwohl es mir nicht die Zeiten gibt, es erzeugt noch mehr Fragezeichen :)

    Mein Live-Frontend zeigt die "Fehler in den Aufnahmen", sprich die Zahl, die in die info geschrieben wurde. Da bin ich bei vier Aufnahmen bei 1.

    Der Check mit vdr-checkts:

    Nur bei der letzten Aufnahme ist der Fehler, der notiert wurde, wirklich im TS zu finden.

    mir scheint es so zu sein, dass direkt nach Boot, früh genug gemessen, die Performance noch gut ist. Messen tu ich mittels dd if=/dev/zero of=/srv/vdr/video/bigfile.bin bs=1M count=10000 (/srv ist die NVMe-SSD, sollte 3,4++GBps liefern) und mittels scp bigfile.bin <anderer PC> und direkt nach Boot ist es auch gut. Aber dann scheinen in 3 von 7 Fällen die Leistung runterzugehen - das kann doch nicht Stromversorgung oder Hardware sein, wenn es schon läuft. Interrupts? Ich versuche die M4 mal mit dem MSI=0 Parameter. Vorher wird noch der Marvel deaktiviert.

    das fasse ich mal als Kompliment auf :)

    Ernsthaft, ich bin genau an der Schwelle. Was ich habe, hatte ich teils schon, aber das, was ich noch brauchte, war natürlich nicht kostenfrei. Ich gebe jedenfalls nicht einen weiteren Euro für das Konstrukt aus, wenn es nicht so hinzubekommen ist, wie ich das gerne hätte. n100 ist andererseits auch nciht so wie ich mir das vorstelle. Aber auch andere Dinge - ich hatte da gerade mal einen Blick auf ein Asus ROG B-550 Gaming, Ryzen 2 4300G, 32GB - kosten und sind dann auch nur ein Kompromiss (ich hätte gerne noch zwei Frontends mehr, just in case). Immerhin bin ich jetzt soweit, dass ich fast glaube, dass das Signal ok ist und wenn es noch Fehler gibt, die irgendwie durch irgendwas Hakendes reinkommen. Als wenn da eine angezogene Handbremse irgendwo ist. Natürlich, auch wenn ich neu kaufe, es wird nicht einfach so funktionieren. Lernen und verstehen muss man in jedem Fall, das ist noch ein Punkt, der mich neben dem ökologischen Aspekt, einfach nicht immer sofort neu zu kaufen, beim alten hält.

    nee, sitze gerade nicht vor dem Rechner, aber es geht um eine Zeile im dmesg (kurz gegoogelt, genaues Zitat kommt nachher)

    Code
    Memory: 32768K/xyzK available…

    und in zwei Bootvorgängen unterscheidet sich die ganz linke Zahl ganz leicht, wenige kB. Ich hätte aber gedacht, das ist Hardware und bleibt gleich. Wie gesagt, nachher kann ich es genau zitieren.

    Hallo,


    auf der Suche nach einem Problem (merkwürdige Unterschiede in der Systemleistung von Reboot zu Reboot, 3 von 7 Reboots sind so auffällig, SSD liefert reduzierte Leistung (schon ausgetauscht), NIC auch) bin ich darüber gestolpert, wenn ich einen diff des dmesg Gutfall mit Schlecht-Fall mache, dass der Speicher sich unterscheidet (!).


    Ist das normal?

    Hallo,

    nach der Neuinstallation meines vdr-Client habe ich scheinbar vdpau mit OpenGL und leider dropped frames.

    Ich habe host_vars/localhost:


    In meinem alten vdr-Client hatte ich ein gutes Ausgabeplugin, aber nicht alles in ansible eingetragen.


    1) Wie finde ich raus, welches Ausgabeplugin das war (in ansible ist es genauso konfiguriert und wenn ich in den gestarteten vdr gucke zeigt mir softhddevice leider nicht wie im neuen vdr das konkrete Setup an)?

    2) Und gibt es eine Liste an Einträgen, die ich in obiger Datei eintragen muss, damit ich genau das bekomme?


    Ich habe eine Geforce GT630 drin, die sollte doch für irgendwas gut sein. Danke.

    danke Dir. Scheint noch eine große Baustelle bei mir zu sein. Als letztes Feedback habe ich mich vor zwei Stunden auf die Stirn geklatscht, weil ich nicht realisiert habe, dass evtl. eine smartctl-basierte Temperaturanzeige von hddtemp in jammy evtl. das Problem ist, warum die HDDs nicht schlafen gehen (das muss man erstmal zusammenbringen, sorry). Jedenfalls sind die Platten gerade im standby :) nachdem hddtemp deaktiviert wurde. *argh*.

    Als nächstes müsste ich mal rebooten, um zu gucken, dass die ganzen hdparm-Änderungen wieder weg sind und trotzdem noch ein spindown stattfindet.

    Die Hersteller haben meist Webseiten, wo sie schildern, wie sie selbst reklamierte Festplatten erhalten wollen. *DAS* ist das Gegenteil davon. Aber unabhängig davon habe ich auch erfahren müssen, dass die großen Festplatten hinsichtlich Anlaufströmen größere Anforderungen stellen (vielleicht ergab sich ein instabiler Zustand). Nichtsdestotrotz: so verpackte Festplatten nehme ich gar nicht mehr an.

    Spaßige Info: Versucht mal, einem DPD-Fahrer, der vernehmbar die Festplatte in dem Karton hin- und herschießt mitzuteilen, dass Ihr die Annahme verweigert. Der gibt (gab) sie einfach einem unbedarften Nachbarn ab, der dachte, er tue mir was gutes. Ziemlich daneben, der Bote.

    Der "magische" Befehl badblocks -n -s -v -c 256 -b 4096 -t "random" DEVICE hat es vollbracht. Danach rannte die SSD plötzlich wieder.

    das klingt *extrem* nach einem Problem analog wie das schon genannte bei den alten Samsung SSDs (soweit ich weiß, war der Fix damals lt. heise auch nur ein Umkopieren durch diese Samsung-Software).

    Hallo,

    solange ich focal drauf hatte hat das Schlafenlegen von RAIDz1-Membern mittels hd-idle funktioniert.

    Seit jammy nicht mehr, obwohl hd-idle eigentlich läuft. Problematisch ist, dass die Festplatten dicht verbaut sind und eigentlich nur temporär laufen sollen.


    Was kann ich tun, um das automatische Schlafenlegen wieder zu haben?


    Ein

    Code
    hdparm -y /dev/sdc
    hdparm -y /dev/sdd
    hdparm -y /dev/sde

    funktioniert. Kann man hd-idle wieder ans Laufen bekommen? Kann der smartd da eine Rolle spielen? Gibt es eine Möglichkeit, beide gleichzeitig laufen zu lassen?

    Hallo,

    ich hoffe, man kann diese Frage verzeihen:

    Ich habe in meinem vdr die mSATA-SSD ausgetauscht (zu SKC600MS/256GB) und jetzt leuchtet die Aktivitäts-LED fast dauerhaft. Nur manchmal geht sie so kurz aus, wie sie eigentlich angehen sollte. System läuft ohne Probleme. Kabel steckt richtig (andersrum leuchtet es gar nicht). Die SSD habe ich schon aus- und nochmals eingebaut, selbes Verhalten. Die alte SSD (Apacer 64GB) erzeugt dieses Problem nicht. Bin ein wenig baff. Das einzige, was mich wundern tut (neben dem Licht an): man kann relativ viel der Kontakte sehen, aber sie ist bis Anschlag drin und sie funktioniert ja auch).


    Hat da jemand einen Hinweis, was das sein könnte?

    Hallo,


    ich möchte ganz lieben Dank sagen und etwas Feedback geben:

    -Meinen vdrserver konnte ich ja mit seahawks Hinweis aus #3 und seinen PPA-Webseiten upgraden. (Automatisch war vdr nicht aktualisiert; ich habe dann mit dpkg --list | grep vdr | grep focal die Pakete identifiziert, die ich nach dem do-release Upgrade (mit den neuen PPAs) auf jammy einzeln installiert habe).

    -Bei meinem vdr3 hatte ich leider irgendwelche Abhängigkeiten drin (sh. RE: YAVDR für Ubuntu 22.04 LTS). Habe mir eine größere SSD beschafft, die alte Ubuntu-Installation via clonezilla zurückgesichert und eine weitere Ubuntu20.04-Installation unabhängig davon hinzugefügt. Dort habe ich yavdr-ansible nach Anleitung (aber gleich mit seahawk1986-PPAs und hoffentlich diesmal sauber angepasster host_vars/localhost) installiert. Anschließend habe ich noch die Einstellungen des alten vdrs übertragen und eine reccmds.custom.conf nach /etc/vdr/command-hooks kopiert. Bis jetzt schaut es ganz gut aus.

    Ich habe jetzt einmal einen Verstärker ausproibert -

    Axing BVS12-69N. Lieferzustand (nicht an den Reglern herumgespielt). TV-Ausgang Kabeldose, Adapter Koax-F-Stecker-Kabel, Verstärkereingang, Verstärkerausgang, F-Stecker-Kabel, großer Verteiler (mit 11dB Dämpfung lt. Aufdruck), F-Stecker-Kabel, M4.


    Das meint femon:

    Bei den öffentlichen HD-Sendern hatte ich (bis jetzt) keine Fehler mehr gesehen.

    Bei RTL NITRO gibt es leider noch (wenige) Fehler, wobei ich keine Ahnung habe, wie sichtbar die sind.


    Habe auch einen w_scan laufen lassen und die Parameter für Nitro sehen eigentlich noch gleich aus. Natürlich QAM256 - vielleicht grenzwertig. Meiner Meinung nach hat Pyur ordentlich herumgeschraubt, schon die Aufnahmengrößen sind massiv verändert (1/4 von vor anderthalb Jahren). Und nicht ohne Einfluss auf die Qualität.


    Aber ich verfolg das mal, ich könnte mir vorstellen, dass es im Großen und Ganzen jetzt gehen könnte.