VDR version 2.7.9 freigegeben

FireFly · February 15, 2026 at 11:22 AM

Noch ein Kuriosum:
Ich habe eine 1080i Aufnahme gemacht und da steht im info-File: O 51 51 also wirklich 2x "51"
Wenn man sie abspielt wird aber im Fortschrittsbalken kein einziger Fehler angezeigt. Es handelt sich um eine Originalaufnahme, also ungeschnitten.

kls · February 15, 2026 at 11:27 AM

man vdr.5:

Code

O <errors> [ <tmperrors> ]
...
If the video data stream was broken while recording, tmperrors contains 
the estimated number of missed frames. If the recording was later continued, 
errors will contain the exact number of missing frames, and tmperrors will 
be removed.

blau · February 15, 2026 at 11:27 AM

Quote from FireFly

da steht im info-File: O 51 51 also wirklich 2x "51"

Ja, so etwas hatte ich auch schon. Allerdings mit anderen Werten. Das hatte ich noch nicht erwähnt.

Hast du das PlugIn "markad" in Einsatz?

FireFly · February 15, 2026 at 11:43 AM

Quote from kls

man vdr.5:

Oh, Danke, wieder was gelernt, das kam mit Version 2.7.8

Aber wo sind dann die Fehler? Im Fortschrittsbalken werden sie ja nicht angezeigt, da sieht die Aufnahme komplett fehlerfrei aus. Auch mit Channel+/- kann man keine Fehler anspringen....

FireFly · February 15, 2026 at 11:46 AM

Quote from blau

Hast du das PlugIn "markad" in Einsatz?

Habe mich gerade nochmal rückversichert: Markad verändert die Info-Datei nicht

kls · February 15, 2026 at 11:58 AM

Wenn während der Aufnahme der Datenstrom abbricht, dann wird die Zahl der fehlenden Frames geschätzt (Anzahl der Sekunden der Unterbrechung mal FPS) und als <tmperrors> in die info-Datei geschrieben. <errors> ist (aus Gründen der Rückwärtskompatibilität) die Gesamtzahl der Fehler und beinhaltet auch <tmperrors>. Wird die Aufnahme in diesem Zustand abgebrochen, bleibt in deinem Fall O 51 51 stehen. Die Frames fehlen aber am Ende der Aufnahme und sind somit nicht wirklich fehlerhaft. Die auf der Platte gespeicherte Aufnahme beinhaltet also keine wirklichen Fehler, die zum Benutzer angezeigte Fehleranzahl ist als <errors> - <tmperrors>, also 0. Wäre die Aufnahme erneut gestartet worden, wäre die Zahl der fehlenden Frames genau berechnet worden (und vermutlich etwas höher als 51 gewesen) und am Schluss wäre diese Zahl (alleine) in <errors> gestanden.

FireFly · February 15, 2026 at 1:17 PM

Danke für die Erklärung, aber in meinem Fall wurde der Timer regulär vom VDR gestoppt, da die Zeit abgelaufen war. VDR lief danach noch einige Minuten. Markad wurde zwar benutzt, liest die info-Datei aber nur am Anfang und schließt sie dann wieder.

Quote from kls

die zum Benutzer angezeigte Fehleranzahl ist als <errors> - <tmperrors>, also 0

Im Aufnahmemenü wird sie allerdings als fehlerhaft angezeigt, auch mit Skin "Klassischer VDR". Müsste das Skin das ausrechnen?

kls · February 15, 2026 at 1:21 PM

Kannst du bitte mal alle Log-Meldungen im Zusammenhang mit dieser Aufnahme posten?

MarkusE · February 15, 2026 at 5:38 PM

Quote from kls

Wenn während der Aufnahme der Datenstrom abbricht, dann wird die Zahl der fehlenden Frames geschätzt (Anzahl der Sekunden der Unterbrechung mal FPS) und als <tmperrors> in die info-Datei geschrieben. <errors> ist (aus Gründen der Rückwärtskompatibilität) die Gesamtzahl der Fehler und beinhaltet auch <tmperrors>. Wird die Aufnahme in diesem Zustand abgebrochen, bleibt in deinem Fall O 51 51 stehen. Die Frames fehlen aber am Ende der Aufnahme und sind somit nicht wirklich fehlerhaft. Die auf der Platte gespeicherte Aufnahme beinhaltet also keine wirklichen Fehler, die zum Benutzer angezeigte Fehleranzahl ist als <errors> - <tmperrors>, also 0. Wäre die Aufnahme erneut gestartet worden, wäre die Zahl der fehlenden Frames genau berechnet worden (und vermutlich etwas höher als 51 gewesen) und am Schluss wäre diese Zahl (alleine) in <errors> gestanden.

