Hallo,
ich habe mich gestern Abend mal noch etwas mit dem Thema befasst.
An sich funktioniert der JumpPlay-Patch auch mit aktuellen VDR Versionen. Hauptproblem ist aber zurzeit das die aktuellen Schnittmarken vom Wiedergabeteil des VDRs ignoriert werden.
Nach etwas lesen des Quelltextes habe ich aber gesehen das der Wiedergabeteil vom VDR in welchem auch der Hauptteil vom JumpPlay-Patch sitzt (dvbplayer.c), die Schnittmarken aktualisieren möchte. Dazu ruft er sehr oft (glaube bei jedem Frame bzw. Paket) von der Variable "marks" (Typ cMarks) die Update-Funktion.
Diese Funktion liest das letzte Aktualisierungsdatum der marks-Datei und vergleicht dieses mit dem letzten bekannten Aktualisierungsdatum. Sollte sich das Datum geändert haben, wird die Datei und somit auch die Schnittmarken neu eingelesen (und würden dann auch dem dvbplayer/jumpplay-patch zur Verfügung stehen.
Damit das Dateidatum nicht zu oft überprüft wird, mehr sich die Update-Funktion wann sie wieder mal auf eine Änderung der Datei prüfen muss. Dieser Zeitabstand wird abhängig vom Zeitpunkt der letzten Aktualisierung der marks-Datei ermittelt:
bool cMarks::Update(void)
{
time_t t = time(NULL);
if (t > nextUpdate) {
time_t LastModified = LastModifiedTime(fileName);
if (LastModified != lastFileTime) // change detected, or first run
lastChange = LastModified > 0 ? LastModified : t;
int d = t - lastChange;
if (d < 60)
d = 1; // check frequently if the file has just been modified
else if (d < 3600)
d = 10; // older files are checked less frequently
else
d /= 360; // phase out checking for very old files
nextUpdate = t + d;
if (LastModified != lastFileTime) { // change detected, or first run
lastFileTime = LastModified;
if (lastFileTime == t)
lastFileTime--; // make sure we don't miss updates in the remaining second
cMutexLock MutexLock(&MutexMarkFramesPerSecond);
MarkFramesPerSecond = framesPerSecond;
if (cConfig<cMark>::Load(fileName)) {
Align();
Sort();
return true;
}
}
}
return false;
}
Alles anzeigen
Wie man sieht wird wenn die marks-Datei schon sehr alt ist (älter als 1h) ein sehr langer Aktualisierungsintervall gewählt (Variable d, welche den nächsten Aktualisierungszeitpunkt beeinflusst "nextUpdate = t + d;").
Wenn nun die marks Datei während des Setzens der Schnittmarken geändert wird, würde die Variable marks vom dvbplayer erst davon etwas mitbekommen wenn der ermittelte Aktualisierungszeitpunkt (unter Umständen mehrere Minuten später) erreicht ist.
Dieses Verhalten ist aber nicht neu und war auch schon in der 1.7.28 so. Was sich aber in neueren VDR Versionen geändert hat, ist der Zeitpunkt wann die marks-Datei beim Setzen der Schnittmarken geschrieben wird. Früher war es so das bei jeder Änderung der Schnittmarken die Datei sofort geschrieben wurde.
Aktuell ist es aber so das sich beim Schieben der Marken nur gemerkt wird das sich diese geändert haben. Sobald dann die Wiedergabe/Schnittsteuerung geschlossen wird (der Dialog in dem die Schnittmarken/Wiedergabestatus zu sehen sind) indem man OK klickt oder die Aufnahme verlässt, wird geprüft ob sich die Marken geändert haben.
Wenn ja, wird die marks-Datei geschrieben.
Wenn man nun z.B. in einem Film die Schnittmarken ändert, wurde früher die marks-Datei beim ersten Ändern einer Schnittmarke geschrieben. Aktuell ist es aber so das die Datei erst geschrieben wird wenn man OK auf der Fernbedienung geklickt hat.
Angenommen der Aktualisierungsintervall von cMarks.Update wurde auf 2min gesetzt (also aller 2min wird das Dateidatum geprüft). So war die Wahrscheinlichkeit dass wenn man mit dem Setzen der Schnittmarken fertig war, die Update Funktion diese bereits gelesen hat (bei Änderung, wird der Updateintervall dann auf 1s geändert, so dass weitere Änderungen sofort erkannt werden). Jetzt wird die Datei aber erst viel später geschrieben, so dass man in dem Beispiel eventuell erst nach 2min die aktuellen Schnittmarken im dvbplayer zur Verfügung hat.
Ich habe mal folgenden Test durchgeführt:
Test 1:
-aktuelle marks-Datei in einer Aufnahme erzeugt (einfach irgendeine Schnittmarke ändern und Wiedergabe verlassen)
-Wiedergabe gestartet, durch sehr aktuelle marks-Datei wird der Aktualisierungsintervall von cMarks.Update beim Öffnen der Aufnahme sehr kurz eingestellt
-Schnittmarke geändert (ok geklickt um Fenster zu schließen und marks-Datei zu schreiben)
-ein paar Sekunden vor die Schnittmarke gesprungen und Wiedergabe fortgesetzt
Die Schnittmarke wurde durch das kurze Aktualisierungsintervall bereits eingelesen und der JumpPlay-Patch hat korrekt an der geänderten Marke funktioniert
Test 2:
-Wiedergabe einer ältere Aufnahme gestartet, durch sehr alte marks-Datei wird der Aktualisierungsintervall von cMarks.Update beim Öffnen der Aufnahme sehr lang eingestellt
-Schnittmarke geändert (ok geklickt um Fenster zu schließen und marks-Datei zu schreiben)
-ein paar Sekunden vor die Schnittmarke gesprungen und Wiedergabe fortgesetzt
Die Schnittmarke wurde durch das lange Aktualisierungsintervall noch nicht eingelesen und der JumpPlay-Patch die geänderte Marke ignoriert
Hätte ich längere Zeit gewartet wäre der nächste Aktualisierungszeitpunkt von cMarks.Update erreicht gewesen und die aktuellen Marken wären eingelesen worden.
Ich denke wenn man in der cMarks::Update-Funktion den maximalen Intervierungsintervall verkürzt (z.B. auf 10-30s) dürfte die Verzögerte Aktualisierung der Schnittmarken vom dvbplayer bei normalen Nutzungsverhalten nicht mehr auffallen (man hat ja fast immer mehr als 30s bis zur ersten Schnittmarke/Werbung eines Films).
Da bei nicht so alten marks-Dateien ohnehin ein Intervall von 1-10s verwendet wird ohne das der VDR davon gestört wird, dürfte ein maximales Intervall von 30s vollkommen unkritisch sein.
Tschau, Uwe.