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

maf · 22. Juni 2023

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?

SHF · 20. Juli 2023

Sieht mir nach fehlenden Zugriffsrechten aus.

evtl. ist unterschiedliche numerische UserID die Ursache?

MarkusE · 20. Juli 2023

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

maf · 18. August 2023

Zitat von 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

maf · 18. August 2023

Zitat von MarkusE

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

maf · 18. August 2023

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:

Code

malte@taco:~$ cat '/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'
C C-61441-10017-11150 3sat HD (C)
E 5228 1683499740 6900 4E 1F
T Heimat. Eine deutsche Chronik (3/7)
S Weihnacht wie noch nie (1935)/Reichshöhenstraße (1938)
D Lucie will zu den höheren Kreisen gehören und schafft es, mit ihrem Eduard die Villa mit 52 Fenstern zu bauen. Indes entdeckt Hänschen sein Talent als Scharfschütze.|Wilfried kommt von seiner SS-Ausbildung zurück und organisiert mit Lucie ein Treffen hoher NSDAP-Funktionäre in der neuen Villa des Bürgermeisters. Die Reichshöhenstraße soll gebaut werden, und Otto Wohlleben kommt bei Familie Simon unter.|Darsteller:|Maria - Marita Breuer|Katharina - Gertrud Bredel|Mathias - Willi Burger|Luci - Karin Rasenack|Eduard - Rüdiger Weigand|Pauline - Eva Maria Bayerwaltes|Regie: Edgar Reitz|Buch/Autor: Edgar Reitz, Peter Steinbach|HD-Produktion
G 10
X 2 03 deu Mono
X 2 41 mul Klare Sprache
X 2 03 mis ohne Audiodeskription
X 4 42 deu Dolby Digital 2.0
X 5 0B deu HDTV
X 3 10 deu DVB-Untertitel
X 2 05 mis
X 2 05 mul
X 3 03 deu
V 1683499800
F 50
P 50
L 99
@ <epgsearch><channel>50 - 3sat HD (C)</channel><searchtimer>Heimat Eine deutsche Chronik</searchtimer><start>1683499800</start><stop>1683506700</stop><s-id>736</s-id><eventid>5228</eventid></epgsearch>

Alles anzeigen

maf · 18. August 2023

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

Code

Usage: vdr [OPTIONS]
...
            --dirnames=PATH[,NAME[,ENC]]
                           set the maximum directory path length to PATH
                           (default: 4095); if NAME is also given, it defines
                           the maximum directory name length (default: 255);
                           the optional ENC can be 0 or 1, and controls whether
                           special characters in directory names are encoded as
                           hex values (default: 0); if PATH or NAME are left
                           empty (as in ",,1" to only set ENC), the defaults
                           apply

Alles anzeigen

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

MarkusE · 19. August 2023

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

maf · 19. August 2023

Zitat von MarkusE

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

SHF · 20. August 2023

Die Fehlermeldung an den Stellen bedeutet AFAIK, dass die Datei existiert, der VDR sie aber nicht einlesen kann.

Zitat von maf

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.

Zitat von maf

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?

Zitat von maf

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.

maf · 20. August 2023

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

wirbel · 20. August 2023

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

maf · 20. August 2023

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

Code

root@taco:~# find /net/spiro/var/lib/video -ls | head
378208257     12 drwxr-xr-x 111 vdr      vdr         12288 Aug 19 23:30 /net/spiro/var/lib/video
416317441      4 drwxr-xr-x   3 vdr      vdr          4096 Dez 10  2022 /net/spiro/var/lib/video/Ich_bin_dein_Mensch
416317442      4 drwxr-xr-x   2 vdr      vdr          4096 Dez 10  2022 /net/spiro/var/lib/video/Ich_bin_dein_Mensch/2022-12-10.20.15.58-0.rec
338952207 2048120 -rw-r--r--   1 vdr      vdr      2097266712 Dez 10  2022 /net/spiro/var/lib/video/Ich_bin_dein_Mensch/2022-12-10.20.15.58-0.rec/00001.ts
338952212  304824 -rw-r--r--   1 vdr      vdr       312133580 Dez 10  2022 /net/spiro/var/lib/video/Ich_bin_dein_Mensch/2022-12-10.20.15.58-0.rec/00002.ts
416284700       4 -rw-r--r--   1 vdr      vdr             903 Dez 10  2022 /net/spiro/var/lib/video/Ich_bin_dein_Mensch/2022-12-10.20.15.58-0.rec/info
416284698    2344 -rw-r--r--   1 vdr      vdr         2393448 Dez 10  2022 /net/spiro/var/lib/video/Ich_bin_dein_Mensch/2022-12-10.20.15.58-0.rec/index
378306562       4 drwxr-xr-x   3 vdr      vdr            4096 Jul 18 22:52 /net/spiro/var/lib/video/Der_Rausch
379506690       4 drwxr-xr-x   2 vdr      vdr            4096 Aug  6 13:29 /net/spiro/var/lib/video/Der_Rausch/2023-07-18.22.50.54-0.rec
331874716 2040028 -rw-r--r--   1 vdr      vdr      2088980987 Jul 19 00:42 /net/spiro/var/lib/video/Der_Rausch/2023-07-18.22.50.54-0.rec/00003.ts

Alles anzeigen

maf · 20. August 2023

Zitat von wirbel

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.

MarkusE · 20. August 2023

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

maf · 20. August 2023

Antworten in umgekehrter Reihenfolge:

Zitat von MarkusE

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

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

C

int cResumeFile::Read(void)
  ...
  if (fileName) {
    ...
        int f = open(fileName, O_RDONLY);
        if (f >= 0) {
           ...
        else if (errno != ENOENT)
           LOG_ERROR_STR(fileName);
        ...
        FILE *f = fopen(fileName, "r");
        if (f) {
        ...
        else if (errno != ENOENT)
           LOG_ERROR_STR(fileName);

Alles anzeigen

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);

Zitat von MarkusE

Timeouts wenn Festplatten schlafen und geweckt werden müssen

Die Platten auf Server und Testsystem laufen durch.

Zitat von MarkusE

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?

davie2000 · 20. August 2023

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!

MarkusE · 20. August 2023

> Wie sollte ich bei der Fehlersuche vorgehen?

Komponenten austauschen, und testen.

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

maf · 20. August 2023

Zitat von davie2000

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.

Zitat von MarkusE

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.

maf · 21. August 2023

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?

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

Jetzt mitmachen!

Teilen

Tags