VDR 2.7.8: "Deleted recordings" im Hauptmenü

SHF · February 2, 2026 at 1:28 AM

Eigentlich wollte ich die Frage schon ganz am Anfang stellen...

Wäre es nicht einfacher und weniger fehleranfällig Recording->Delete() usw. so zu ändern, dass es wie früher funktioniert? Also alles macht, um eine Aufzeichnung korrekt zu löschen. (Die Aufzeichnung umbenennt, aus dem Menü löscht, (neu) bei den deletet recordings einträgt, bzw. daraus entfernt falls endgültig gelöscht, ...)
Eventuell mit einem zusätzlichen, optionalen Parameter, falls irgendwo das aktuelle Verhalten notwendig ist.

Die Beschreibung im Header pass aktuell auch nicht mehr.
Changes the file name so that it will no longer be visible in the "Recordings" menu

Das Löschen von Aufzeichnungen ist jetzt echt kompliziert geworden. Ich habe mir das jetzt über eine Stunde angeschaut und überblicke noch immer nicht alles....

SHofmann · February 2, 2026 at 10:43 AM

Quote from SHF

Das Menü zeigt nur "Kürzlich Gelöschte Aufzeichnungen" an, nicht alle gelöschten Aufzeichnungen. Darauf wollte ich hinaus.

Das stimmt so nicht. Im VDR gibt es nur aktive und gelöschte (als gelöscht markierte) Aufzeichnungen. Bei letzteren wird keineswegs zwischen kürzlich und schon vor längerem gelöschten Aufzeichnungen differenziert. Und in diesem Menü kann man die als gelöscht markierten Aufzeichnungen manuell endgültig löschen (also tatsächlich von der Festplatte löschen), wenn man nicht warten möchte, bis die Verwahrdauer abgelaufen ist und sie zeitgesteuert entsorgt werden.

FireFly · February 2, 2026 at 12:19 PM

Quote from kls

Das hier sollte das fixen:

Danke, funktioniert

kls · February 2, 2026 at 3:45 PM

Quote from SHF

Wäre es nicht einfacher und weniger fehleranfällig Recording->Delete() usw. so zu ändern, dass es wie früher funktioniert? Also alles macht, um eine Aufzeichnung korrekt zu löschen. (Die Aufzeichnung umbenennt, aus dem Menü löscht, (neu) bei den deletet recordings einträgt, bzw. daraus entfernt falls endgültig gelöscht, ...)

cRecording::Delete() kann sich nicht selber aus Recordings bzw. DeletedRecordings löschen bzw. dort eintragen, da es keinen Zugriff auf diese Listen hat. Auch aus dem Menü kann es sich nicht selber löschen, weil es auch darauf keinen Zugriff hat. Ein cRecording ist ja nicht einmal selber in einem Menü, sondern ein cMenuRecordingItem hat einen Pointer auf das cRecording.

Quote from SHF

Die Beschreibung im Header pass aktuell auch nicht mehr.

Das mit "...so that it will no longer be visible in the "Recordings" menu" hat eigentlich so direkt noch nie gestimmt, denn mit dem Aufruf von Delete() allein war es auch bisher nicht getan. Der Aufrufer musste es auch selber aus der Liste der Recordings (und ggf. das zugehörige cMenuRecordingItem aus dem Menü) entfernen.

Und "Changes the file name..." hat eigentlich auch nur halb gestimmt, denn es wurde zwar der Dateiname auf der Platte geändert, aber nicht der cRecording::fileName im Objekt. Deshalb hat der Undelete-Patch ja auch

Code

+#define RECEXT       ".rec" 
+#define DELEXT       ".del"

dupliziert, was mir nicht gefallen hat.
Ich werde die Beschreibung so ändern:

Code

  bool Delete(void);
       ///< Changes the file name (both internally and on disk) to make this a "deleted" recording.
       ///< The caller must explicitly move this object from the Recordings to the
       ///< DeletedRecordings list.
       ///< Returns false in case of error.
  bool Remove(void);
       ///< Actually removes the file from the disk.
       ///< The caller must explicitly delete this object from the DeletedRecordings list.
       ///< Returns false in case of error.
  bool Undelete(void);
       ///< Changes the file name (both internally and on disk) to make this a "normal" recording.
       ///< The caller must explicitly move this object from the DeletedRecordings to the
       ///< Recordings list.
       ///< Returns false in case of error.