Ich finde es super, dass VDR auch prüft, ob der Datenstrom abbricht und dann fehlende Frames abschätzt.

Wenn ich jetzt wissen will, ob meine Aufnahme fehlerhaft ist, möchte ich natürlich auch wissen, ob sie vollständig ist. Wäre es von daher nicht besser <errors> und nicht <errors> - <tmperrors> anzuzeigen? Bei letzterem verliere ich ja die Information, dass Frames am Ende fehlen.

Wenn ich das jetzt weiter denke: Optimal wäre es, eine Zeit (oder Anzahl von Frames) zu haben, die in der Aufnahme fehlen. Warum die fehlen, ist fast schon weniger relevant. Mögliche Gründe:

andere Aufnahmen mit höherer Prio
Reboot des VDR während der Aufnahme
VDSB
VDR wurde zu spät hochgefahren
...

FireFly · February 15, 2026 at 6:00 PM

Quote from kls

Kannst du bitte mal alle Log-Meldungen im Zusammenhang mit dieser Aufnahme posten?

Ich hab's dir per PN geschickt

kls · February 15, 2026 at 9:23 PM

Da die "Fehler" ganz am Schluss auftreten

Code

2026-02-14T04:15:00.847855+01:00 uhdvdr vdr: [3417] /srv/vdr/video0/Halbpension_mit_Schmitz/2026-02-14.03.06.20-0.rec: 51 new errors (total 51) 
2026-02-14T04:15:00.853727+01:00 uhdvdr vdr: [3417] recording thread ended (pid=1563, tid=3417) 
2026-02-14T04:15:00.856208+01:00 uhdvdr vdr: [1563] timer 297 (20 0306-0415 'Halbpension mit Schmitz') finished with 51 errors

und mit 51 (bei 25fps) ziemlich genau 2 Sekunden Video entsprechen, schließe ich auf ein Timing-Problem beim Beenden von cRecorder::Action(). Ich hatte damals eine "Karenzzeit" von 2 Sekunden (LEFTOVERTIMEOUT) eingebaut, was bei mir immer ausgereicht hat, bei dir aber anscheinend gerade so überschritten wurde. Aber wenn ich es mir recht überlege braucht es das gar nicht, denn ich weiß ja am Schluss, ob die Schleife ordentlich beendet wurde.
Daher sollte das hier das Problem beheben:

Diff

--- recorder.c  2025/12/29 14:14:05     5.13
+++ recorder.c  2026/02/15 20:20:23
@@ -15,7 +15,6 @@
 // The maximum time we wait before assuming that a recorded video data stream
 // is broken:
 #define MAXBROKENTIMEOUT 30000 // milliseconds
-#define LEFTOVERTIMEOUT   2000 // milliseconds

 #define MINFREEDISKSPACE    (512) // MB
 #define DISKCHECKINTERVAL   100 // seconds
@@ -334,9 +333,11 @@
         }
   // Estimate the number of missing frames in case the data stream was broken, but the timer
   // didn't reach the timeout, yet:
