VDR version 2.7.7 freigegeben

Quote from kls

Es ist wohl eher unwahrscheinlich, dass vom Setzen von Now bis zur Verwendung 20 Minuten vergehen können.

Mag ja sein, dass das unwahrscheinlich ist. Aber der syslog belegt genau das. Die Frage ist jetzt, was kann dazu führen, dass das so lange dauert? Eine Sperre auf ein VDR Objekt? Wenn ja, welches? Ein Aufruf einer API des DVB Treibers, der nicht zurückkommt? Wenn ja, welcher?

> Oder kann es sein, dass der rpi4s in der Zwischenzeit "geschlafen" hat?

Nein, hat er nicht. Du hast ja inzwischen den kompletten syslog. Der rpi4s läuft 24/7.

> Auffällig ist, dass der Timer in der selben Sekunde startet, in der EPGSearch: search timer update finished passiert:

Scheint mir eher ein Zufall. Vor allem, da EPGSearch: search timer update started ja eine Sekunde früher passiert. Ich denke, dass

2025-08-06T20:47:09.380075+02:00 rpi4s vdr: [229821] frontend 0/0 regained lock on channel 19 (zdf_neo HD), tp 111361

hier relevant ist. Seltsam ist, dass es keine lost lock Meldung gibt. Seltsam ist auch, dass es mit zdf_neo HD überhaupt ein Problem gibt. Eigentlich empfange ich diesen Sender hier sehr gut.

> Auf welchen Wert hast du denn den Watchdog eingestellt?

--watchdog=0

> Setz den mal auf z.B. 60.

Weiß nicht, habe damit schlechte Erfahrung. Dann bricht noch eine laufende Aufzeichnung ab.

Lieber herausfinden, was die Hauptschleife blockiert.

Quote from kls

Vielleicht sollte ich den Defaultwert ändern.

Bei mir sind wegen verschlüsselten Sendern --watchdog=120 und #define MAXBROKENTIMEOUT 120000 // milliseconds nötig.
Vielleicht sollten beide geändert werden.

Spricht eigentlich was dagegen für vdr-plugin-statusleds das aufzunehmen?
https://github.com/j1rie/vdr-plug…ch_for_vdr.diff
--- vdr.c.a    2020-08-06 21:10:29.297129795 +0200
+++ vdr.c    2020-08-06 21:15:12.943092492 +0200
@@ -138,10 +138,10 @@ static bool DropCaps(void)
     }
  cap_t caps;
  if (cap_flag_value == CAP_SET)
-     caps = cap_from_text("= cap_sys_nice,cap_sys_time,cap_net_raw=ep");
+     caps = cap_from_text("= cap_sys_nice,cap_sys_time,cap_net_raw=ep,cap_sys_tty_config=ep");
  else {
     fprintf(stdout,"vdr: OS does not support cap_sys_time\n");
-     caps = cap_from_text("= cap_sys_nice,cap_net_raw=ep");
+     caps = cap_from_text("= cap_sys_nice,cap_net_raw=ep,cap_sys_tty_config=ep");
     }
  if (!caps) {
     fprintf(stderr, "vdr: cap_from_text failed: %s\n", strerror(errno));

Beim Entschlüsseln dauert es manchmal etwas, bis der entschlüsselte Datenstrom zuverlässig fliesst.
Mit 60 hatte ich manchmal kaputte Aufnahmen, seit ich beides auf 120 gestellt habe sind die Aufnahmen in Ordnung.

Quote from kls

Ist es bei dir schon öfter vorgekommen, dass die Hauptschleife länger als 60 Sekunden blockiert wird?

Ich verfolge den Thread nur lose. Aber auf die Frage hin fällt mir ein, dass ich schon des Öfteren den Fall hatte, dass der VDR im Menü einfach eingefroren ist. Wie ich mich zu erinnern glaube, bevorzugt beim zeitgleichen Schneiden von Aufnahmen. Nach – gefühlt – einer Minute erfolgte dann ein Neustart. Kein Ahnung, ob das damit zusammenhängt und ob nicht vielleicht auch ein Plugin mit im Spiel ist. Aber es ist zumindest eine ergänzende Beobachtung.

PS: Im Syslog habe ich nichts gefunden, was mir einen Hinweis auf die Ursache gegeben hätte.

Quote from kls

Wozu dient dieses Plugin?

https://github.com/j1rie/vdr-plug…lob/main/README
This plugin shows the status of VDR via LED:
when VDR starts, the LED is turned on;
when VDR stops, the LED is turned off;
if VDR is recording, the LED blinks (as often as recordings are active).

Die LED ist dabei an einer Tastatur oder an einem meiner IR Empfänger.

Quote from kls

aber warum bei --watchdog? Wieso bleibt die Hauptschleife da so lange blockiert?

Hab ich nie untersucht. Ist einfach Versuch und Irrtum, mit 60 geht's nicht zuverlässig, mit 120 geht's.

Quote from jrie

Spricht eigentlich was dagegen für vdr-plugin-statusleds das aufzunehmen?
https://github.com/j1rie/vdr-plug…ch_for_vdr.diff
--- vdr.c.a    2020-08-06 21:10:29.297129795 +0200
+++ vdr.c    2020-08-06 21:15:12.943092492 +0200
@@ -138,10 +138,10 @@ static bool DropCaps(void)
     }
  cap_t caps;
  if (cap_flag_value == CAP_SET)
-     caps = cap_from_text("= cap_sys_nice,cap_sys_time,cap_net_raw=ep");
+     caps = cap_from_text("= cap_sys_nice,cap_sys_time,cap_net_raw=ep,cap_sys_tty_config=ep");
  else {
     fprintf(stdout,"vdr: OS does not support cap_sys_time\n");
-     caps = cap_from_text("= cap_sys_nice,cap_net_raw=ep");
+     caps = cap_from_text("= cap_sys_nice,cap_net_raw=ep,cap_sys_tty_config=ep");
     }
  if (!caps) {
     fprintf(stderr, "vdr: cap_from_text failed: %s\n", strerror(errno));

Display More

Das klingt für mich sehr bekannt, mit den negativen Auswirkungen, derer ich weiterhin aus dem Weg gehe, siehe die Posts zwischen diesem: vdr-plugin-statusleds 0.4 und jenem: vdr-plugin-statusleds 0.4

Viele Grüße,
Chriss