Video Directory Scanner meldet Eingabe-/Ausgaberfehler für über NFS eingebundene Aufnahmen

  • Dank Avahi findet mein Testsystem mit yaVDR 0.7 unter Ubuntu Jammy (vdr 2.6.1) das Videoverzeichnis meines alten VDRs unter Debian Stretch (vdr 2.2.0). Es wird mit NFS bereitgestellt und steht unter /srv/vdr/video zur Verfügung. Dort sieht das Verzeichnis gut aus. Doch im OSD werden nur manche der Aufnahmen angezeigt.


    Der Video Directory Scanner auf dem Testsystem meldet für viele der Info- und Resume-Dateien Eingabe-/Ausgabefehler, die aus den Funktionen cResumeFile::Read und cRecording::cRecording in recording.c stammen (bei mir sind's die Zeilen 301 und 900). Allerdings durchläuft der Scanner nach meinem Verständnis nur diejenigen Aufnahmen, die er für "neu" hält und nicht bei jedem Start das gesamte Aufnahmeverzeichnis. Jedenfalls ist die Anzahl der Fehlermeldungen stets deutlich niedriger als die Anzahl der Aufnahmen.


    Wenn ich mit find ... | wc -l die Info-Dateien zähle, ist das Ergebnis auf beiden Rechnern gleich. Wenn ich eine der Dateien, die dem Scanner Probleme bereiten, mit ls, cat oder file] anschaue, tritt kein Fehler auf. Laut find handelt es sich um UTF-8 kodierte Textdateien, und das ist auch die Kodierung, die beide VDRs benutzten.


    Warum also hat der Video Directory Scanner Probleme?

  • Sieht mir nach fehlenden Zugriffsrechten aus.


    evtl. ist unterschiedliche numerische UserID die Ursache?

    Gruss
    SHF


  • Sieht mir nach fehlenden Zugriffsrechten aus.


    evtl. ist unterschiedliche numerische UserID die Ursache?

    Das war auch meine erste Idee, obwohl zwei Clients unter MLD keine Probleme haben. Die Rechtebehandlung unter NFS finde ich ziemlich undurchsichtig. Und das sogenannte NFS ID Mapping wird dem Namen ja nicht gerecht.


    Doch heute habe ich dann sogar auf dem Server UID und GID von vdr auf den von yaVDR benutzten Wert 666 umgestellt. Und das Problem tritt immer noch auf :(

  • Schlechtes LAN. Hatte ich auch. Bei mir war ein Switch defekt.

    Das glaube ich eher nicht. Irgendwie scheint es ein VDR-spezifisches Problem zu sein. Denn andere Programme haben keine Probleme beim Zugriff auf das entfernte Videoverzeichnis, z.B. find: Auf dem Server

    Code
    root@spiro:~# find /var/lib/video/ -user vdr -ls | wc -l
    53056

    und dem Rechner mit yaVDR

    Code
    root@taco:~# find /net/spiro/var/lib/video/ -user vdr -ls | wc -l
    53056
    root@taco:/tmp# sudo -u vdr find /net/spiro/var/lib/video/ -user vdr -ls | wc -l
    53056

    Dabei werden keine Fehler gemeldet. Aber vielleicht liefern ja folgende Einträge in /var/log/syslog, die ich nicht verstehe, einen Hinweis:

    Code
    Aug 18 16:53:46 taco vdr: video: 22:03:15.416  +37 1145   0/\ms  81+1+4 v-buf
    Aug 18 16:54:46 taco vdr: video: 22:04:15.418  +37 1145   0/\ms  79+1+4 v-buf
    Aug 18 16:55:01 taco systemd[1]: net-spiro-var-lib-video.mount: Deactivated successfully.
    Aug 18 16:55:46 taco vdr: video: 22:05:15.420  +37 1113   0/\ms  72+1+4 v-buf
    Aug 18 16:56:30 taco kernel: [ 1444.537546] nfs: Deprecated parameter 'intr'
    Aug 18 16:56:46 taco vdr: video: 22:06:15.423  +37 1113   0/\ms  60+1+4 v-buf
    Aug 18 16:57:45 taco systemd[1]: net-spiro-var-lib-video.mount: Deactivated successfully.
    Aug 18 16:57:46 taco vdr: video: 22:07:15.425  +37 1177   0/\ms  75+1+4 v-buf

    Schreiben in das Verzeichnis auf dem Server geht auch:

    Code
    root@taco:/tmp# sudo -u vdr touch /net/spiro/var/lib/video/.taco

    Ergebnis:

    Code
    root@spiro:~# ls -l /var/lib/video/.taco
    -rw-rw-r-- 1 vdr vdr 0 Aug 18 17:10 /var/lib/video/.taco
  • Noch ein Hinweis, dass es eher ein VDR-spezifisches Problem ist: Der Video Directory Scanner meldet ein Problem mit einer Datei

    Code
    Aug 18 18:47:17 taco vdr[1369]: [1400] ERROR (recording.c,900): /srv/vdr/video/VDR_Recordings_on_spiro(nfs)/Serien/Heimat/Weihnacht_wie_noch_nie_(1935)~Reichshöhenstraße_(1938)/2023-05-08.00.49.50-0.rec/info: Eingabe-/Ausgabefehler

    die mit cat gelesen werden kann:

  • Könnte es etwas mit der Option --dirnames zu tun haben?


    Auf dem Server wird sie nicht benutzt, d.h. ENC ist 0:

    Code
    root@spiro:~# vdr --showargs | grep dirnames

    Unter yaVDR ist ENC auf 1 gesetzt:

    Code
    root@taco:~# vdr --showargs | grep dirnames
    --dirnames=,,1

    Leider zeigt ein Test: Wenn ich vdr unter yaVDR ohne --dirnames=,,1 starte, tritt der Fehler auch auf :(

  • Ist das reproduzierbar? Also, meldet VDR das bei jedem Neustart bei dieser Datei?


    Code
    /srv/vdr/video/VDR_Recordings_on_spiro(nfs)/Serien/Heimat/Weihnacht_wie_noch_nie_(1935)~Reichshöhenstraße_(1938)/2023-05-08.00.49.50-0.rec/info

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Ist das reproduzierbar? Also, meldet VDR das bei jedem Neustart bei dieser Datei?

    Gute Frage! Ich hab's geprüft und die Antwort lautet nein, der Fehler wird für diese bestimmte Datei außerst selten gemeldet.


    Die Aufzeichnung wurde am 05.05.23 gemacht. Seitdem wurde VDR auf dem Testsystem 107 mal gestartet:

    Code
    root@taco:~# journalctl -u vdr --no-pager -S "2023-05-23" | grep 'Starting Video Disk Recorder...' | wc -l
    107

    Der Fehler für die Datei wurde nur viermal gemeldet:

    Code
    root@taco:~# journalctl -u vdr --no-pager | grep Weihnacht_wie_noch_nie | grep ERROR | wc -l
    4

    Fehler beim Zugriff auf das eingebundene Verzeichnis wurden aber seit dem Tag der Aufzeichnung 13808 mal gemeldet:

    Code
    root@taco:~# journalctl -u vdr --no-pager -S "2023-05-23" | grep '/srv/vdr/video/VDR_Recordings_on_spiro(nfs)' | grep ERROR | wc -l
    13808

    Und weil Statisken so viel Spaß machen: Nur in 682 Fehlerfällen enthielt der Dateiname eine Tilde:

    Code
    root@taco:~# journalctl -u vdr --no-pager -S "2023-05-23" | grep '/srv/vdr/video/VDR_Recordings_on_spiro(nfs)' | grep ERROR | grep '~' | wc -l
    682
  • Die Fehlermeldung an den Stellen bedeutet AFAIK, dass die Datei existiert, der VDR sie aber nicht einlesen kann.


    Seitdem wurde VDR auf dem Testsystem 107 mal gestartet:

    [...]

    Der Fehler für die Datei wurde nur viermal gemeldet:

    Dann ist es also wahrscheinlich nicht reproduzierbar.


    Fehler beim Zugriff auf das eingebundene Verzeichnis wurden aber seit dem Tag der Aufzeichnung 13808 mal gemeldet:

    Also etwa 130 pro Start.

    Wobei der VDR das Video-Verzeichnis auch zwischen drin aktualisieren kann.

    Mehr als maximal etwa 130 Dateien sollten es aber nicht sein, wenn es immer die Gleichen sind.


    Du könntest mal versuchen zB. mit "cut" und "unique" die Dateinamen aus der Logfile zu extrahieren.

    Und bei 130 oder weniger mal die Dateinamen auf Gemeinsamkeiten überprüfen.

    Wenn es ein paar hundert verschieden Dateien sind, liegt es eher am NFS. Gibt es das evtl. irgendwo eine Beschränkung der offenen Dateien oder einen Timeout?

    Nur in 682 Fehlerfällen enthielt der Dateiname eine Tilde:

    Die Tilde ist ein ganz normales ASCII-Zeichen, also hier normalerweise unproblematisch.

    Ich würde mal nach Umlauten suchen.

    Gruss
    SHF


  • In den 13808 Fehlermeldungen werden Probleme mit 10292 verschiedenen Dateien gemeldet:

    Code
    root@taco:~# journalctl -u vdr --no-pager -S "2023-05-23" | grep '/srv/vdr/video/VDR_Recordings_on_spiro(nfs)' | grep ERROR | sed -E 's,.*/srv/vdr/video/VDR_Recordings_on_spiro\(nfs\)/,,' | sed -E 's,: Eingabe\-/Ausgabefehler.*,,' | wc -l
    13808
    root@taco:~# journalctl -u vdr --no-pager -S "2023-05-23" | grep '/srv/vdr/video/VDR_Recordings_on_spiro(nfs)' | grep ERROR | sed -E 's,.*/srv/vdr/video/VDR_Recordings_on_spiro\(nfs\)/,,' | sed -E 's,: Eingabe\-/Ausgabefehler.*,,' | sort -u | wc -l
    10292

    Da auf dem Server zwischenzeitlich immer wieder neue Aufzeichnungen hinzugekommen und alte gelöscht worden sind, scheint mir ein Vergleich mit der aktuellen Anzahl von info- und resume-Dateien auf dem Server nicht sinnvoll. Bei meinen wenigen Versuchen, eine Aufzeichnung abzuspielen, gab es ja ebenfalls Eingabe-/Ausgabefehler. Ich vermute deshalb, dass es ein Problem mit allen Dateien ist. Und vermutlich ein eigentlich offensichtliches Problem. Nur ich steh' leider wie der Ochs vorm Berg und sehe es nicht ...

  • Hat deine NAS vielleicht ein Dateisystem, was bestimmte Zeichen im Dateinamen nicht akzeptiert?

  • Könnte das Problem etwas damit zu tun haben, wie yaVDR das Server-Verzeichnis einbindet? Es ist eine Kette von Verweisen:

    Code
    root@taco:~# tree /srv/vdr/video
    /srv/vdr/video
    └── VDR_Recordings_on_spiro(nfs) -> /media/vdr/VDR Recordings on spiro for taco

    Die einzelnen Aufzeichnungn werden erst am Ende der Verweiskette gefunden:

    Code
    root@taco:~# find '/srv/vdr/video/VDR_Recordings_on_spiro(nfs)' -ls
      1181519      0 lrwxrwxrwx   1 root     root           43 Aug 19 18:45 /srv/vdr/video/VDR_Recordings_on_spiro(nfs) -> /media/vdr/VDR\ Recordings\ on\ spiro\ for\ taco
    Code
    root@taco:~# find /media/vdr/VDR\ Recordings\ on\ spiro\ for\ taco -ls
       138883      0 lrwxrwxrwx   1 root     root           24 Aug 20 11:52 /media/vdr/VDR\ Recordings\ on\ spiro\ for\ taco -> /net/spiro/var/lib/video
  • Hat deine NAS vielleicht ein Dateisystem, was bestimmte Zeichen im Dateinamen nicht akzeptiert?

    Das Dateisystem auf auf Server mit vdr 2.2.0 (spiro, Debian Stretch) und yaVDR-Testsystem mit vdr 2.6.1 (taco, Ubuntu Yammy) ist ext4. Wenn meine MLD-Clients auf die Aufzeichnungen auf dem Server zugreifen, gibt es keine Probleme.

  • VDR kann manchmal auf eine Datei im Netzwerk zugreifen, und manchmal kann VDR auf diese Datei nicht zugreifen.

    Also ich würde hier nicht nach ~, Umlauten, Verlinkungen, Berechtigungen, ... suchen. Da wäre der Fehler bei einer bestimmten Datei doch reproduzierbar.


    Ich würde prüfen:

    • Stabilität des Netzwerks
    • Timeouts wenn Festplatten schlafen und geweckt werden müssen
    • Im Code von VDR prüfen, mit welchem Befehl VDR versucht auf die Datei zuzugreifen. Den exakten Fehlercode im syslog ausgeben, und nach möglichen Ursachen für diesen Fehlercode suchen

    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • 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?

  • Tausch mal die 50cm "Stummel"-Kabel aus - klingt nach "wurde mal geknickt" oder einfach alterslahm.

    Bzw. - hatte ich leider auch schon - schlechte LAN-Dosen-Verkabelung (die vielen dünnen, bunten Käbelchen), die zu unstabiler bzw. tw. gar keiner Verbindung führte; musste bei manchen Dosen bis zu 3 mal nachgebessert werden.

    Viel Erfolg!

    MyVDR: yaVDR-Ansible (Ubuntu 20) - softhddevice-openglosd (ffmpeg 2.8) - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 18 - inputstream + amazon vod
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 120 GB SSD | 3 TB HDD

  • > Wie sollte ich bei der Fehlersuche vorgehen?

    Komponenten austauschen, und testen.

    Ich habe den Switch im Verdacht. Kann aber auch ein Kabel sein, oder ...

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

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

  • 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?

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!