Jumpplay-Patch in testing-vdr

Hallo,
da in eTobis Quellen der Jumpplay-Patch nicht enthalten ist, habe ich testweise die Quellen des testing-vdrs aus dem yavdr-repository verwendet.
Damit gibt es zwar nun die Optionen im VDR-Menü, jedoch funktioniert der Patch nicht. Egal ob Sprung Bei Schnittmarke an oder aus ist, der VDR ignoriert bei der Wiedergabe einfach die Marken (muss also von Hand über die Marken der Werbung springen).
Kann es sein das der Patch gar nicht mehr mit den Quellen von VDR 2.0 funktioniert?

Die Option Pause beim Setzen einer Schnittmarke (die kommt ja nicht aus dem Patch) wird auch ignoriert. Auch wenn die Option deaktiviert ist, hält die Wiedergabe an sobald ich eine Schnittmarke setze.

Ist das Verhalten nur bei mir so (nutze nur die Quellen vom VDR aus dem yavdr-Repo, alles andere ist von Debian oder eTobi).

Tschau, Uwe.

Hallo,
ich hab noch mal im SysLog geschaut. Dort wird zwar geschrieben das der VDR einen Sprung durchgeführt hat ("PlayJump: xxx Frames to xxx"), ist davon während der Wiedergabe nix zu sehen.

Mir scheint als wird der durch den Patch geänderte Frameindex bei einem Sprung ignoriert.

Tschau, Uwe.

Hallo,
seltsamerweise funktioniert der Patch seit gestern Abend so wie er soll (natürlich ohne das ich etwas geändert habe, nur neu gebootet).
Ich habe auch die gleiche Aufnahme wie vorgestern Abend zum Testen verwendet

Wenn nun noch das Problem mit den Tonspurversatz am Anfang/Ende der Werbung im Softhddevice-Plugin gelöst wird (die vorgeschlagenen Änderungen muss ich noch probieren), ist alles Prima.

Tschau, Uwe.

Hallo,
ich muss den Thread noch mal aus der Versenkung holen.
Ich installiere gerade einen neuen VDR und hatte gehofft dass dieses Problem nicht mehr auftritt. Als Paketquellen habe ich die vom testing yavdr (dürfte die 2.0.4 sein) genommen, da darin der JumpPlay-Patch enthalten ist.

Leider funktioniert der Patch (wie auch schon vor einem Jahr) nicht richtig mit aktuelleren VDR Versionen (in der 1.7.28 hatte er ja noch funktioniert).
Wenn ich innerhalb einer Aufnahme Schnittmarken setzen, dann werden diese vom JumpPlay-Patch ignoriert. Sobald man aber die Aufnahme verlässt und wieder startet, funktioniert alles wie s soll.
Das Verhalten erklärt auch warum ich vor einem Jahr dann den Fehler nach dem Neustart nicht mehr nachvollziehen konnte, da das Problem nur besteht solange man die Aufnahme noch nicht verlassen hatte.
Wenn während einer Aufnahme Noad im Online-Modus läuft, funktionieren die Schnittmarken auch richtig. Das Problem der vom Patch ignorierten Schnittmarken scheint also nur bei fertigen Aufnahmen zu bestehen.

Ich glaube mich zu erinnern hier mal einen Thread darüber gelesen zu haben (finde den aber weder mit der Foren noch mit der Google-Suche nicht mehr). Darin wurde vermutet dass dieses Problem durch das Veränderte Verhalten vom VDR verursacht wird:
Changelog für Version 1.7.38: "Fixed moving editing marks, so that they don't get overwritten with old values through an update of the marks file."

Nutzt niemand mehr den JumpPlay-Patch (ist doch im YaVDR im Standard aktiv), oder stört niemanden das unschöne Verhalten? Mir jedenfalls geht es etwas auf den Geist nach dem Setzen/Ändern der Schnittmarken die Aufnahme immer neu starten zu müssen.
Ich habe auch schon im Diff zwischen der 1.7.37 und 38 geschaut ob ich die Ursache finde, glaube aber ich würde nur noch mehr kaputt machen da ich nicht weiß welche Nebenwirkungen meine Änderungen haben würden.

Tschau, Uwe.

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;
}

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.

Hallo Lars,
ich habe jetzt auch mal geschaut welcher Typ wovon abgeleitet ist.
Das einfachste wäre wenn man in dem Patch folgendes einbaut:

Neue Variablen/Parameter:
-der dvbPlayer erhält eine Variable "ForceRefreshMarks"
-die Funktion cMarks::Update erhält einen zusätzlichen Parameter "ForceShortUpdateTime"

Änderungen der Funktionen:
-Solange ForceRefreshMarks beim dvbPlayer True ist, wird der Parameter "ForceShortUpdateTime" beim Aufruf von cMarks::Update mit True übergeben
-Wenn cMarks::Update mit True zurück kehrt, wird "ForceRefreshMarks" auf False gesetzt (in dem Fall wurden die aktuellen Marken ja eingelesen)
-Wenn "ForceShortUpdateTime" True ist, wird geprüft ob nextUpdate mehr als 5s in der Zukunft liegt, wenn ja, wird nextUpdate auf t gesetzt (und somit die eigentliche Funktion von Update forciert)
Vor der Zeile nextUpdate = t + d, wird wenn "ForceShortUpdateTime" True ist d auf einen Wert kleiner 5s gesetzt.
Dadurch wird, wenn in dem Durchlauf keine neuen Marken geladen werden, der nächste Durchlauf nicht sofort durchgeführt (nextUpdate liegt dann ja weniger als 5s in der Zukunft). Dennoch ist das Updateintervall so klein das es nur eine geringe Verzögerung gibt sobald die marks-Datei tatsächlich aktualisiert wurde.

Es sind wirklich nicht viele Änderungen, aber ich habe keine Ahnung vom Programmieren/Compilieren im Linux (man müsste ja erst alle Patche anwenden, dann die Änderungen vornehmen und dann einen neuen Patch daraus generieren lassen).
Tschau, Uwe.