Display More

SHF · February 3, 2026 at 1:08 AM

Zunächst der Hintergrund, warum ich die Frage erst jetzt gestellt habe:
Bislang ging ich von einem reinen Darstellungsproblem im Menü aus, wenn man darin eine Aufzeichnung gelöscht hat. Nach dem letzten Patch bin ich da nicht mehr so sicher.

Inzwischen sind mir auch immer mehr Plugins und Erweiterungen eingefallen, die irgendwie mit den Recordings zu tun haben, sei es über die Recordings Liste oder über SVDRP.
zB. vnsi, epgsearch, vdr-admin
Nicht alle haben dabei so etwas wie Aufzeichnungs-Menü.

Da frage ich mich jetzt, ob man die jetzt auch alle anpassen muss?
epgsearch beispielsweise vergleicht erledigte Aufzeichnungen und löscht ggf. sogar Aufzeichnungen, wenn diese Funktion aktiviert ist (die Recordings werden dafür natürlich entsprechend gelockt). Wenn da was bei den Aufzeichnungen durcheinander gerät merkt man das also nur indirekt und das kann dauern.

Bei allem über SVDRP sollte doch der VDR alles nötige erledigen?
Bei vdr-admin (kommuniziert nur über SVDRP mit dem VDR) sollte also alle in Ordnung sein?

Quote from kls

Das mit "...so that it will no longer be visible in the "Recordings" menu" hat eigentlich so direkt noch nie gestimmt, denn mit dem Aufruf von Delete() allein war es auch bisher nicht getan. Der Aufrufer musste es auch selber aus der Liste der Recordings (und ggf. das zugehörige cMenuRecordingItem aus dem Menü) entfernen.

Das erklärt einiges.
Ich ging davon aus, dass Liste der Recordings irgendwie aktuell gehalten wurde.
(Wie das Menü aktuell gehalten wird hatte ich bislang noch nicht angesehen, die Liste ist mein primäres Interesse.)

Die Frage ist dann also, ob das was ein Plugin zur Zeit macht um die Liste(n) aktuell zu halten, auch in Zukunft reicht.
Kann man da was pauschal sagen oder ausschließen, oder muss man jedes Plugin einzeln ansehen?

kls · February 3, 2026 at 10:28 AM

Du hast Recht, da liegt noch so einiges im Argen, sowohl in VDR selber als auch für Plugins.

Ich arbeite gerade an einem Fix, der keine Änderungen in Plugins erfordern sollte.
Mehr dazu später.

TomJoad · February 3, 2026 at 11:33 AM

Man sollte auch die SVDRP-Schnittstelle nicht vergessen, halb-gelöschte Aufnahmen anzeigen, forced Löschen, ...?

kls · February 3, 2026 at 11:42 AM

TomJoad Ja, wird alles berücksichtigt.

kls · February 3, 2026 at 1:24 PM

Das Problem waren Sequenzen wie diese:

Code

if (Recording->Delete()) {
   Recordings->DelByName(Recording->FileName());

Wegen der Änderung in cRecording::Delete(), dass der interne FileName jetzt auch von "*.rec" nach "*.del" geändert wird, konnte DelByName() das Recording nicht mehr finden und löschte es damit nicht aus Recordings.

Dieser Patch sollte das fixen:

Diff

--- recording.c 2026/02/02 15:01:50     5.49
+++ recording.c 2026/02/03 11:09:54
@@ -1741,10 +1741,23 @@

 void cRecordings::DelByName(const char *FileName)
 {
-  cRecording *Recording = GetByName(FileName);
+  if (this != &recordings) {
+     esyslog("ERROR: cRecordings::DelByName() called with '%s' on a list other than Recordings - ignored", FileName);
+     return;
+     }
+  char *DelRecFileName = strdup(FileName);
+  if (char *ext = strrchr(DelRecFileName, '.')) {
+     if (strcmp(ext, DELEXT)) {
+        esyslog("ERROR: cRecordings::DelByName() called with '%s', using '.rec' instead", DelRecFileName);
+        strncpy(ext, RECEXT, strlen(ext));
+        }
+     }
   cRecording *dummy = NULL;
-  if (!Recording)
+  cRecording *Recording = GetByName(DelRecFileName);
+  if (!Recording) {
+     esyslog("ERROR: cRecordings::DelByName(): '%s' not found in Recordings - using dummy", DelRecFileName);
      Recording = dummy = new cRecording(FileName); // allows us to use a FileName that is not in the Recordings list
+     }
   LOCK_DELETEDRECORDINGS_WRITE;
   if (!dummy)
      Del(Recording, false);
@@ -1758,6 +1771,7 @@
         }
      }
   delete Recording;
