Version 0.4.7 Timeshift und Permashift Unterstützung

Moin,

im Git ist eine neue Version, die die folgenden Änderungen beinhaltet:

- added token {startsin} in displaymenuschedules
- added viewelement <vdrstatistics> in main menu
- added permashift support in displaychannel
- added timeshift support in displayreplay

Das wesentliche ist der Timeshift- und Permashift Support. Der Permashift Support funktioniert natürlich nur bei aktiviertem Permashift Plugin. Ist das Plugin aktiviert, steht in displaychannel die Tokens {permashift} und {livebuffer} zur Verfügung. {permashift} ist dann true, und {livebuffer} beinhaltet die Zeit in Sekunden, die bereits gepuffert sind. In metrixHD habe ich das mal eingebaut und stelle den vorhandenen Livebuffer im Fortschrittsanzeigebalken mit dar (siehe Screenshot, der livebuffer ist rot hinterlegt).

Der Timeshift Support ist dann aktiv, wenn eine Aufnahme abgespielt wird, die noch aufgenommen wird. Ist das der Fall, stehen die weitere Tokens {timeshift} und {timeshifttotal} zur Verfügung. {timeshift} ist true, und {timeshifttotal} beinhaltet bei der Progressbar die Anzahl der insgesamten Frames der Aufnahme (wenn sie denn mal fertig ist) bzw. die Gesamtzeit der Aufnahme (bei <totaltime>). Ausserdem wird die Endezeit entsprechend ausgerechnet. Alle diese Werte basieren auf der Endezeit des der Aufnahme zugrundeliegenden Events (und dem Anfang der Aufnahme). Im angehängten Screenshot ist die Umsetzung in metrixHD gezeigt: der Balken insgesamt entspricht der insgesamten Zeit der *fertigen* Aufnahme, der weiße Balken das bereits aufgenommene und der hellblaue Balken die aktuell wiedergegebene Position. In der Zeitanzeige wird sowohl die gesamte Zeit als auch die Länge der tatsächlichen Aufnahme angezeigt, die Endzeit entspricht der Zeit, wenn man die Aufnahme fertig anschauen würde.

Ich hoffe ich habe nicht zu wirr gefaselt Wer es in seinen Skin übernehmen möchte, schaut sich am besten mal die Änderungen in metrixHD in displayreplay an.

Ciao Louis

Moin,

freut mich dass es funktioniert

Da ich ja immer als Anhaltspunkt das der Aufnahme zugrunde liegende Event Objekt benutze, kann es in etwas "komischen" Konstellationen ggf. zu ungewünschten Effekten kommen. Beispielsweise wenn man ziemlich am Ende eines Events Pause drückt und dann der Timeshift die nächste Sendung beinhaltet...jedoch scheint der VDR in solch einem Fall (ab einem bestimmten Grenzwert) eh das nächste "vollständige" Event zu benutzen. Bei meinen Tests habe ich bisher keine Probleme feststellen können, jedoch habe ich natürlichnicht alles getestet. Schaumer mal, wenn was komisch ist, dann bitte bescheid geben.

Ciao Louis

PS: Das Timeshift Feature funktioniert übrigens erst ab VDR Version 2.1.1. Aber kleinere Versionen scheinen ja eh nicht mehr so viele zu nutzen.

Moin,

eigentlich prüfe ich, ob der Beginn der Aufnahme vor oder nach dem Eventstart liegt. Ist der Start der Aufnahme nach dem Beginn des Events, berechne ich EventEnde - AufnahmeStart. Eigentlich sollte es also passen. Ich hab das auch getestet und es hat eigentlich gepasst. Ggf. gibt der VDR unter gewissen Umständen per cRecording::Start() nicht die wirkliche Startzeit der Aufnahme, sondern des Events zurück?! Muss ich nochmal schauen...

Ciao Louis

Moin,

Quote from machtnix

Kann es vielleicht am epgsearch plugin liegen ?

unwahrscheinlich

Mach doch bitte mal folgendes: ergänze in der Datei displayreplay.c in der Zeile 135:

double fps = recording->FramesPerSecond();
    time_t liveEventStop = event->EndTime();
    time_t recordingStart = recording->Start();
+   esyslog("skindesigner: Recording Start Time: %s, Event Start Time %s, Event Stop Time %s", *TimeString(recordingStart), *TimeString(event->StartTime()), *TimeString(liveEventStop));    
    int framesTotal = (liveEventStop - recordingStart)*fps;

Im Log siehst du dann beim Start des Abspielens einer Aufnahme die entsprechenden Werte. Ich benutze immer "liveEventStop - recordingStart" als Dauer für die TimeShift Aufnahme...wie gesagt, bei meinen Tests hat das immer gepasst. Ich gehe davon aus, dass cRecording::Start() den tatsächlichen Beginn der Aufnahme zurückgibt.

Ciao Louis

Moin,

und hat denn die Anzeige gepasst? Meine Glaskugel ist in Reparatur

