Dr. Jochen Manns

Der VCR.NET Recording Service legt für jede einzelne Aufzeichung eine TS (Transport Stream) Datei an. Der Speicherort der Datei kann in gewissen Grenzen frei gewählt werden, der Dateiname selbst setzt sich im Wesentlichen aus den Parametern der Aufzeichnung zusammen – etwa dem Namen der Aufzeichnung und dem Startzeitpunkt. Die möglichen Muster zum Zusammenbau des Dateinamens werden mit VCR.NET 3.0 deutlich erweitert.

Bei der Konfiguration des VCR.NET ist der Anwender an dieser Stelle sehr frei. Zu dieser Freiheit ist allerdings auch eine Warnung angebracht: der VCR.NET prüft nicht, ob ein Dateiname doppelt vorkommt und überschreibt bei einer unglücklichen Konfiguration ältere Dateien ohne Vorwarnung. Es wird empfohlen, zumindest die volle Startzeit (bis zur Sekunde) und den Namen der Aufzeichnung in das Muster einfliessen zu lassen. Die genaue Zeit garantiert, dass bei einem Neustart der Aufzeichnung (manuell durch den Anwender oder automatisch bei Abbruch des digitalen Datenstroms während eines Gewitters) ein anderer Dateiname erzeugt wird. Der Name kann wichtig sein, wenn auf mehreren DVB Geräten gleichzeitig eine Aufzeichnung beginnt – theoretisch reicht natürlich die Angabe des DVB.NET Geräteprofils im Muster.

Ach, so etwa wird die Konfiguration im VCR.NET 3.0 aussehen:

Die ersten Entwicklertests von VCR.NET 3.0 mit Benutzung der DVB.NET 3.0 Geräteprofile sind durch. Auch wenn ich einige Punkte wie etwa den Übergang in den und aus dem Schlafzustand noch nicht verifizieren konnte, so sieht es aus, als wäre die Kernfunktionalität des VCR.NET nach der großen Umstellung wieder hergestellt. Aufzeichnungen, EPG Sammlungen und Sendersuchlauf tun es und alles kann an eines von optional mehreren für den VCR.NET freigegebenen Profilen gebunden werden.

Der erste Zipfel vom nächsten Schritt ist auch getan: der Aufbau einer Entwicklungsumgebung für den ASP.NET 2.0 basierten Thin-Client. Ich kann nun in der Gesamtlösung den VCR.NET Dienst als normale Anwendung starten und den Web Server darin über den Browser bei voller Debug Funktionalität ansprechen. Hört sich trivial an, hatte aber einige kleine Fallstricke.

Da ich den VCR.NET Recording Manager nicht mehr weiter ausbauen will, werde ich neue Funktionalitäten nun erst einmal in den Thin-Client einbauen. Das beginnt mit der Möglichkeit, die Administration über den Browser durchzuführen – der alte Menüpunkt VCR.NET konfigurieren. Danach kommen Aufzeichung mit zusätzlicher Auswahl des DVB.NET Geräteprofils. Der VCR.NET Recording Manager wird, so lange es ihn denn noch gibt, immer nur das erste freigegebene Profil ansprechen können. Für alle Anwender mit nur einer DVB Karte ist das völlig ausreichend – und das dürfte die Mehrzahl der Anwender sein.

DVB.NET Geräteprofile erlauben es, dass mehrere gleichartige Geräte (etwa DVB-S Karten) sich eine Kanaldatei teilen. Die Kanaldatei wird einem Profil zugeordnet, nur auf diesem kann auch ein Sendersuchlauf durchgeführt werden.

Wie bildet sich dieses Konzept auf VCR.NET ab? Bei der folgenden Darstellung verzichte ich einfach mal auf den Fall kaskadierender Abhängigkeiten (Profil A verwendet laut Konfiguration die Kanaldatei von B, das aber wiederrum die von C verwendet), was das Ganze zwar etwas komplizierter macht, aber keine wirklich neue Komplexität mit sich bringt.

Fall A: Ein Geräteprofil in VCR.NET hat eine eigene Kanaldatei. Auf diesem Profil kann VCR.NET einen Sendersuchlauf durchführen und es werden auch EPG Sammlung durchgeführt sowie die EPG Daten bereitgestellt.

Fall B: Ein Geräteprofil in VCR.NET verwendet die Kanaldatei eines anderen Geräteprofils, dass auch in VCR.NET angeboten wird. Auf dem Profil werden keinerlei Suchläufe angeboten, sondern vielmehr die Daten des Geräteprofils mit der Kanaldatei verwendet.

Fall C: Wie B, allerdings ist das Geräteprofil mit der Kanaldatei nicht in VCR.NET aktiviert. In diesem Fall führt VCR.NET keinen Sendersuchlauf durch – das würde die Spielregeln von DVB.NET Geräteprofilen verletzen. Im Gegensatz dazu wird eine EPG Sammlung durchgeführt.

Von den anderen lustigen Fällen einer mal durchgespielt: VCR.NET unterstützt Profile A und B. A hat einen Kanaldatei und wird von C referenziert, wobei VCR.NET Profil C nicht anbietet. B wiederum referenziert C und damit indirekt A. Was passiert nun in VCR.NET?
Geräteprofil A: Sendersuchlauf und EPG Sammlung werden durchgeführt.
Geräteprofil B: Verwendet die Ergebnisse von A, als gäbe es C nicht. Es werden für B keine eigenen Daten verwaltet.