+  free(DelRecFileName);
   TouchUpdate();
 }

Display More

Erklärung:
- Zunächst wird geprüft, ob es sich auch wirklich um die Recordings Liste handelt. Das sollte zwar immer der Fall gewesen sein, aber sicher ist sicher.
- Dann wird die Extension von ".del" nach ".rec" geändert, falls nötig.
- Danach wird verfahren wie bisher, wobei der Fall, dass es in Recordings keinen Eintrag mit FileName gibt, als Fehler ins Log geschrieben wird, denn das sollte an der Aufrufstelle geändert werden.

Hiermit sollte sowohl VDR als auch Plugins, die solche Sequenzen verwenden, wieder funktionieren.

In VDR selber werde ich DelByName() nicht mehr verwenden, sondern es so machen:

Diff

--- menu.c      2026/02/02 15:10:28     5.41
+++ menu.c      2026/02/03 11:40:56
@@ -5972,7 +5972,9 @@
                 Recordings->SetExplicitModify();
                 if (cRecording *Recording = Recordings->GetByName(fileName)) {
                    if (Recording->Delete()) {
-                      Recordings->DelByName(fileName);
+                      LOCK_DELETEDRECORDINGS_WRITE;
+                      Recordings->Del(Recording, false);
+                      DeletedRecordings->Add(Recording);
                       ClearLastReplayed(fileName);
                       Recordings->SetModified();
                       }
--- recording.c 2026/02/03 11:25:29     5.50
+++ recording.c 2026/02/03 11:40:56
@@ -2123,13 +2123,15 @@
      return true;
      }
   // We're done:
-  if (!error && (usage & (ruMove | ruCopy)) != 0)
-     cRecordingUserCommand::InvokeCommand(RUC_COPIEDRECORDING, FileNameDst(), FileNameSrc());
-  if (!error && (usage & ruMove) != 0) {
-     cRecording Recording(FileNameSrc());
-     if (Recording.Delete()) {
-        cRecordingUserCommand::InvokeCommand(RUC_MOVEDRECORDING, FileNameDst(), FileNameSrc());
-        Recordings->DelByName(Recording.FileName());
+  if (!error) {
+     if ((usage & (ruMove | ruCopy)) != 0)
+        cRecordingUserCommand::InvokeCommand(RUC_COPIEDRECORDING, FileNameDst(), FileNameSrc());
+     if ((usage & ruMove) != 0) {
+        if (cVideoDirectory::RemoveVideoFile(FileNameSrc())) {
+           cRecordingUserCommand::InvokeCommand(RUC_MOVEDRECORDING, FileNameDst(), FileNameSrc());
+           if (cRecording *Recording = Recordings->GetByName(FileNameSrc()))
+              Recordings->Del(Recording); // just to be sure
+           }
         }
      }
   Recordings->SetModified(); // to trigger a state change
@@ -2146,10 +2148,11 @@
            delete cutter;
            cutter = NULL;
            }
-        if (cRecording *Recording = Recordings->GetByName(fileNameDst))
+        if (cRecording *Recording = Recordings->GetByName(fileNameDst)) {
            cVideoDirectory::RemoveVideoFile(Recording->FileName());
-        Recordings->DelByName(fileNameDst);
-        Recordings->SetModified();
+           Recordings->Del(Recording);
+           Recordings->SetModified();
+           }
         }
      }
   if ((usage & (ruMove | ruCopy)) // this was a move/copy operation...
@@ -2160,11 +2163,12 @@
         delete copier;
         copier = NULL;
         }
-     if (cRecording *Recording = Recordings->GetByName(fileNameDst))
+     if (cRecording *Recording = Recordings->GetByName(fileNameDst)) {
         cVideoDirectory::RemoveVideoFile(Recording->FileName());
+        Recordings->Del(Recording);
+        }
      if ((usage & ruMove) != 0)
         Recordings->AddByName(fileNameSrc);
-     Recordings->DelByName(fileNameDst);
      Recordings->SetModified();
      }
 }
