Trigger von UPDR auf verbundenen VDRs bei Aufnahmestart auf Server

Hi,

vielleicht löse ich auch ein schon bereits gelöstes Problem.

Ich habe mehrere vdr-Clients mit einem vdr-Server verbunden. An dem Server ist eine große Festplatte angeschlossen und die Aufnahmen (egal von wo programmiert) sollen durch den Server auf der Server-Festplatte gemacht werden. Funktioniert prima. Leider erkennt der vdr-Client aber nicht von alleine, dass es eine neue Aufnahme gibt und liest deshalb das Aufnahmeverzeichnis nicht neu ein. Hier setzt meine Idee an: sobald eine Aufnahme gestartet wird, wird an alle verbundenen Clients das SVDRP-Kommando UPDR gesendet. Hier mein Patch für den Server (client-seitig muss ja nichts gemacht werden):

diff -Naur vdr-2.6.7/recorder.c vdr/recorder.c
--- vdr-2.6.7/recorder.c        2024-07-23 18:51:28.700000000 +0200
+++ vdr/recorder.c      2024-07-23 20:08:54.588000000 +0200
@@ -9,6 +9,7 @@

 #include "recorder.h"
 #include "shutdown.h"
+#include "svdrp.h"

 #define RECORDERBUFSIZE  (MEGABYTE(20) / TS_SIZE * TS_SIZE) // multiple of TS_SIZE

@@ -338,6 +339,17 @@
                        }
                     InfoWritten = true;
                     cRecordingUserCommand::InvokeCommand(RUC_STARTRECORDING, recordingName);
+                    // trigger UPDR on each client
+                    cStringList cSvdrpClients;
+                    cStringList cSvdrpResponse;
+                    if (GetSVDRPServerNames(&cSvdrpClients)) {
+                       for (int i = 0; i<cSvdrpClients.Size(); i++) {
+                          if (char *s = cSvdrpClients[i]) {
+                             dsyslog("New recording: Trigger Client %d: %s", i, s);
+                             ExecSVDRPCommand(s, "UPDR", &cSvdrpResponse);
+                             }
+                          }
+                       }
                     frameChecker->SetFrameDelta(PTSTICKS / frameDetector->FramesPerSecond());
                     }
                  if (firstIframeSeen || frameDetector->IndependentFrame()) {

Dazu zwei Fragen: gab es hierzu schon eine elegante(re) Lösung und/oder spricht etwas gegen den Patch? Wenn man die Funktionalität im Menü noch ein-/ausschaltbar macht, wäre es vielleicht auch etwas für den offiziellen vdr.

Quote from kfb77

Wie wäre es mit einem touch aus dem post recording hook auf die .update im root Aufnahmeverzeichnis ?

Stimmt, die .update Methode gibt es schon sehr lange und am Ende kommt es auf das gleiche raus. Einziger Nachteil mit dem Skript: es muss auf den betroffenen VDRs (normalerweise der Server) eingerichtet werden. Ich fände es elegant, wenn die schon vorhandene Peering-Funktionalität hier etwas erweitert und genutzt wird.

Quote from kls

Wenn eine Aufnahme startet wird .update getoucht, was bei allen Clients, die das gleiche Video-Directory benutzen, zum Update führt.

Habe es nochmals ohne Patch getestet. Das "touchen" von .update macht vdr (bei mir 2.6.7) nur, wenn bereits eine .update existiert. --> ohne eine existierende .update triggert vdr selbst auch kein "touch". Ist das so gewollt?

Verständnisfrage: wird durch das "touchen" durch den VDR Server beim Start der Aufnahme das Aufnahmeverzeichnis durch den Server ebenfalls komplett neu eingelesen?

Ok, dann ist die Funktion as intended - man sollte nur (was ich nicht gemacht habe) zuvor eine .update anlegen. Dann greift der Mechanismus, benötige kein recordings-script und ich kann auf den Patch verzichten.

Quote from kls

Die Funktion BroadcastSVDRPCommand() gibt es aber noch, die könnte mrjoe direkt verwenden. Wobei sein Ansatz nur beim Start einer Aufnahme greift. Wenn dies aber parallel zu .update wirken soll, wäre wohl die TouchUpdate() Funktion der zentralere Ort.

Leider weiß ich nicht mehr, wie sich das mit dem "too fast" ausgewirkt hat. Das müsste mal jemand untersuchen, bevor wir das wieder einbauen.

Du meinst das

BroadcastSVDRPCommand("UPDR");

in die Funktion cRecordings::TouchUpdate(void) einzubauen? Kann ich gerne machen und testen.

Quote from kls

Ja, siehe hier:

http://git.tvdr.de/?p=vdr.git;…f6bf239f23f095836e3c65f6d

Sorry für die späte Rückmeldung, kam erst jetzt dazu. Testaufbau:

• VDR Server Version 2.6.7 ungepatcht
• VDR Client 1 Version 2.6.9 ungepatcht
• VDR Client 2 Version 2.6.9 ungepatcht
• .update aus dem Aufnahmeverzeichnis gelöscht

Tests:

1. Timer programmiert via Live auf dem VDR Server. VDR Server nimmt auf, Aufnahme ist sichtbar in der Live Aufnahmeübersicht, Clients sehen die neue Aufnahme nicht (erklärbar, da .update fehlt und diese nicht bei Bedarf angelegt wird; kein Triggern von UPDR)

2. Änderungen aus dem diff von dir am VDR Server händisch übernommen (aufgrund des Versionssprungs passte der diff nicht mehr ganz). VDR am Server neu gestartet. Beide Clients haben direkt auf den discover-Broadcast reagiert und sich somit registriert. Eine Aufnahme programmiert. Aufnahme taucht bei beiden auf.

3. 4 Aufnahmen mit gleichem Startzeitpunkt programmiert. Auf beiden Clients wurde 4 Mal der video directory scanner thread gestartet und beendet. Aufnahmen waren bei beiden Clients sichtbar.

Ergebnis: grundsätzlich funktioniert der UPDR Broadcast. Zwei Fehlerfälle könnte ich mir aber vorstellen:

• was passiert, wenn ein video directory scanner thread läuft und dann zusätzlich nochmals ein UPDR per SVDRP getriggert wird (mein Videoverzeichnis ist dazu zu klein, eventuell hat einer hier im Forum etwas mehr Aufnahmen um das mal zu testen)
• was passiert, wenn SVDRP am Client gerade durch (etwas anderes) belegt ist --> vermutlich verpasst dieser Client dann das UPDR. War das der damals beobachtete Fehler?

Auch ohne die Antwort auf die 2 Fehlerfälle spricht doch dennoch nichts gegen die Aufnahme des Broadcast-Befehls, oder? Eventuell müsste man den ersten Fehlerfall noch prüfen und u.U. ein Neueinlesen starten oder den Request schedulen. Neueinlesen starten ist vermutlich die einfachere Umsetzung.

Ich lasse bei mir den Broadcast-Patch mal drin und werde weiter beobachten. Wobei mehr "Stress" als 4 Aufnahmen parallel kann ich mir nicht vorstellen...