Beiträge von maf

    With Nouveau there may be problems with the hardware video decoder, but then the softhddevice will most likely work with software decoding.

    Dann sollte ich es wohl mit nvidia-tesla-470-driver oder einem (selbstgebauten) nvidia-driver versuchen.


    Mir ist allerdings nicht klar, was die Unterschiede zwischen bzw. die wechselseiten Vor- und Nachteile von nvidia-tesla-470-driver und nvidia-driver sind. Und deshalb auch nicht, ob sich ein eigenes Paket überhaupt lohnt. Kann jemand mir auf die Sprünge helfen?

    # update-glx --config nvidia There are 2 choices for the alternative nvidia (providing /usr/lib/nvidia/nvidia).

    Noch habe ich leider keine Wahl :) :

    Code
    root@taco:~# update-glx --config nvidia
    update-alternatives: Fehler: keine Alternativen für nvidia

    Danke für den Vorschlag! Als der Fehler auftrat, waren ja die Quellen bereits von Bullseye auf Bookworm umgestellt. Das wieder zurückzudrehen, um den Tesla-Treiber aus Bullseye zu installieren, habe ich mich nicht getraut. Ich habe auch überlegt, den Tesla-Treiber aus Bookworm zu installieren, war mich aber nicht sicher, ob ich dann den Treiberwechsel hinbekommen würde. Deshalb habe ich mich schließlich dazu entschlossen, mit apt autoremove nvidia* --purge den NVIDIA-Treiber zu entfernen. Nach einem Neustart wurde für die Karte automatisch der Nouveau-Treiber benutzt und ich konnte den Upgrade fortsetzen (und letztlich erfolgreich abschließen). Während des gesamten Upgrade war das System zum Glück im Multiuser-Mode.


    Eigentlich war ich überrascht, im Netz keine Berichte über diesen Stolperstein gefunden zu haben. Eigentlich sollte doch jeder, der unter Bullseye das Paket nvidia-driver installiert hatte, auf ihn stoßen.


    Hat jemand schon Erfahrungen damit gesammelt, wie nvidia-tesla-470-driver und vdr-plugin-softhddevice zusammenspielen? Oder tut es auch die aktuelle, angeblich deutlich verbesserte Version von Nouveau? Oder sollte ich mit Branch 470 von nvidia-graphics-driver ein eigenes Paket für Bookworm bauen?

    Hallo,


    ich habe ein Problem beim Upgrade meines VDR-Testsystems von Bullseye auf Bookworm.


    Unter Bullseye habe ich das Paket nvidia-driver für meine NVIDIA GT 710 installiert. Dieses Paket gibt es unter Bookworm nicht mehr. Der richtige Ersatz - wenn ich nicht zum Nouveau-Treiber wechseln will - ist vermutlich das Paket nvidia-tesla-470-driver. Aber wie kann ich den Wechsel zum neuen Paket im Zuge des Upgrades vollziehen?


    Der (in der Upgrade-Anleitung empfohlene) erste Schritt des Upgrades erkennt, dass der alte Treiber nicht mehr verfügbar sein wird und meldet den Fehler:

    Wie sollte ich jetzt vorgehen?

    Hallo!


    Statt viele eigene Anpassungen in yavdr-ansible vorzunehmen, würde ich gerne ein separates Projekt aufsetzen, in dem meine Playbooks, Roles, ... versammelt sind, und das existierende yavdr-ansible als Ansible Collection nutzen. Ganz naiv habe ich dazu yavdr-ansible um eine Datei galaxy.yml und eine Datei CHANGELOG.yml ergänzt. Es gelingt mir aber noch nicht, dieses Verzeichnis als Collection zu installieren:



    Als Werte für namespace und name habe ich in galaxy.yml jeweils yavdr angegeben. Das scheint mir nicht die Ursache für den Fehler. Aber was Ansible betrifft, bin ich noch Anfänger. Vielleicht kann mir jemand weiterhelfen, der sich schon besser auskennt.

    Ich habe vdrffs um eine zusätzliche Mount-Option nofile (in Anlehung an prlimit(1) bzw. prlimit(2)) ergänzt. Seit ich die auf 4096 (statt des Standwerts 1024) gesetzt habe, tritt der Fehler nicht mehr auf.


    /sbin/mount.vdrffs ist ist ein Verweis auf das eigentliche Programm /bin/vdrffs. Diesen Eintrag benutzt mount, wenn /etc/fstab einen Eintrag enthält, der als Typ des Dateisystems vdrffs angibt.

    Es könnte durch das Setup sein, dass einfach zu viele Dateien auf einmal geöffnet sind.

    Sehr gute Idee! In der Tat meldet nfsd auf dem Server den Fehler 24 ('Too many open files'), wenn auf dem Testsystem die Eingabe-/Ausgabefehler anfangen. Dass ich da nicht schon viel früher hingeschaut habe ...


    Ich habe daraufhin testweise das Soft-Limit für den vdrffs-Prozess von 1024 auf 4096 erhöht:

    Code
    root@spiro:~# prlimit --nofile --pid $(pidof /sbin/mount.vdrffs)
    RESOURCE DESCRIPTION              SOFT HARD UNITS
    NOFILE   max number of open files 1024 4096 files
    root@spiro:~# prlimit --nofile=4096 --pid $(pidof /sbin/mount.vdrffs)
    root@spiro:~# prlimit --nofile --pid $(pidof /sbin/mount.vdrffs)
    RESOURCE DESCRIPTION              SOFT HARD UNITS
    NOFILE   max number of open files 4096 4096 files

    Und beim nächsten Start des Testsystem gab es keine Fehler mehr, hurra!


    Leider weiß ich noch nicht, wie ich die Änderung am besten über den Neustart rette. Die von SHF verlinkte Anleitung und andere, die ich gefunden habe, beschreiben - soweit ich sie richtig verstanden habe -, wie man Begrenzungen für einen Benutzer oder einen Dienst dauerhaft ändern kann. Ich würde sie ja gerne für ein Programm ändern. Sicherlich könnte ich ein Skript schreiben, das nach mount läuft und letztlich obigen Befehl ausführt. Besser wäre wohl eine zusätzliche mount-Option, die das Limit mittels setrlimit(2) ändert. Aber vielleicht gibt es noch einen eleganteren Weg?

    Du kennst das distributedvideodir Plugin?

    Ja, das Plugin ist auf dem Server auch im Einsatz.


    Im Unterschied zum distributesvideodir-Plugin ist vdrffs ein virtuelles Dateisystem. Damit kann ich ein in sich geschlosses Dateisytem exportieren, das die Partitionen des alten VDR-Dateisystems zusammenfasst. Es ist mir nämlich nie so recht gelungen, die einzelnen Partitionen so per NFS zu exportieren, dass die Links zwischen den Partitionen auf Client-Seite wieder funktioniert hätten. Außerdem erspart vdrffs die Rekonfiguration auf Server und Client, wenn eine Partition hinzukommt oder wegfällt. Und das distributedvideodir-Plugin gab es - zumindest damals - unter MLD nicht.


    Wenn ich wüsste, wie ich die einzelnen Video-Partitionen des Servers exportieren und auf dem Testsystem so importieren kann, dass die Links funktioneren, könnte ich auf dem Testsystem das distributedvideodir-Plugin benutzen und müsste nicht das vdrffs-Dateisystem des Servers benutzen.

    Mittlerweile habe ich noch einen ganz anderen Verdacht: Kann es sein, dass der alte Server (Intel Pentium 4 541 3.20 GHz) für das Testsystem (Xeon E3-1226 v3 3.30 GHz) schlicht zu langsam liefert? Denn der Server wird nicht nur durch das Software-RAID belastet. Mehr Rechenleistung erfordert sicherlich mein selbstgeschriebenes vdrffs, das mittels FUSE die Partitionen des historischen verteilten VDR-Dateisystems zu einem zusammenfasst, das leicht per NFS exportiert werden kann. Für die RPi-2 MLD-Clients erfüllt vdrfffs seinen Zweck, aber die sind ja auch selbst hübsch langsam.

    Ich habe jetzt alle beteiligten Kabel und Switches stückweise ersetzt oder überbrückt - und die Fehler treten immer noch auf. Gleich geblieben sind nur die (onboard) Netzwerkkarten der beiden Rechner.


    Ich hoffe, ihr habt noch Vorschläge zur Suche nach Problemen mit dem Netzwerk:: Ich haber derzut nur eine: Ein Programm, mit dem ich Netzwerkverbindungen unabhängig von NFS und VDR testen kann? Vielleicht zunächst wischen den beiden Rechnern, dann zwischen einem dritten Rechner und jeweils einem der beiden Rechner?

    schlechte LAN-Dosen-Verkabelung

    Nur um ein mögliches Missverständnis aufzuklären: Nur die langsamen, aber funktionierenden Netzwerkverbindungen zu den MLD-Clients laufen über LAN-Dosen.

    Ich habe den Switch im Verdacht.

    Meinst Du den am Server oder den am Testsystem?


    Ich hatte gehofft, es gäbe vielleicht ein Diagnoseprogramm, das die Fehlerursache zumindest einkreisen könnte. Stattdessen also komponentenweise austauschen oder überbrücken. Ich hatte es befürchtet :-).


    Ich werde berichten, ob und wie ich eine Fehlerursache gefunden habe.

    Antworten in umgekehrter Reihenfolge:


    Im Code von VDR prüfen, [...]


    Die Fehlermeldungen stammen von LOG_ERROR_STR in recording.c. Zeilen 262 bis 301:

    und Zeilen 831 bis 900

    Code
    cRecording::cRecording(const char *FileName)
        ...
         FILE *f = fopen(InfoFileName, "r");
         if (f) {
         ...
         else if (errno != ENOENT)
            LOG_ERROR_STR(*InfoFileName);


    Timeouts wenn Festplatten schlafen und geweckt werden müssen

    Die Platten auf Server und Testsystem laufen durch.

    Stabilität des Netzwerks

    Der (dankenswerterweise wiederholte) Hinweis, dass es sich um ein Netzwerkproblem handeln könnte, hat mich zu folgendem Test veranlasst:

    Code
    root@taco:~# find /srv/vdr/video/VDR_Recordings_on_spiro\(nfs\)/* -name info -exec cat {} \; > /dev/null

    Und in der Tat: Für ein paar Dateien geht alles gut und dann kommen die Fehler:

    Code
    cat: '/srv/vdr/video/VDR_Recordings_on_spiro(nfs)/Kultur/Klassiker_der_Weltliteratur/Virginia_Woolf/2016-03-27.22.30.10001-0.rec/info': Eingabe-/Ausgabefehler
    find: ‘/srv/vdr/video/VDR_Recordings_on_spiro(nfs)/Kultur/Klassiker_der_Weltliteratur/Max_Frisch’: Eingabe-/Ausgabefehler
    cat: '/srv/vdr/video/VDR_Recordings_on_spiro(nfs)/Kultur/Klassiker_der_Weltliteratur/Gerhart_Hauptmann/2016-06-05.23.50.10001-0.rec/info': Eingabe-/Ausgabefehler
    find: ‘/srv/vdr/video/VDR_Recordings_on_spiro(nfs)/Kultur/Klassiker_der_Weltliteratur/Hans_Christian_Andersen’: Eingabe-/Ausgabefehler
    find: ‘/srv/vdr/video/VDR_Recordings_on_spiro(nfs)/Kultur/Klassiker_der_Weltliteratur/Jane_Austen’: Eingabe-/Ausgabefehler
    ...

    Wenn ich find nach jedem Aufruf von cat eine Pause verordne, geht alles gut (zumindest habe ich irgendwann die Geduld verloren, auf eine Fehlermeldung zu warten :-)):

    Code
    root@taco:~# find /srv/vdr/video/VDR_Recordings_on_spiro\(nfs\)/* -name info -exec cat {} \; -exec sleep 1 \; > /dev/null

    Server und Testsystem hängen jeweils mit einem kurzen Ethernet-Kabel an ihrem Gigabit-Switch. Von Switch zu Switch liegt ein langes Ethernet-Kabel (ich glaube etwa 20 m). Andere Netzwerkprobleme habe ich in der Vergangenheit noch keine festgestellt. Am gleichen Switch wie mein Testsystem hängt u.a. mein Arbeitsplatz und damit dessen Internetverbindung. Und ich habe schon gigabyteweise Dateien von zwischen einem alten Testsytem und dem Server hin- und herkopiert.


    Im Vergleich dazu haben meine beiden RPi 2 MLD-Clients, auf denen keine Probleme auftreten, eine abenteuerliche LAN-Verbindung: Vom Switch beim Server führt Ethernet-Kabel zur Wanddose, von dort eine umfunktionierte Telefonleitung (4 Adern, nicht verdrillt) zwei Stockwerke in den Keller zu einem Megabit-Switch und von dort geht es wieder über ehemalige Telefonleitungen in die Zimmer, in denen hinter Dose und Ethernet-Kabel die Clients werkeln. Das funktioniert seit Jahren ohne Probleme.


    Ist jetzt die Verbindung zwischen Server und Testsystem "zu schnell" für einen der beteiligten Rechner, oder ist eher eine der Komponenten zwischen Switch am Server und Testsystem (Kabel, Switch am Testsystem, Netzwerkkarte) die Fehlerquelle? Mit Netzwerk-Hardware habe ich leider keine Erfahrung. Wie sollte ich bei der Fehlersuche vorgehen?