Beiträge von maf

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.

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

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:

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

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

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

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

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

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:

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:

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:

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:

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

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

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

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

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

Unter yaVDR ist ENC auf 1 gesetzt:

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

Noch ein Hinweis, dass es eher ein VDR-spezifisches Problem ist: Der Video Directory Scanner meldet ein Problem mit einer Datei

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:

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>

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

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

und dem Rechner mit yaVDR

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:

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:

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

Ergebnis:

root@spiro:~# ls -l /var/lib/video/.taco
-rw-rw-r-- 1 vdr vdr 0 Aug 18 17:10 /var/lib/video/.taco

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

Danke fürs Anschauen und den Vorschlag. Ich werd's ausprobieren und berichten

In der arte-Mediathek gibt es zur Zeit eine sechsteilige BBC-Produktion von "Stolz und Vorurteil". Die Folgen haben neben deutscher und französischer auch eine englische Tonspur, die bei den Ausstrahlungen auf arte nicht dabei ist, zumindest im Vodafone-Kabelnetz. Allerdings ist diese englische Tonspur verknüpft mit französischen Untertiteln.

Ich weiß, dass ich mit vdr-transcode die Folgen aus der Mediathek in VDR-Aufnahmen umwandeln könnte. Aber ist es auch möglich, dabei die französischen Untertitel aus der Tonspur zu entfernen?

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?

Die Distrubutionen, die ich kenne, haben eigene Repositorys, um zusammen mit dem Quellcode von Upstream distributionsspezifische Patches und alles, was zur Paketerstellung benötigt wird, zu verwalten, z.B. das Repository für Paket vdr von Debian. Und ich suche die Repositories, aus denen die Pakete in den yavdr-ansible PPAs gebaut werden.

Zitat von kfb77

hier

Tur mir leid, der Begriff Repositorys war missverständlich. Dein Link führt auf die PPAs, die ich kenne. Ich suche die (vermutlich) Git-Repositorys mit dem Quellcode, aus dem die Pakete in den PPAs gebaut werden.

Ich kenne die PPAs für yavdr-ansible, aber ich suche die Repositorys, aus denen diese Pakete (für jammy) gebaut werden. Könnte mir bitte jemand auf die Sprünge helfen?

Yep, das war's. Vielen Dank!

Danke für den Tip. Ich habe versuchsweise bei mehreren Auflösungen den Wert von „Schneide links und rechts ab (Pixel):“ geändert. Leider ohne Effekt auf die Streifen.

Da geht bei mir noch irgendwas durcheinander. Ich dachte, Overscan sei der Effekt, dass schmale Streifen an den seitlichen Rändern des eigentlichen Bildes u.U. nicht zu sehen sind. Aber bei mir ist es ja so, dass das Bild rechts und links schmale schwarze Streifen hat, also die verfügbare Bildschirmfläche nicht ausnutzt. Deshalb verstehe ich auch noch nicht, warum es helfen könnte, das Bild mit den Einstellungen des Treibers künstlich zu verkleinern. Ob allerdings am Rand etwas "fehlt", habe ich mangels geeigneter Testbilder bislang auch nicht feststellen können.

Das Attribut CurrentMetaMode ist bei yaVDR

malte@taco:~$ nvidia-settings --ctrl-display :0 --query CurrentMetaMode
libEGL warning: DRI2: failed to authenticate

  Attribute 'CurrentMetaMode' (taco:0.0): id=50, switchable=yes, source=xconfig :: DPY-2: 1920x1080_50 @1920x1080 +0+0
  {ViewPortIn=1920x1080, ViewPortOut=1920x1080+0+0}

und dem parallel installierten Debian Bullseye

malte@taco:~$ nvidia-settings --ctrl-display :0 --query CurrentMetaMode
Unable to init server: Verbindung ist gescheitert: Verbindungsaufbau abgelehnt
libEGL warning: DRI2: failed to authenticate

  Attribute 'CurrentMetaMode' (taco:0.0): id=50, switchable=yes, source=xconfig :: DPY-2: nvidia-auto-select @1920x1080 +0+0
  {ViewPortIn=1920x1080, ViewPortOut=1920x1080+0+0}

nach meinem Verständnis gleich. Beide benutzten die Treiber-Version 470.182.

Und eine Einstellung des Fernsehers zu ändern, scheint mir derzeit nicht die richtige Lösung, weil es ja unter Debian Bullseye keine Ränder gibt.

Das klingt gut. Leider habe ich in den Einstellungen des Plugins (im OSD) noch nichts gefunden, was für mich nach Overscan klingt. Könntest Du mir bitte sagen, wie die Einstellung heißt, die ich ändern muss?

Ich vermute mittlerweile, dass ich mich selbst ausgetrickst habe und bei ausbleibendem Bild am Fernseher als Quelle der Antenneneingang ausgewählt war. Doch das Antennenkabel steckt mittlerweile am yaVDR-Rechner. Nach der Installation eines CEC-Adapters erfolgt das Umschalten auf die "richtige" Quelle von alleine. Das ist gut für Schusselköpfe

Vielleicht kann ich die Tatsache nutzen, dass ich oben schon die gesamte Konfiguration beschrieben habe, um eine Zusatzfrage zu stellen. Mir ist aufgefallen, dass bei der Wiedergabe mit yaVDR das Bild rechts und links einen schmalen schwarzen Streifen hat (jeweils knapp 2% der Bildschirmbreite). Beim normanlen Fernsehempfang und mit den parallel zu yaVDR installieren Betriebssystemen (Windows 10, Debian Bullseye) gibt die nicht. Deshalb vermute ich, dass die Streifen durch eine Einstellung unter yaVDR zu beheben sind. Nur halt welche?

Die Erklärung für das von mir beschriebene "Problem" ist so einfach wie peinlich für mich: Der CEC-Adapter funktioniert prima und ich habe mich selbst ausgetrickst.

Offensichtlich war beim Fernseher der Antennen- und der HDMI-Eingang ausgewählt. Und ein Kanal, der seit Umstellung der Kabelkanäle nicht mehr existiert. Deshalb blieb nach dem Einschalten des Fernsehres der Bildschirm schwarz. Und es gab keine BIOS-Ausgaben und kein GRUB-Menü des Rechners. Beim Start des VDR schalteten dann cecremote-Plugin und CEC-Adapter den Eingang des Fernsehers um, Fernsehbild und OSD tauchten auf.