-  int dt = t.Elapsed();
-  if (dt > LEFTOVERTIMEOUT)
-     tmpErrors += int(round(frameDetector->FramesPerSecond() * dt / 1000));
+  if (working) {
+     int dt = t.Elapsed();
+     if (dt > 0)
+        tmpErrors += int(round(frameDetector->FramesPerSecond() * dt / 1000));
+     }
   if (pendNumber > 0) {
      bool PreviousErrors = false;
      errors = frameDetector->Errors(&PreviousErrors);

Display More

kls · February 15, 2026 at 9:55 PM

Quote from MarkusE

Wenn ich jetzt wissen will, ob meine Aufnahme fehlerhaft ist, möchte ich natürlich auch wissen, ob sie vollständig ist. Wäre es von daher nicht besser <errors> und nicht <errors> - <tmperrors> anzuzeigen? Bei letzterem verliere ich ja die Information, dass Frames am Ende fehlen.

Ich hab das gerade nochmal nachgestellt: zum Benutzer hin wird immer <errors> angezeigt. <tmperrors> dient nur dazu, nach einer Fortsetzung der Aufnahme nach einer Unterbrechung die bis dahin geschätzte Anzahl der Fehler (<tmperrors>) von <errors> abziehen zu können, um dann die genaue Anzahl anhand der neu hinzukommenden PTS-Werte ermitteln zu können. Das Ganze entstand aus der Forderung, dass die Anzahl der gemeldeten Fehler möglichst auch nach einem Schnitt uder Index-Neugenerieren konsistent sein soll.

Das konkrete Problem von FireFly sollte mit dem Patch aus #52 nicht mehr auftreten.

FireFly · February 16, 2026 at 11:42 AM

Quote from kls

Daher sollte das hier das Problem beheben:

Danke für die schnelle Korrektur. Ich habs eingebaut und werde es beobachten

wmautner · February 18, 2026 at 3:40 PM

Seit kurzem fällt mir (siehe .sig) auf, daß im OSD oft nach dem Starten die now/next-Info EINES Kanals angezeigt wird, aber Bild & Ton (+Logo) einen anderen Sender zeigen.

Das tritt sowohl bei Skinflatplus als auch bei LCARS auf. Wähle ich einen anderen Sender mit vdradmin-am aus der "Fernsseher"-Ansicht rechts, wechselt der Kanal, nicht aber die OSD-Anzeige. Erst ein Druck auf "OK" bringt das passende OSD now/next.

Bei live-ng gibt es die Kanal-Liste rechts nicht im "Fernbedienung"-Menü.

The content cannot be displayed because you do not have authorisation to view this content.

SHF · February 20, 2026 at 1:29 AM

Ich habe da jetzt etwas die Übersicht verloren:
Ist der "Pixelsalat" an den Schnittstellen auch beseitigt, oder ist das ein anderes Problem?

FireFly · February 22, 2026 at 7:17 PM

Quote from kls

Daher sollte das hier das Problem beheben:

Mit dem Patch läuft es bisher problemlos, erwartungsgemäß keine Fehler mehr am Ende.

Kannst Du nochmal nach dem Problem aus #40 schauen oder hast Du das noch auf dem Schirm?
Version 2.7.9 erzeugt beim erneuten Erstellen des Index einer H.265 Aufnahme nur noch 1 anstatt 4 Fehler obwohl die Fehler in der Aufnahme sichtbar sind (mitten im Film, nicht an den Schnittstellen, waren schon im Original). Bei Bedarf kann ich auch die VDR Versionen raussuchen, mit denen Aufnahme und Schnitt gemacht wurden.

kls · February 22, 2026 at 8:23 PM

Ich hatte so eine Aufnahme hier, konnte aber an den Störstellen keinen Fehler erkennen, den VDR mit seinen vorhandenen Mitteln hätte detektieren können. Entweder war die Störung bereits im übertragenen Material, oder VDRs Fehlererkennung ist nicht darauf angesprungen.

FireFly · February 23, 2026 at 11:46 AM

Quote from kls

Ich hatte so eine Aufnahme hier, konnte aber an den Störstellen keinen Fehler erkennen, den VDR mit seinen vorhandenen Mitteln hätte detektieren können

Beim Durchsuchen der Logs habe ich die Ursache wohl beim Schnitt dieser UHD-Aufnahme gefunden:

Code

vdr: [14036] ERROR: frame larger than buffer (1053740 > 1048476) 
vdr: [14036] ERROR: frame larger than buffer (1202448 > 1048476) 
vdr: [14036] ERROR: frame larger than buffer (1202636 > 1048476)

Die Anzahl passt (drei Fehler gingen beim Re-Index verloren) und auch das Fehlerbild passt (untere 20% zeigen kurz eine farbige Fläche).
Das würde auch zum Re-index passen: die Frames sind ja da, so dass VDR sie findet (und keinen Fehler bemerkt), aber sie sind halt nicht vollständig. Leider habe ich die Originalaufnahme nicht mehr sondern nach dem Schnitt gelöscht so dass ich nicht weiter testen kann.

Beim Durchsuchen aller noch vorhandener Logs habe ich folgende Maximalgröße gefunden:
ERROR: frame larger than buffer (2147336 > 1048476)
was knapp 2098 kB entspricht, also mehr als 2 MB

kls · February 23, 2026 at 11:59 AM

FireFly Good catch!
Dann werde ich MAXFRAMESIZE mal auf 3MB erhöhen und mittelfristig versuchen, das dynamisch zu handhaben.

Rene · March 1, 2026 at 10:41 PM

Here is an example how i get the pixelschmudge after cutting. This occurs when watching "over the cut mark", but if i jump tino the cutmark with 7 or 9, the picture clear is as it should be

The content cannot be displayed because you do not have authorisation to view this content.

VDR version 2.7.9 freigegeben

Participate now!

Similar Threads

VDR version 2.7.8 freigegeben

[gelöst]Kernel zerschossen? Bitte ein paar tips wie reparieren