VDR version 2.7.5 freigegeben

FireFly · April 15, 2025 at 12:29 PM New

Quote from FireFly

Jedes cRecording-Objekt hat ja auch ein cRecordingInfo-Objekt, sollte man dann nicht einfach immer auf cRecordingInfo::FramesPerSecond() zugreifen anstatt die Variable nochmals mitzuführen?

Das hat leider nichts gebracht - cRecorder und cRecording haben jeweils ein eigenes cRecordingInfo-Objekt und cRecordings soll das Info-File neu einlesen wenn es aktualisiert wurde. Bleibt die Frage warum das (manchmal) nicht funktioniert

kls · April 15, 2025 at 2:03 PM New

Hier mal ein Patch, der das doppelte Speichern von priority, lifetime und framesPerSecond entfernt.

Das ist auf jeden Fall schon mal sinnvoll, denn eine Information, die an zwei Stellen gespeichert ist, wird früher oder später an mindestens einer Stelle falsch sein ;-).

Ob das den eigentlichen Fehler auch behebt, muss sich erst noch zeigen...

FireFly · April 15, 2025 at 5:48 PM New

Da geht Dein Patch weiter als meine Änderungen Ich hatte nur framesPerSecond verlagert, aber bei beiden Varianten tritt das Phänomen noch auf.
Ich habe es jetzt soweit debugged, dass im Fehlerfall zwar die richtigen Werte erzeugt werden, aber das recordingInfo->Write() in cRecorder::Action() später erfolgt als das cRecordingInfo::Read(FILE f) und somit dort nur der Defaultwert 'F 25' drin steht.

cocobrother · April 15, 2025 at 8:04 PM New

Default 25 hmm 🤨

kls · April 15, 2025 at 10:24 PM New

FireFly Der Ablauf ist aber doch

Code

                      recordingInfo->Write(); 
                      LOCK_RECORDINGS_WRITE; 
                      Recordings->UpdateByName(recordingName);

Kann es vielleicht sein, dass st.st_mtime in cRecordingInfo::Read(FILE *f) noch den "alten" Timestamp liefert?

Kannst du mal diesen Patch ausprobieren? (nur compiliert, nicht getestet)

Diff

--- recording.c 2025/04/15 19:38:46     5.40
+++ recording.c 2025/04/15 20:23:11
@@ -497,13 +497,13 @@
   errors = Errors;
 }

