Archiv des Autors: Jochen

Für VCR.NET 4.2 habe ich mir einen eigenen Wunsch erfüllt und die Unterstützung des Schlafzustands durch das Kontrollzentrum (das kleine Kamera Symbol im System Tray von Windows) etwas erweitert. Die im Folgenden beschriebenen Funktionen sind bereits in der ersten Beta Version von 4.2 enthalten.

Vielleicht aber kurz zum bestehenden Konzept: die Hintergrundfarbe der Kamera signalisiert den letzten Stand der Kommunikation des Kontrollzentrums mit jeweils einem der überwachten VCR.NET Dienstrechner. Ist die Farbe grün, gelb oder blau, dann konnte eine Verbindung zum VCR.NET Recording Service hergestellt werden und es gibt sogar eine Nutzung der angeschlossenen DVB Geräte. Bei einer roten Hinterlegung ist ein Kommunikationsversuch fehlgeschlagen – konkret wurde eine Anfrage in einer vorgegebenen Zeitspanne nicht beantwortet. Keine Hinterlegung heißt fast immer, dass der VCR.NET Recording Service bereit steht, aber keinerlei Aufzeichnung für die Zukunft geplant sind und auch keine aktive Nutzung der DVB Geräte stattfindet. In seltenen Fällen kann es aber auch sein, dass eine Anfrage an den VCR.NET Rechner geschickt wurde, diese aber weder beantwortet wurde noch durch das Timeout als nicht beantwortet bewertet wurde – das ist etwa die ersten Sekunden nach dem Starten des Kontrollzentrums der Fall. Dieser Sonderfall wird nun nicht weiter betrachtet.

Ist die Kamera zu einem der überwachten VCR.NET Rechner nicht rot, so bietet das Kontrollzentrum einen Menüpunkt zum Versetzten des jeweiligen Rechners in den Schlafzustand an. Dabei wird nach einer interaktiven Sicherheitsrückfrage allerdings nicht nur die entsprechende Methode von Windows aufgerufen, sondern vielmehr VCR.NET direkt angesprochen. Ist eine Aufzeichnung aktiv, so findet kein Übergang statt.

Wenn die Kamera allerdings rot hinterlegt ist, so wird ein anderer Menüpunkt angeboten, über den der Rechner mittels eines Wake-On-LAN (WOL) Magic Packets aus dem Schlafzustand aufgeweckt werden kann. Natürlich kann es sein, dass der Rechner gar nicht im Schlafzustand ist, sondern vielleicht nur der VCR.NET Dienst nicht läuft oder nicht antwortet – da hilft natürlich auch das Aufwecken wenig, aber in den normalen Fällen ist das eine sehr praktische Funktionalität. Dieser Menüpunkt wird übrigens nicht für den lokalen Rechner angeboten – der ist ja definitiv schon wach, hier muss also sicher eine andere Ursache vorliegen.

Hinweis: In der aktuellen Implementierung gibt es für das Aufwecken im Kontrollzentrum keinerlei Fehlerbehandlung. Im Zweifelsfall passiert einfach nichts. Zur Selbstkontrolle kann man mittels NSLOOKUP die IP Adresse des betroffenen Rechners ermitteln und dann mit ARP -A prüfen, ob der Rechner überhaupt bekannt ist: das Kontrollzentrum sucht genau in dieser Liste die IP Adresse und sendet den Aufweckbefehl dann an die entsprechende physikalische Adresse der zugehörigen Netzwerkkarte.

Ich habe den WOL Mechanismus jetzt gegen zwei Rechner ausprobiert und es scheint prima zu funktionieren. In beiden Fällen musste ich im Gerätemanager die entsprechende Netzwerkkarte vorbereiten, wobei es wichtig ist, dass man die Option aktiviert, dass der Rechner nur über das Magic Packet aufgeweckt werden soll – sonst sorgt alleine der nächste Kontrollanruf der Kontrollzentrums schon für das erneute Starten, was zumindest bei mir völlig unerwünscht war. Warum Windows verlangt, dass man ihm erlauben muss, das Gerät zum Energie sparen zu deaktivieren bevor man das Aufwecken konfigurieren darf, bleibt mir ein Rätsel.

Einer der Rechner hat eine separate Netzwerkkarte (die auf dem Mainboard ist abgeraucht), da reichte die beschriebene Maßnahme aus. Der andere verwendet die auf dem Mainboard integrierte Karte, da war es dann notwendig, auch im BIOS eine Reaktivierung über die Netzwerkkarte zusätzlich freizuschalten. Dabei erwies es sich als kleine Stolperfalle, dass eine EuP Option erst einmal deaktiviert werden musste, bevor die WOL Option freigeschaltet werden konnte.

Viel Spaß mit dem neuen Feature

Jochen

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