Kategorie-Archiv: VCR.NET

Nachdem ich eigentlich dachte im VCR.NET Recording Service alles richtig gemacht zu haben, habe ich mich bei dem neuen Web Client nun doch wieder ausgetrickst und muss für 4.2 nachrüsten. Aber vielleicht an dieser Stelle kurz die Ursachen, die dem einen oder anderen helfen mögen nicht selbst in ähnliche Fettnäpfchen zu treten.

In der Web Oberfläche von VCR.NET wird die Dauer einer Aufzeichnung durch drei separate Parameter angegeben:

Soll eine Aufzeichnung über Mitternacht erfolgen, so liegt die Startzeit nach der Endzeit und der Web Client kompensiert das dadurch, dass zum Startzeitpunkt 24 Stunden hinzugefügt werden. Bei einer Aufzeichnung in die Nacht hinein, in der die Umstellung stattfindet, aber mit einem Endzeitpunkt nach der Umschaltung liefert diese Rechnung entweder eine Stunde zu viel (da kann man mit leben) oder eine zu wenig (das ist dann übel). Ein Beispiel: die Aufzeichnung beginnt am 26. 10. 2013 um 23:00 und endet um 04:00 – das sind die drei Parameter, die der Anwender eingibt. Der Web Client hat nun erst einmal den Endzeitpunkt mit dem 26. 10. 2013 04:00 angenommen. Da dieser vor dem Start liegt wurden fälschlich 24 Stunden addiert, das gibt nur 27. 10. 2013 03:00 – schade, aber knapp daneben ist auch daneben.

Zudem wurde der Startzeitpunkt aus dem ausgewählten Datum plus der Startzeit berechnet. Das ausgewählte Datum liefert der DatePicker von jQueryUI bereits als JavaScript Date. Stellt man etwa eine Aufzeichnung vom 27. 10. 2013 von 20:00 bis 22:00 so ist dieses Datum der 27. 10. 2013 00:00 in der lokalen Zeitzone – also der 26. 10. 2013 22:00 GMT / UTC. Addiert man fehlerhaft nur 20 Stunden dazu, landet man durch die Umstellung auf 27. 10. 2013 19:00 – und verliert wieder eine Stunde der Aufzeichnung! Alle Aufzeichnungen, die mit dem bisherigen 4.1 Web Client für den Tag der Zeitumstellung nach der Umstellung gemacht wurden, beginnen bei gleicher Länge eine Stunde falsch!

Mangels besserer JavaScript / jQuery Kenntnisse verwendet VCR.NET 4.2 folgende Lösung: aus den Teilinformationen Jahr / Monat / Tag der lokalen Zeitzone des ausgewählten Datums und den festgelegten Uhrzeiten werden die Zeitpunkte für Start und Ende ermittelt. Liegt der Startzeitpunkt vor den Endzeitpunkt ist alles in Ordnung. Ansonsten wird nur der Tag im Endzeitpunkt mittels Date.setDate() um 1 erhöht. JavaScript führt hier nicht nur den notwendigen Sprung auf den nächsten Monat / das nächste Jahr aus, sondern berücksichtigt dabei auch die Zeitzone und verändert tatsächlich nur den Tag der lokalen Zeitzone.

Die Aufzeichnungsdauer wird dann korrekt aus der Differenz von End- und Startzeitpunkt ermittelt. Dass VCR.NET mit der Dauer und nicht dem Endzeitpunkt arbeitet ist eine Geschichte für einen anderen BLog Eintrag irgendwann später einmal…

Sorry an alle Zeitgeschädigten…

Jochen

In der Standardeinstellung versucht VCR.NET immer Geräten mit höherer Priorität bei der Zuweisung von Aufzeichnungen zu bevorzugen. Hat man mehr als zwei Karten so kann es in der Standardeinstellung des Planungsalgorithmus dazu kommen, dass zwei Karten zum gleichen Zeitpunkt die gleiche Quelle aufzeichnen. Hier ein Beispiel aus der Praxis:

 19:25-21:05 KiKA auf Gerät A
 20:10-22:20 RTL auf Gerät C
 20:10-23:40 HD auf Gerät B
 22:05-00:20 RTL auf Gerät A 

Den Geräten A und B wurde die Priorität 100 zugeordnet, C allerdings nur 50. Um 22:05 erfolgt die Zuordnung der letzten Aufzeichnung an Gerät A, da dieses die höchste Priorität und gerade nichts zu tun hat – in der Praxis ist die Entscheidung geringfügig komplizierter führt aber zum selben Ergebnis.

Die neue Regel ParallelSource:Min erlaubt es VCR.NET nun die Aufzeichnung auf dem Gerät C auszuführen, da dieses auf der gewünschten Quelle bereits aktiv ist – obwohl dadurch ein Gerät niedrigerer Priorität länger als unbedingt notwendig in Betrieb bleibt.