-bool cRecordingInfo::Read(FILE *f)
+bool cRecordingInfo::Read(FILE *f, bool Force)
 {
   if (ownEvent) {
      struct stat st;
      if (fstat(fileno(f), &st))
         return false;
-     if (modified == st.st_mtime)
+     if (modified == st.st_mtime && !Force)
         return true;
      if (modified) {
         delete ownEvent;
@@ -614,13 +614,13 @@
   return true;
 }

-bool cRecordingInfo::Read(void)
+bool cRecordingInfo::Read(bool Force)
 {
   bool Result = false;
   if (fileName) {
      FILE *f = fopen(fileName, "r");
      if (f) {
-        if (Read(f))
+        if (Read(f, Force))
            Result = true;
         else
            esyslog("ERROR: EPG data problem in file %s", fileName);
@@ -1281,9 +1281,9 @@
   return cMarks::DeleteMarksFile(this);
 }

-void cRecording::ReadInfo(void)
+void cRecording::ReadInfo(bool Force)
 {
-  info->Read();
+  info->Read(Force);
 }

 bool cRecording::WriteInfo(const char *OtherFileName)
@@ -1729,7 +1729,7 @@
 void cRecordings::UpdateByName(const char *FileName)
 {
   if (cRecording *Recording = GetByName(FileName))
-     Recording->ReadInfo();
+     Recording->ReadInfo(true);
 }

 int cRecordings::TotalFileSizeMB(void) const
--- recording.h 2025/04/15 19:38:46     5.14
+++ recording.h 2025/04/15 20:17:50
@@ -80,7 +80,7 @@
   char *fileName;
   int errors;
   cRecordingInfo(const cChannel *Channel = NULL, const cEvent *Event = NULL);
-  bool Read(FILE *f);
+  bool Read(FILE *f, bool Force = false);
 public:
   cRecordingInfo(const char *FileName);
   ~cRecordingInfo();
@@ -110,7 +110,7 @@
   int Errors(void) const { return errors; } // returns -1 if undefined
   void SetErrors(int Errors);
   bool Write(FILE *f, const char *Prefix = "") const;
-  bool Read(void);
+  bool Read(bool Force = false);
   bool Write(void) const;
   void SetData(const char *Title, const char *ShortText, const char *Description);
   void SetAux(const char *Aux);
@@ -201,7 +201,7 @@
        ///< Deletes the editing marks from this recording (if any).
        ///< Returns true if the operation was successful. If there is no marks file
        ///< for this recording, it also returns true.
-  void ReadInfo(void);
+  void ReadInfo(bool Force = false);
   bool WriteInfo(const char *OtherFileName = NULL);
        ///< Writes in info file of this recording. If OtherFileName is given, the info
        ///< file will be written under that recording file name instead of this

Display More

FireFly · April 16, 2025 at 12:27 AM New

Auf die Schnelle habe ich jetzt einfach mal den Check auskommentiert:

Code

  if (ownEvent) {
     struct stat st;
     if (fstat(fileno(f), &st))
        return false;
     //if (modified == st.st_mtime)
     //   return true;
     if (modified) {

... und konnte das Problem damit nicht mehr nachstellen. Morgen test ich dann Deinen Patch (der dann ja auch funktionieren müsste) und lasse mir auch nochmal die mtime ausgeben

SHofmann · April 16, 2025 at 1:15 PM New

Quote from FireFly

Auf die Schnelle habe ich jetzt einfach mal den Check auskommentiert:

Ich hatte Klaus diesen Check ja vorgeschlagen, weil damit das Neueinlesen einer umfangreichen Filmsammlung per touch .update deutlich schneller geht. Die Metadaten liegen oft noch im Cache des Dateisystems, sodass der Check schnell vonstatten geht, wohingegen das unspezifische Einlesen der Info-Dateien die Platte ganz schön rattern lässt. Insofern würde ich nur ungern auf den Check verzichten, zumal mir solche Effekte mit doppelt langen Zeitangaben schon seit einigen VDR-Versionen nicht mehr aufgefallen sind. Und ich habe diesen Check schon seit Jahren lokal bei mir drin…

Quote from FireFly

Ich habe es jetzt soweit debugged, dass im Fehlerfall zwar die richtigen Werte erzeugt werden, aber das recordingInfo->Write() in cRecorder::Action() später erfolgt als das cRecordingInfo::Read(FILE f) und somit dort nur der Defaultwert 'F 25' drin steht.

Müsste man dann nach einem Write() nicht das Neueinlesen explizit triggern? Ohne dass ich ihm mir en detail angesehen habe, macht der Patch von Klaus vermutlich genau das.

Im Cutter habe ich auch zwei Aufrufe von recordingInfo->Write() gefunden. Müsste man dort nicht auch die Info-Datei neu einlesen?

FireFly · April 16, 2025 at 1:17 PM New

Wenn man sich die Zeit ausgeben lässt

Code

bool cRecordingInfo::Read(FILE *f)
{
  if (ownEvent) {
     struct stat st;
     if (fstat(fileno(f), &st))
        return false;
+     if (modified)
+        isyslog("Read(FILE) mtime: %ld - %ld = %ld", st.st_mtime, modified, st.st_mtime - modified);
     if (modified == st.st_mtime)
        return true;

dann wird es klar warum framesPerSecond nicht aktualisiert wird:

Code

2025-04-16T12:05:42.111518+02:00 vdr vdr: [10640] record /srv/vdr/video0/Tagesschau/2025-04-16.11.54.1-0.rec
2025-04-16T12:05:42.111563+02:00 vdr vdr: [10640] creating directory /srv/vdr/video0/Tagesschau
2025-04-16T12:05:42.111577+02:00 vdr vdr: [10640] creating directory /srv/vdr/video0/Tagesschau/2025-04-16.11.54.1-0.rec
2025-04-16T12:05:42.111603+02:00 vdr vdr: [10640] Write(FILE) F: 25,00
2025-04-16T12:05:42.119876+02:00 vdr vdr: [10640] Read(FILE) F: t='25' 25 -> 25,00
2025-04-16T12:05:42.125132+02:00 vdr vdr: [10640] recording to '/srv/vdr/video0/Tagesschau/2025-04-16.11.54.1-0.rec/00001.ts'
2025-04-16T12:05:42.125415+02:00 vdr vdr: [10640] writing timer id '2@VDR' to /srv/vdr/video0/Tagesschau/2025-04-16.11.54.1-0.rec/.timer
2025-04-16T12:05:42.125494+02:00 vdr vdr: [11112] recording thread started (pid=10640, tid=11112, prio=high)
2025-04-16T12:05:42.127199+02:00 vdr vdr: [10640] Read(FILE) F: t='25' 25 -> 25,00
2025-04-16T12:05:42.225837+02:00 vdr vdr: [11112] H.264: 1280 x 720p 50,00 fps 8 Bit 16:9
2025-04-16T12:05:42.225975+02:00 vdr vdr: [11112] Setting fps 25,00 -> 50,00
2025-04-16T12:05:42.226027+02:00 vdr vdr: [11112] Write(FILE) F: 50,00
2025-04-16T12:05:42.234789+02:00 vdr vdr: [11112] Read(FILE) mtime: 1744797942 - 1744797942 = 0    <<================
2025-04-16T12:05:42.234927+02:00 vdr vdr: [11112] ReadInfo() true 25,00 -> 25,00 Tagesschau
-----------------------------------------------------------------------------------------------
2025-04-16T12:04:57.725226+02:00 vdr vdr: [10640] creating directory /srv/vdr/video0/heute
2025-04-16T12:04:57.725306+02:00 vdr vdr: [10640] creating directory /srv/vdr/video0/heute/2025-04-16.11.54.2-0.rec
2025-04-16T12:04:57.725380+02:00 vdr vdr: [10640] Write(FILE) F: 25,00
2025-04-16T12:04:57.730925+02:00 vdr vdr: [10640] Read(FILE) F: t='25' 25 -> 25,00
2025-04-16T12:04:57.736125+02:00 vdr vdr: [10640] recording to '/srv/vdr/video0/heute/2025-04-16.11.54.2-0.rec/00001.ts'
2025-04-16T12:04:57.736379+02:00 vdr vdr: [10850] recording thread started (pid=10640, tid=10850, prio=high))
2025-04-16T12:04:57.736508+02:00 vdr vdr: [10640] writing timer id '1@VDR' to /srv/vdr/video0/heute/2025-04-16.11.54.2-0.rec/.timer
2025-04-16T12:04:57.737898+02:00 vdr vdr: [10640] Read(FILE) F: t='25' 25 -> 25,00
2025-04-16T12:04:58.350988+02:00 vdr vdr: [10850] H.264: 1280 x 720p 50,00 fps 8 Bit 16:9
2025-04-16T12:04:58.351134+02:00 vdr vdr: [10850] Setting fps 25,00 -> 50,00
2025-04-16T12:04:58.351214+02:00 vdr vdr: [10850] Write(FILE) F: 50,00
2025-04-16T12:04:58.359553+02:00 vdr vdr: [10850] Read(FILE) mtime: 1744797898 - 1744797897 = 1   <<====================
2025-04-16T12:04:58.359646+02:00 vdr vdr: [10850] Read(FILE) F: t='50 1280 720 p 16:9' 50 -> 50,00
2025-04-16T12:04:58.359690+02:00 vdr vdr: [10850] ReadInfo() true 25,00 -> 50,00 heute

Display More

Das time_t modified ist nur sekundengenau, so dass manchmal schon die nächste Sekunde angebrochen ist, aber oft auch nicht und dann die info-Datei nicht neu eingelesen wird.
st_mtime ist lt. man 3type stat nur ein Alias für die Sekunden: #define st_mtime st_mtim.tv_sec, man könnte auf struct timespec st_mtim umstellen, muss dann aber das struct timespec umständlich vergleichen.
Da ist der Patch mit Force die einfachere und sichere Alternative und mein nächster Test.

SHofmann · April 16, 2025 at 1:41 PM New

Ich finde, beides ergänzt sich doch recht gut:

Aufruf per Force, wenn der VDR das nach internen Aktionen für einzelne Dateien benötigt.
Check per st_mtime, wenn alle Aufzeichnungen neu eingelesen werden sollen.

Ich hatte den ersten Fall damals gar nicht auf dem Radarschirm. Danke, dass du das Ganze so detailliert untersucht hat.

FireFly · April 16, 2025 at 1:46 PM New

kls Mit dem Force-Patch funktioniert es wie erwartet:

Code

2025-04-16T13:32:14.325295+02:00 vdr vdr: [15774] record /srv/vdr/video0/ARD-Mittagsmagazin/2025-04-16.12.04.1-0.rec
2025-04-16T13:32:14.325351+02:00 vdr vdr: [15774] creating directory /srv/vdr/video0/ARD-Mittagsmagazin/2025-04-16.12.04.1-0.rec
2025-04-16T13:32:14.325484+02:00 vdr vdr: [15774] Write(FILE) F: 25,00
2025-04-16T13:32:14.332878+02:00 vdr vdr: [15774] Read(FILE) F: t='25' 25 -> 25,00
2025-04-16T13:32:14.340032+02:00 vdr vdr: [15774] recording to '/srv/vdr/video0/ARD-Mittagsmagazin/2025-04-16.12.04.1-0.rec/00001.ts'
2025-04-16T13:32:14.340563+02:00 vdr vdr: [18679] recording thread started (pid=15774, tid=18679, prio=high)
2025-04-16T13:32:14.340610+02:00 vdr vdr: [15774] writing timer id '1@VDR' to /srv/vdr/video0/ARD-Mittagsmagazin/2025-04-16.12.04.1-0.rec/.timer
2025-04-16T13:32:14.342356+02:00 vdr vdr: [15774] Read(FILE) F: t='25' 25 -> 25,00
2025-04-16T13:32:14.949286+02:00 vdr vdr: [18679] H.264: 1280 x 720p 50,00 fps 8 Bit 16:9
2025-04-16T13:32:14.949432+02:00 vdr vdr: [18679] Setting fps 25,00 -> 50,00 0986D0C0
2025-04-16T13:32:14.949508+02:00 vdr vdr: [18679] Write(FILE) F: 50,00
2025-04-16T13:32:14.960026+02:00 vdr vdr: [18679] Read(FILE) mtime: 1744803134 - 1744803134 = 0 forced    <<=============
2025-04-16T13:32:14.960151+02:00 vdr vdr: [18679] Read(FILE) F: t='50 1280 720 p 16:9' 50 -> 50,00  
2025-04-16T13:32:14.960194+02:00 vdr vdr: [18679] ReadInfo() true forced 25,00 -> 50,00 ARD-Mittagsmagazin  <<==============

Display More

Quote from SHofmann

Insofern würde ich nur ungern auf den Check verzichten,

Ich auch, warum sollte man Daten nochmal einlesen, die schon vorhanden sind? Aber das time_t modified ist mit der Auflösung von einer Sekunde zu ungenau, weshalb man das Einlesen in manchen Situation erzwingen muss. Beim Anzeigen der Recording Errors, die auch von cRecorder über die Info-Datei an die Liste der Aufnahmen übergeben werden, sollte die Genauigkeit aber reichen so dass dort kein Force notwendig ist.

Quote from SHofmann

Müsste man dann nach einem Write() nicht das Neueinlesen explizit triggern?

Das wurde ja schon gemacht und auch nur für diese Aufnahme, aber wie gesagt ist der Timestamp der Info-Datei nur Sekunden-genau.

kls · April 16, 2025 at 1:52 PM New

"Sekundengenau" - oh Mann, da hätte ich aber auch draufkommen können! Danke FireFly!

SHofmann · April 16, 2025 at 1:53 PM New

Quote from FireFly

Das wurde ja schon gemacht und auch nur für diese Aufnahme, aber wie gesagt ist der Timestamp der Info-Datei nur Sekunden-genau.

Bleibt noch die Frage nach dem Wiedereinlesen im Cutter…

kamel5 · April 16, 2025 at 2:07 PM New

Quote from FireFly

Beim Anzeigen der Recording Errors, die auch von cRecorder über die Info-Datei an die Liste der Aufnahmen übergeben werden, sollte die Genauigkeit aber reichen so dass dort kein Force notwendig ist.

Ich hatte in letzter Zeit, ich denke so ab Version 2.7.4, relativ oft den Fall, das Recording Errors während und nach einer Aufnahme nicht korrekt im Recordings Menü angezeigt wurden. Das ist mir beim Schneiden einer solchen Aufnahme aufgefallen, erst bei der geschnittenen Aufnahme wurden die Fehler dann korrekt angezeigt. Ich weiß allerdings nicht, ob das den gleichen Zusammenhang hat.

Grüße
kamle5

FireFly · April 16, 2025 at 3:15 PM New

kls Ehrlich gesagt habe ich mich gewundert, dass Infos wie FramesPerSecond indirekt über die info-Datei an die Aufnahmeliste übergeben werden.
Mit Recordings->UpdateByName(recordingName) in cRecorder::Action() erreicht man ja schon die richtige Aufnahme, da könnte man ein cRecordings::UpdateByName(onst char *FileName, const *cRecordingsInfo) draus machen/hinzufügen und die relevanten Infos direkt übernehmen .... (oder nur die u.a. Parameter)

Edit: es gibt nur drei Stellen, wo Recordings->UpdateByName() augerufen wird:

cCuttingThread::HandleErrors(): Setzt Errors
cRecorder::Action(): Setzt fps, Width, Height, ScanType, AspectRatio
cIndexFileGenerator::Action(): Setzt fps, Width, Height, ScanType, AspectRatio und Errors

Die Änderungen würden sich also in Grenzen halten und für das UpdateByName() ist jetzt auch schon ein LOCK_RECORDINGS_WRITE gesetzt

FireFly · April 16, 2025 at 4:22 PM New

Quote from kamel5

das Recording Errors während und nach einer Aufnahme nicht korrekt im Recordings Menü angezeigt wurden

Das müsste mit dem obigen Patch von kls auch korrigiert sein da die Fehler in cCuttingThread::HandleErrors() mit dem gleichen Mechainismus übertragen werden.

kamel5 · April 16, 2025 at 4:45 PM New

Quote from FireFly

Das müsste mit dem obigen Patch von kls auch korrigiert sein

OK, ich habe den Patch jetzt eingespielt und werde das mal eine Weile beobachten.

Grüße
kamel5

kls · April 16, 2025 at 4:57 PM New

Quote from FireFly

Ehrlich gesagt habe ich mich gewundert, dass Infos wie FramesPerSecond indirekt über die info-Datei an die Aufnahmeliste übergeben werden.

Da hast du natürlich grundsätzlich recht. Aber ausser priority, lifetime und framesPerSecond geht es ja auch noch um die ganzen Frame-Parameter (in cRecorder::Action()). Um alle erdenklichen (und evtl. künftigen) Fälle abzudecken müsste man also die Info komplett kopieren - da erscheint es mir einfacher, die Datei neu einzulesen.

MarkusE · April 17, 2025 at 7:13 PM New

Quote from wakko

MarkusE
Kannst du bitte schaun wegen dynamite?
Ich bekomme mit 2.7.5 rejects

Im dynamite git ist vdr-2.7.5-dynamite.patch

seahawk1986 · April 18, 2025 at 11:09 AM New

Ich habe mal Pakete für Ubuntu 20.04, 22.04 und 24.04 bauen lassen: https://launchpad.net/~seahawk1986-h…buntu/vdr-2.7.5

FireFly · April 18, 2025 at 2:48 PM New

Mir ist da nochwas in der Aufnahmeliste augefallen:
Wenn man eine Aufnahme schneidet wird normalerweise während des Schneidens die Dauer der geschnittenen Aufnahme hochgezählt. Ändert man danach die Schnittmarken und scheidet die gleiche Aufnahme nochmals, dann wird nicht nur die Dauer nicht mehr hochgezählt sondern auch nach dem Ende des Schneidens wird weiterhin die Dauer der Aufnahme nach dem ersten Schneiden angezeigt. (Vermutlich betrifft das auch die Anzahl der Fehler in der Aufnahme). Erst nach einem Restart des VDR wird die richtige Dauer der geschnittenen Aufnahme wieder angezeigt.

Ursache ist, dass die erste geschnittene Aufnahme in der Aufnahmeliste nicht gelöscht wird sondern beim Schneiden nur ein Eintrag hinzugefügt wird (falls er noch nicht existiert). In cCutter::Start() werden zwar die Videodateien des ersten Schneidens gelöscht aber die Aufnahme nicht aus der Aufnahmeliste entfernt. Der folgende Patch löscht die Aufnahme in der Liste bevor die neue hinzugefügt wird:

Diff

--- vdr-2.7.5/recording.c       2025-04-16 13:49:13.520577063 +0200
+++ vdr-2.7.5-devel/recording.c 2025-04-18 12:53:29.645557856 +0200
@@ -2056,6 +2066,7 @@
      if ((Usage() & ruCut) != 0) {
         cutter = new cCutter(FileNameSrc());
         cutter->Start();
+        Recordings->DelByName(FileNameDst());
         Recordings->AddByName(FileNameDst(), false);
         }
      else if ((Usage() & (ruMove | ruCopy)) != 0) {

kls Gibt es eine bessere/elegantere Möglichkeit für das Del/Add oder kannst Du das so übernehmen?

VDR version 2.7.5 freigegeben

Participate now!

Similar Threads

25 Jahre VDR

Users Viewing This Thread