--- recording.h 2026/02/02 14:48:04     5.20
+++ recording.h 2026/02/03 11:40:56
@@ -295,7 +295,7 @@
   cRecording *GetByName(const char *FileName) { return const_cast<cRecording *>(static_cast<const cRecordings *>(this)->GetByName(FileName)); }
   void Add(cRecording *Recording);
   void AddByName(const char *FileName, bool TriggerUpdate = true);
-  void DelByName(const char *FileName);
+  [[deprecated("use explicit locking, deleting etc.")]] void DelByName(const char *FileName);
   void UpdateByName(const char *FileName);
   int TotalFileSizeMB(void) const;
   double MBperMinute(void) const;
--- svdrp.c     2026/01/23 10:35:23     5.16
+++ svdrp.c     2026/02/03 11:40:56
@@ -1520,7 +1520,9 @@
               Reply(550, "%s", *RecordingInUseMessage(RecordingInUse, Option, Recording));
            else {
               if (Recording->Delete()) {
-                 Recordings->DelByName(Recording->FileName());
+                 LOCK_DELETEDRECORDINGS_WRITE;
+                 Recordings->Del(Recording, false);
+                 DeletedRecordings->Add(Recording);
                  Recordings->SetModified();
                  isyslog("SVDRP %s < %s deleted recording %s", Setup.SVDRPHostName, *clientName, Option);
                  Reply(250, "Recording \"%s\" deleted", Option);

Display More

cRecordings::DelByName() sollte man nicht mehr verwenden, daher [[deprecated]], um die Aufrufstellen anzumeckern.

SHofmann · February 3, 2026 at 1:39 PM

Quote from SHF

Die Frage ist dann also, ob das was ein Plugin zur Zeit macht um die Liste(n) aktuell zu halten, auch in Zukunft reicht.

EPGsearch macht derzeit folgendes:

Code

        cRecording *Recording = Recordings->GetByName(FileName);
        if (!Recording || Recording->Delete()) {
           cReplayControl::ClearLastReplayed(FileName);
#if APIVERSNUM >= 30010
           Recordings->Del(Recording, false);
           DeletedRecordings->Add(Recording);
#else
           Recordings->DelByName(FileName);
#endif

Das sollte nach meinem Kenntnisstand eigentlich korrekt sein.

kls · February 3, 2026 at 3:31 PM

Sieht gut aus.

MarkusE · February 3, 2026 at 4:02 PM

Und wenn es einen Timer gibt, der die Aufnahme gerade aufzeichnet, sollte man den Timer vorher auf inaktiv setzen oder löschen
Und wenn die Aufnahme gerade wiedergegeben wird, vorher die Wiedergabe stoppen
Und wenn die Aufnahme gerade geschnitten wird (Quelle), dann warten, bis das Schneiden fertig ist. Und dann löschen. Alternative: Fehler zurückgeben und nicht löschen. Dann kann der Aufrufer etwas in den Hintergrund schieben.
Und wenn die Aufnahme gerade geschnitten wird (Ziel), dann das Schneiden abbrechen und dann löschen.
Beim Kopieren analog verfahren wie beim Schneiden
Beim Verschieben / Umbenennen: warten, bis das Verschieben / Umbenennen fertig ist. Und dann löschen
... habe ich noch was vergessen?

Wäre natürlich super, wenn VDR eine API für Plugins anbieten würde, die das alles macht. Und dabei nicht nur die eigenen Aktionen berücksichtigt, sondern auch die Aktionen anderer VDR Instanzen, die auf die gleichen Videos zugreifen. Diese API könnte dann auch gleich von SVDRP verwendet werden.

Und dann noch eine andere API die prüft, ob eines der oben genannten "Probleme" vorliegt und dann eine Liste dieser Probleme zurückgibt. Dann kann das Plugin erst diese API aufrufen und bei Bedarf erst noch mal den Anwender fragen.

OK, das ist jetzt vermutlich zu umfangreich. Aber bereits ein Teil der hier genannten Features würde helfen.

Dann noch eine API für "endgültig löschen" und eine für "wiederherstellen" ... Träum... Ist nicht bald Weihnachten?

kls · February 3, 2026 at 4:16 PM

Quote from MarkusE

Ist nicht bald Weihnachten?

Nein, war erst ;-).

SHF · February 4, 2026 at 12:59 AM

Quote from kls

Wegen der Änderung in cRecording::Delete(), dass der interne FileName jetzt auch von "*.rec" nach "*.del" geändert wird, konnte DelByName() das Recording nicht mehr finden und löschte es damit nicht aus Recordings.

Dann war das ByName das Problem, immer diese Details ...

Quote from kls

cRecordings::DelByName() sollte man nicht mehr verwenden, daher [[deprecated]], um die Aufrufstellen anzumeckern.

Das das oft eigentlich unnötig verwendet wurde, war mir auch schon aufgefallen. Besonders beliebt scheint Konstrukt: Recordings->DelByName(Recording->FileName());
Da wäre doch schon immer Recordings->Del(Recording); sinnvoller gewesen?

Als Kochrezept für so einen Fall würde ich jetzt so verfahren:

Diff

--- file.c.old 
+++ file.c
@@ -123,1 +123,7 @@
-                 Recordings->DelByName(Recording->FileName());
+                 Recordings->Del(Recording, false);
+ #if APIVERSNUM >= 30010
+                 {
+                    LOCK_DELETEDRECORDINGS_WRITE;
+                    DeletedRecordings->Add(Recording);
+                 }
+ #endif

Display More

Einwände?

Quote from MarkusE

OK, das ist jetzt vermutlich zu umfangreich. Aber bereits ein Teil der hier genannten Features würde helfen.

Es würde eigentlich schon reichen, wenn man sicher wüsste, ob schon irgendwer lesend/schreibend auf eine Aufzeichnung zugreift.
Da das auch externe Scripte sein können, ist schon das nicht so einfach.
Die aktuellen Ansätze über lsof fuser oder atime haben alle so ihre Tücken.

kls · February 4, 2026 at 7:37 AM

Quote from SHF

Als Kochrezept für so einen Fall würde ich jetzt so verfahren

Würde ich nicht empfehlen, denn DelByName() ist [[deprecated]] und sollte gar nicht mehr verwendet werden. Mach es lieber so wie in #30.

SHF · February 5, 2026 at 12:03 AM

Das sollte ein .diff sein, da ist aber was bei der Darstellung schief gegangen. Ist jetzt korrigiert.

Funktionell sollte das #30 entsprechen, nur habe ich das DelByName() ganz raus geschmissen.
Recordings->Del() konnte man doch immer schon verwenden?

Bei dem LOCK_DELETEDRECORDINGS_WRITE müsste man dann ggf. schauen, ob das an der Stelle passt.
Aber nötig ist der Block in der Klammer {} jetzt nach jedem Recordings->Del() , wenn ich das richtig verstanden habe.

Das ist jetzt primär mal als Merkzettel gedacht gewesen, auf was man da jetzt achten muss.

kls · February 5, 2026 at 10:34 AM

Wenn du möchtest, dass es auch mit älteren Versionen funktioniert, dann solltest du das eher so machen:

Code

#if APIVERSNUM >= 30011
                Recordings->Del(Recording, false);
                LOCK_DELETEDRECORDINGS_WRITE;
                DeletedRecordings->Add(Recording);
#else
                Recordings->DelByName(Recording->FileName());
#endif

Beachte APIVERSNUM >= 30011!

SHofmann · February 5, 2026 at 12:18 PM

Dummer Frage: Müsste da nicht auch noch ein Recordings->SetModified() rein, und warum braucht man dies nicht für DeletedRecordings?

TomJoad · February 5, 2026 at 12:57 PM

Modified ist automatisch beim Writelock gesetzt, ausser man ruft direkt SetExplicitModify() auf, dann wird die Statusänderung nur nach SetModified() durchgeführt. Das macht man immer dann, wenn man sich einen WRITE-Lock holt, aber noch nicht weiss, ob man wirklich was ändert.

SHF · February 5, 2026 at 9:30 PM

Quote from kls

Wenn du möchtest, dass es auch mit älteren Versionen funktioniert, dann solltest du das eher so machen:

Danke!
Wäre ja blöde, wenn man es korrigiert und es dann trotzdem nicht funktioniert .

Quote from kls

Beachte APIVERSNUM >= 30011!

Sicher?
Im git steht aktuell noch #define APIVERSNUM 30010, ich dachte, die müsste ich einschließen?

VDR 2.7.8: "Deleted recordings" im Hauptmenü

Participate now!

Users Viewing This Thread