Da die Auswertung der Regel allerdings etwas zeitaufwändiger ist, muss sie in VCR.NET gesondert aktiviert werden um berücksichtigt zu werden. Oder kurz: die Standardregeln enthalten diese neue Bewertungsregel nicht.

Mal schauen, ob das jemandem hilft…

Jochen

Meine alte Nexus hat unter Windows 7 leider die unangenehme Eigenschaft, dass beim Starten einer Aufzeichnung (respektive Nutzung der Karte überhaupt) das System kurz ins Stocken kommt. An sich kein Problem, aber wenn meine andere DVB Karte (Nova-HD-S2) gerade eine Aufzeichnung macht, gibt es kurz Aussetzer. Für VCR.NET 4.2 wird es daher eine eigene Planungsregel geben – hey, ich nutze das halt auch 🙂 :

In dieser Variante (die Regel ist durchaus etwas mächtiger) sagt die Zeile mit der Nexus: wenn möglich (i.e. keine der vorherigen Regeln wird verletzt) sollten Aufzeichnung auf der Nexus immer vor Aufzeichnungen anderer Karten starten. Da in der Standardeinstellung die Priorität der Geräte erst ganz am Ende berücksichtigt wird heißt das, dass die Nexus in solchen Situationen bevorzugt wird, obwohl sie (bei mir aus gutem Grund) eigentlich eine niedrigere Aufzeichnungspriorität hat.

Viel Spaß

Jochen

Für VCR.NET 4.1 habe ich einige grundlegende Änderung beim Arbeiten mit dem Schlafzustand vorgenommen. Ursache war, dass seit Windows Vista der Windows Dienst den durch den Anwender ausgelösten Schlafzustand nicht mehr unterbinden kann und sich dem ganzen Vorgang stillschweigend anschließen muss. Das Beenden laufender Aufzeichnungen ist dabei ein wichtiger Schritt und das scheint auch soweit zu klappen. Allerdings wollte ich VCR.NET dafür sorgend lassen, dass zum einen ein überhasteter Schlafzustand Aufzeichnungen nicht ganz unter den Tisch fallen lässt zum anderen aber der Rechner auch nicht direkt wieder aufgeweckt wird.

Die Grundidee war der neue Konfigurationsparameter zur minimalen Verweildauer im Schlafzustand. Wenn der Anwender eine Minute vor Beginn in der Aufzeichnung den Schlafzustand auslöst, dann respektiert VCR.NET das erst einmal. Allerdings wird sichergestellt, dass der Aufweckzeitpunkt durch einen sogenannten WaitableTimer nicht weiter als diese minimale Verweildauer in der Zukunft liegt – die Voreinstellung ist 5 Minuten, i.e. im Beispiel gingen “nur” 4 Minuten der Aufzeichnung verloren.

Leider haben wir nun festgestellt, dass das so nicht immer geht. Es scheint so zu sein, dass Windows den Aufweckzeitpunkt ignoriert wenn dieser zu spät während des Übergangs in den Schlafzustand erfolgt! Einige Änderungen in VCR.NET 4.1 führen dazu, dass je nach konkreter Konfiguration, Anzahl von Aufzeichnungen und Karten und abhängig von der Leistungsfähigkeit des Rechners in einigen Fällen genau dies passiert. Und dann wacht der Rechner für die nächste Aufzeichnung gar nicht auf – blöd, wenn das im Urlaub passiert.

Ab VCR.NET 4.2 kann man dieses neu eingeführte Verhalten wieder deaktivieren – in der Voreinstellung ist es weiterhin aktiv, für mich benutze ich es als Selbstschutz gegen persönliche Dummheit.

Ist das Häkchen gesetzt, so manipuliert VCR.NET 4.2 den Aufweckzeitpunkt nicht mehr. Würde das Kontrollzentrum einen gelben Hintergrund zeigen und damit signalisieren, dass eine Aufzeichnung unmittelbar bevorsteht, so kann es dann sein, dass der Rechner sehr schnell wieder aufwacht – und dann die Aufzeichnung korrekt ausführt. Bei einem blauen Hintergrund und damit einer laufenden Aufzeichnung kann das Verhalten nicht genau vorhergesagt werden. Überlappen sich Aufzeichnungen, so wird VCR.NET zu Beginn der Folgeaufzeichnung aufwachen, ansonsten eventuell unnötig zu dem Zeitpunkt, an dem die unterbrochene Aufzeichnung eigentlich zu Ende wäre. Mit Verlust ist auf jeden Fall zu rechnen.

Nach aktuellem Kenntnisstand ist das im Moment das beste, was ich für VCR.NET 4.2 machen kann.

Jochen