Die Länge der Aufnahme sollte doch also EventStop - RecStart = 11:05 - 8:58 = 2:07h sein. Wenn du nun also z.B. um 10 mit dem schauen beginnst, sollte die Ende Zeit bei ca. 12:07 sein. Das solltest du mal nachstellen und verifizieren. Vielleicht habe ich auch noch einen Denkfehler

Ciao Louis

Stimmt, steht ja in den Logs...hmmm...das ist blöd, ich dachte eigentlich, dass das der wirkliche Start der Aufnahme ist und nicht wann er hätte sein sollen. Das Problem tritt aber bei "normalen", also vollständigen Aufnahmen, die man z.B. erst eine halbe Stunde später abeginnt anzuschauen, nicht auf, sondern nur bei Aufnahmen, bei denen eh ein Stück fehlt.

Wäre es denn in einem solchen Fall korrekt, wenn ich die tatsächliche Aufnahmelänge mit der aktuellen Zeit vergleiche? Beispiel: Eine Sendung geht von 9.00 - 11.00, wirklicher Start der Aufzeichnung ist aber erst um 10.00. Wenn du nun um 10.30 das schauen beginnst, ist die Aufzeichnung zu dem Zeitpunkt eine halbe Stunde lang, es fehlt also eine Stunde. Diese eine Stunde müsste ich dann von der insgesamten Aufzeichnungslänge für die Anzeige der Endezeit abziehen.

Wie legst du den Timer denn an? Drückst du auf Pause oder legst du den Timer über den Roten Knopf im Programm Menü an?

Ciao Louis

Quote from machtnix

Habe gerade mal getestet was passiert wenn ich eine schon laufende Sendung mit Pause in den Timeshiftmodus bringe, und da scheint die Anzeige korrekt zu sein. (Teste ich gleich mal intensiv)

Ok, interessant. Dann scheint der VDR den wirklichen Start der Aufnahme und nicht die des zugrunde liegenden Events / Timers zu benutzen.

Sieht man übrigens auch am Namen des Aufnahmeverzeichnisses, da steht die Startzeit der Aufnahme (aus VDR Sicht) mit drinn.

Wenn ich mich nicht irre, sollte der Problemfall aber über den oben beschriebenen Umweg auch hinzubekommen sein. Werde ich mal mit einbauen, sobald ich wieder ein bisschen Zeit finde

Ciao Louis

Moin,

im Git gibt es eine Version 0.4.8 mit folgenden Änderungen:

- fixed crash when deleting menuitem
- fixed ecm time display
- provide 10 last recordings in <lastrecordings> viewelement
- fixed translation in currentelement loops
- fixed timeshifttotal in displayreplay timeshift mode

machtnix: ich habe jetzt die Anfangszeit der Aufnahme so bestimmt, wie ich oben geschrieben habe: Aktuelle Zeit - Aktuelle Aufnahmelänge. Damit passt es nach meinen Tests...wäre prima wenn du auch nochmal intensiv testen könntest

Ciao Louis

Hi machtnix,

Quote from machtnix

Bei einem manuellen Aufnahmestart stimmt so die Aufnahmelänge. Bei einer Timeraufnahme fehlt mir allerdings die eingestellte Aufnahmevorlaufzeit (bei mir 3 Minuten)
aber damit kann ich leben.:-)

Das sollte eigentlich nicht sein...ich berechne ja die Startzeit der Aufnahme, indem ich die tatsächliche Länge der Aufnahme in Sekunden zum aktuellen Zeitpunkt von der aktuellen Zeit abziehe. Gibt es also einen Timervorlauf, sollte der auch berücksichtigt werden.

Quote from machtnix

Allerdings habe ich in der displayreplay.c folgende Anpassungen für mich gemacht, um die tatsächliche Aufnahmelänge zu erhalten.

int framesTotal = (liveEventStop - recordingStart + 720 )*fps;
int recLength = liveEventStop - recordingStart + 720;

der Wert 720 entspricht meiner eingestellten Aufnahmenachlaufzeit von 12 Minuten.

Wobei man doch bei der Wiedergabe einer Timeshift Aufnahme wissen will, wann der Film zu Ende ist und nicht die Aufnahme...deshalb finde ich es hier nicht sinnig, den Timernachlauf noch oben drauf zu rechnen. Ausserdem verhält sich das bei einer Sofortaufnahme auch wieder anders, da ist die Nachlaufzeit viel größer.

Quote from machtnix

Ich denke immernoch, dass es einfacher wäre die Timerzeiten vom VDR abzuholen, denn die sind sowohl bei Timeraufnahme als auch bei manuellen Aufnahmen "richtig".
Keine Ahnung ob das programmiertechnisch ein Problem ist ?

Technisch ist das kein Problem. Nach meinen Tests passt der Timer für unsere Zwecke jedoch auch nicht immer...wenn man eine Aufnahme über das "What's on" Menü für die laufende Sendung anstößt, ist die Timer Startzeit die theoretische Timer Startzeit und nicht die tatsächliche. Deshalb habe ich mich für diesen Weg entschieden...

Ciao Louis