vdr Neustart über Einstellungsmenü ohne reload der DVB-Treiber?

aus der Rubrik, was ich immer schon mal wissen wollte, aber mich nicht zu trauen fragte...

Meine runvdr basiert auf dem template der vdr Sourcen. Es sind keine Treiber eingetragen:

# Detect whether the DVB driver is already loaded
# and return 0 if it *is* loaded, 1 if not:
DriverLoaded()
{
  return 1
}

# Load all DVB driver modules needed for your hardware:
LoadDriver()
{
  return 0
}

# Unload all DVB driver modules loaded in LoadDriver():
UnloadDriver()
{
  return 0
}

# Load driver if it hasn't been loaded already:
if ! DriverLoaded; then
   LoadDriver
   fi

while (true) do
      eval "$VDRCMD"
      if test $? -eq 0 -o $? -eq 2; then exit; fi
      echo "`date` reloading DVB driver"
      $KILL $VDRPRG
      sleep 10
      UnloadDriver
      LoadDriver
      echo "`date` restarting VDR"
      done

Wenn ich aus dem vdr-Einstellungsmenü heraus einen vdr-Neustart durchführe, dauert es zwischen dem Beenden von vdr und dem Neustart von vdr teils eine Minute und mehr. Es werden offensichtlich sämtliche DVB-Treiber und ihre abhängigen Module entladen und neu geladen, was aufgrund von Abhängigkeiten naturgemäß dauert. Mir ist aber nicht klar, was diesen Mechanismus auslöst und ob/wie ich ihn abstellen kann.

In der HISTORY finde ich ich diesen schon 22 Jahre alten Vermerk:

Quote

- The new Setup item "Restart" can be used to force a complete restart of VDR,

including reloading the driver. Note that this can only work if VDR and the

driver are wrapped into a mechanism that actually performs this action if VDR

exits. The 'runvdr' script can be used for this purpose.

Das deutet darauf hin, dass der Schlüssel doch in der runvdr liegt. Aber wie funktioniert das, wenn kein einziges Treibermodul dort eingetragen ist? Schön wäre es, wenn man bei einem Neustart aus dem OSD heraus wählen könnte, ob nur vdr neu gestartet werden soll (weil man vielleicht ein Plugin in der /etc/vdr/conf.d/plugins.conf ergänzt hat oder ein Plugin mit geänderten Sourcen neu kompiliert hat) oder ob auch ein Treiber-reload erfolgen soll, weil irgendwas klemmt.

Vielleicht kann der Meister kls zur Erhellung beitragen?

Quote from seahawk1986

da kann z.B. ein Plugin, das noch einen Thread laufen hat, der etwas braucht, bevor er auf die Abbruchbedingung beim Stop des Plugins reagiert einige Zeit ins Land gehen lassen - eventuell hilft es die Logausgabe von VDR und Plugins mal voll aufzudrehen, damit man sehen kann, was passiert.

jepp, das hätte ich auch sehen müssen:

Mai 31 14:23:55 CoreELECTanixTX3 vdr[4337]: [4337] deleting plugin: softhdodroid
Mai 31 14:24:49 CoreELECTanixTX3 vdr.sh[4278]: Segmentation fault (core dumped)
Mai 31 14:24:50 CoreELECTanixTX3 vdr.sh[4278]: Fri May 31 14:24:50 CEST 2024 reloading DVB driver
Mai 31 14:24:50 CoreELECTanixTX3 vdr.sh[4278]: Fri May 31 14:24:50 CEST 2024 restarting VDR
Mai 31 14:24:50 CoreELECTanixTX3 vdr[6625]: [6625] VDR version 2.6.7 started

Habe die Ursache auch schon gefunden - den Fehler habe ich mir selbst ins softhdodroid-Plugin reingepatcht. Weil es beim Detachen zwecks Wechsel zu Kodi immer wieder crashte, hatte ich einen Codeabschnitt deaktiviert - der wird aber beim Beenden des Plugins benötigt.

Sieht in VideoExit() bei mir jetzt so aus:

        if (SuspendMode == 0) {
            VideoThreadExit();
            sleep(1);
        }

Der Restart klappt nun problemlos:

Mai 31 14:37:19 CoreELECTanixTX3 vdr[6983]: [6983] deleting plugin: softhdodroid
Mai 31 14:37:19 CoreELECTanixTX3 vdr[6983]: [6983] max. latency time 1 seconds
Mai 31 14:37:19 CoreELECTanixTX3 vdr[6983]: [6983] exiting, exit code 1
Mai 31 14:37:20 CoreELECTanixTX3 vdr.sh[4278]: Fri May 31 14:37:20 CEST 2024 reloading DVB driver
Mai 31 14:37:20 CoreELECTanixTX3 vdr.sh[4278]: Fri May 31 14:37:20 CEST 2024 restarting VDR
Mai 31 14:37:20 CoreELECTanixTX3 vdr[7066]: [7066] VDR version 2.6.7 started

(Die vdr.sh ist hier ein Script in der Host-Umgebung, das die runvdr in der chroot-Umgebung aufruft)

Mal sehen, ob ich jojo61 davon überzeugen kann...