VDR version 2.7.7 freigegeben

1755185460 == 14. August 2025 17:31:00 GMT+02:00, also time(NULL). D.h. t in CheckLockTime müsste 0 sein, was aber vorher geprüft wird?!

Quote from seahawk1986

Pakete für Ubuntu 24.04 (für 22.04 und 20.04 dauert es noch) gibt es hier: https://launchpad.net/~seahawk1986-h…buntu/vdr-2.7.7

Kannst Du bitte das Zappilot Plugin unter Jammy mal noch ansehen? Hab von 2.7.5 zu 2.7.7 gewechselt und da ist es nicht vorhanden / fehlt. Danke.

Ich habe zaphistory und zappilot gerade hochgeladen.

kls ,

ich bin im Moment dabei meine alten Aufnahmen etwas zu bereinigen (vor dem TS-Format) und habe dabei festgestellt, das zwar der Schnitt mit der aktuellen Version noch funktioniert, die "info.vdr" Datei aber nicht angelegt wird. Es wird stattdessen eine "info" Datei angelegt, die kaum Informationen enthält:

z.B. nur noch:
E 0 0 0 FF FF 
F 25 
P 99 
L 99 
O 0

Sollte das noch gefixt werden?

Nach einem händischen Kopieren der "info.vdr" Datei in das Verzeichnis der geschnitten Aufnahme wird nach einem VDR-Neustart die Information wieder angezeigt, ein Neueinlesen der Aufnahmen reicht aber nicht.

Grüße
kamel5

Quote from kamel5

ein Neueinlesen der Aufnahmen reicht aber nicht

das war leider schon immer so.

Quote from kamel5

Neueinlesen der Aufnahmen reicht aber nicht

Wenn der Timestamp der info-Datei neuer als das letzte Einlesen ist, wird sie mit neueren VDR-Versionen erneut eingelesen. Ob das auch für die ältere info.vdr gilt müsstest Du mal ausprobieren.

Quote from jsffm

das war leider schon immer so.

Das mag sein, ich weiß aber nicht ob das kls schon so bekannt ist. Wenn es so bleibt dann kann ich auch damit leben. Ich habe mich in der Vergangenheit nur gewundert, das nach einem Schnitt einer alten Aufnahme, keine Info mehr angezeigt wurde. Heute habe ich mir das dann mal genauer angesehen...

Quote from FireFly

Wenn der Timestamp der info-Datei neuer als das letzte Einlesen ist, wird sie mit neueren VDR-Versionen erneut eingelesen. Ob das auch für die ältere info.vdr gilt müsstest Du mal ausprobieren.

Ja, mit dem neueren Format ("info" Datei) funktioniert es, nur mit dem alten nicht.

Grüße
kamel5

Quote from kls

Da fehlt wohl noch irgendwo die Sonderbehandlung für alte info.vdr-Files. Wenn das jemand ergänzen mag, übernehm ich das gerne.

Ok, im Anhang mal ein Patch dazu. Ich habe versucht, das so wenig wie möglich invasiv zu machen. Nach einem Schnitt wird damit die "info.vdr"-Datei richtig angelegt und auch aktualisiert. Zusätzlich wird noch die Zeile mit den "Errors" eingetragen. Ich weiß aber nicht, ob bei alten Aufnahmen Fehler gezählt werden, da wird wahrscheinlich immer "0" drin stehen.

Der Patch enthält auch eine Änderung in "cRecordingInfo::Write()", der die Reihenfolge von "channelName" und "channelID" gemäß der alten "info.vdr"-Datei zurückschreibt. Möglicherweise könnte man diese Änderung auch lassen, denn die Reihenfolge scheint beim Einlesen keine Rolle zu spielen.

Ich konnte bei meinen Tests keine grundsätzlichen Probleme mit dem Patch feststellen, das schließt aber nicht aus, das ich etwas übersehen habe.

Grüße
kamel5

Quote from kamel5

Zusätzlich wird noch die Zeile mit den "Errors" eingetragen. Ich weiß aber nicht, ob bei alten Aufnahmen Fehler gezählt werden, da wird wahrscheinlich immer "0" drin stehen."

In index.vdr werden keine Fehler gezählt, da wären auch keine Bits mehr frei in tIndexPes, deshalb gibts das nur bei tIndexTs, also im TS-Format.
"0" heißt ja fehlerfrei und das weiß man bei PES-Aufnahmen nicht, deshalb sollte das beim Default -1 (für 'unknown') bleiben wie es auch in cRecordingInfo initialisiert wird.
Dann kann man IMHO die Errors in info.vdr auch gleich weglassen. Ansonsten:

Quote from kls

Was sollen die Änderungen in den *.po-Dateien?

Sorry, das ist mir durchgerutscht. Da gibt es ja keine Änderungen.

Quote from FireFly

Dann kann man IMHO die Errors in info.vdr auch gleich weglassen.

Quote from kls

Sehe ich auch so.

Ok, anbei der aktualisierte Patch, jetzt ohne po-Dateien und ohne Rückschreiben des Errorfeldes.

Quote from kamel5

Der Patch enthält auch eine Änderung in "cRecordingInfo::Write()", der die Reihenfolge von "channelName" und "channelID" gemäß der alten "info.vdr"-Datei zurückschreibt.

Diese Änderung habe ich wieder entfernt, ich weiß nicht mehr, wo ich das her hatte, vielleicht eine Fehlinterpretation.

Grüße
kamel5

kls ,

kannst Du Dir bitte noch folgenden zusätzlichen Patch ansehen.

Durch die Änderungen von "0001-Fix-cutting-off-PesRecording-v2.patch" scheint es jetzt so, das die Prüfung in cRecording::cRecording(), ob die Info-Datei existiert, nicht mehr nötig ist.

Das:

  FILE *f = fopen(InfoFileName, "r");
  if (f) {
     if (!info->Read(f))

könnte man auch durch:

if (info->Read()) {

ersetzen, da in "info->Read()" auch geprüft wird, ob die Datei vorhanden ist.

Update:
Der angehängte Patch funktioniert so nicht. Ich habe ihn erst einmal gelöscht. Wenn die aktuell laufende Aufnahme bei mir beendet ist, hänge ich einen neuen Patch an.

Grüße
kamel5

kls ,

anbei der aktualisierte Patch zum vorherigen Post. Jetzt sollte es funktionieren.

Grüße
kamel5

Danke euch, ein paar alte Aufzeichnungen im PES-Format fliegen bei mir auch noch herum. Manchmal werden die nicht richtig abgespielt, aber vielleicht wird es mit dem Patch ja besser.

Noch eine Beobachtung zu Aufzeichnungsfehlern bzw. eine Frage an kls: Vor ein paar Tagen wurden bei einer HD-Aufnahme einige Aufzeichnungsfehler detektiert. Diese wurden in der Info-Datei vermerkt und sind an der im Index markierten Stelle durch Klötzchen im Bild auch deutlich sichtbar. Beim Schneiden sind die Fehlerstände in der Info-Datei und auch die Fehlermarkierung im Index erhalten geblieben. Nach Reindizierung der Aufzeichnung sind die Fehler im Datenstrom logischerweise noch vorhanden, die Fehlermarkierungen im Index und damit auch die Zahl der Fehler in der Info-Datei sind aber verschwunden – und nach erneutem Schneiden bleiben sie es auch.

Mit vdr-checkts werden in der Aufzeichnung keine Fehler erkannt, was darauf hindeutet, dass die Fehler nicht aus Unterbrechungen des Datenstroms (Paketfolge), sondern aus Paketen mit fehlerhaften Daten (Prüfsumme) resultieren. Beim Schneiden werden solche Fehler also scheinbar übernommen, bei der Reindizierung wohl aber nicht.

kls, kannst du bitte mal nachsehen, inwiefern sich Schneiden und Reindizierung unterscheiden und ob sich die Beobachtung anhand des Codes erklären lässt? Danke dir!

PS: Ich muss mich dahingehend korrigieren, dass nach dem Schneiden der Fehler in der Info-Datei vermerkt war (siehe die Korrektur oben). Auch nach dem Schneiden der originalen Aufzeichnung ist der Fehler nur im Index vermerkt bzw. in der Fortschrittsanzeige beim Abspielen sichtbar gewesen. Und ich erinnere mich nicht, dass für die ungeschnittene Aufzeichnung im OSD in der Übersicht ein Fehler anzeigt wurde.

Quote from SHofmann

Manchmal werden die nicht richtig abgespielt, aber vielleicht wird es mit dem Patch ja besser.

Die Patche von mir haben da eigentlich keinen Einfluß drauf, da geht es nur um die "info.vdr"-Datei.

Ein Problem, wenn es nicht richtig abgespielt wird, könnte auch die "index.vdr"-Datei sein. Mit der aktuellen VDR-Version kann die aber leider nicht mehr neu erzeugt werden. Du kannst ja mal probieren, die "index.vdr"-Datei umzubenennen und dann nochmal abzuspielen. Dann geht zwar kein "Vor- und Zurückspulen", wenn es dann aber richtig abgespielt wird, liegt es wahrscheinlich daran.

Grüße
kamel5

Stimmt, die Daten aus der Info-Datei werden zum Abspielen vermutlich gar nicht benötigt.

Zum Reindizieren von PES-Aufzeichnung (also zur Neuerstellung von info.vdr) gibt es hier noch das externe Programm genindex.

Quote from kls

Ich hatte den Patch aus #40 jetzt einige Tage ohne eine Meldung in Verwendung, aber heute fand ich das hier:

Code

Aug 14 17:29:59 raspi4 vdr: [13408] channel 7 (BR Fernsehen Süd HD) event Thu 14.08.2025 17:30-18:00 (VPS: 14.08. 17:30) 'Abendschau - Der Süden' status 2->4
Aug 14 17:31:00 raspi4 vdr: [13429] ERROR: lock kept too long (1755185460 seconds)
Aug 14 17:31:02 raspi4 vdr: [13429] ./vdr cRwLock::Unlock() calling CheckLockTime at thread.c:169 at cRwLock::Unlock() at thread.c:225
Aug 14 17:31:02 raspi4 vdr: [13429] ./vdr cStateLock::Lock(cStateKey&, bool, int) at thread.c:794
Aug 14 17:31:02 raspi4 vdr: [13429] ./vdr cTimers::GetTimersRead(cStateKey&, int) at timers.c:1298
Aug 14 17:31:02 raspi4 vdr: [13429] ./vdr cSVDRPClientHandler::ProcessConnections() at svdrp.c:647
Aug 14 17:31:02 raspi4 vdr: [13429] ./vdr cSVDRPClientHandler::Action() at svdrp.c:737
Aug 14 17:31:02 raspi4 vdr: [13429] ./vdr cThread::StartThread(cThread*) at thread.c:323
Aug 14 17:31:39 raspi4 vdr: [13412] SATIP: Idle timeout - releasing [device 2]

Die Zahl von 1755185460 Sekunden erscheint nicht realistisch, kann sich also nur um einen Bug handeln. Unmittelbar vor und nach dieser Meldung ist allerdings nichts Ungewöhnliches im Log. Meine Vermutung ist, dass vielleicht lockTime nicht richtig initialisiert wurde, ich sehe aber nicht, wo das passieren könnte. Vielleicht mag der eine oder andere das ja mal kritisch begutachten. Ich überlege, den Patch fest einzubauen, würde aber natürlich vorher gerne sicherstellen, dass sowas nicht nochmal passiert.

Das ist bei mir jetzt auch aufgetreten:

2025-09-22T16:04:54.569511+02:00 rpi4s vdr: [1144632] ERROR: lock kept too long (1758549894 seconds)
2025-09-22T16:04:55.201496+02:00 rpi4s vdr: [1144632] /usr/bin/vdr cRwLock::Unlock() calling ?? at ??:0
2025-09-22T16:04:55.201734+02:00 rpi4s vdr: [1144632] /usr/bin/vdr cSchedules_Lock::~cSchedules_Lock() calling ?? at ??:0
2025-09-22T16:04:55.201817+02:00 rpi4s vdr: [1144632] /usr/bin/vdr main calling ?? at ??:0

Ich denke, da rufen 2 Prozesse fast gleichzeitig CheckLockTime auf.

static void CheckLockTime(time_t &t)                                                                                                                            
{                                                                                                                                                               
  if (t > 0) {                                                                                                                                                  
     int d = time(NULL) - t;                                                                                                                                    
     if (d > MAX_LOCK_TIME) {                                                                                                                                   
        esyslog("ERROR: lock kept too long (%d seconds)", d);                                                                                                   
        cBackTrace::BackTrace();                                                                                                                                
        }                                                                                                                                                       
     }                                                                                                                                                          
  t = 0;                                                                                                                                                        
}

In Zeile 3 if (t > 0) ist t noch größer 0, und in Zeile 4 int d = time(NULL) - t ist t == 0. Also hat ein anderer Prozess zwischen Zeile 3 und 4 t = 0 gesetzt.