Suchmuster in Dateinamen

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.

muster.jpg

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:

config0.jpg

Erste Gehversuche mit neuem Kern

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.


adminroles.jpg

DVB.NET 3.0 RC1

Ich würde gerne noch dieses Jahr VCR.NET 3.0 fertig machen und habe mich daher entschlossen, DVB.NET 3.0 erst einmal zu zu machen. Das heißt, es wird wohl keine neuen Features mehr geben (etwa Nutzung des Favoriten Managers im Quick Record Standard) und Updates bis zum Final werden nur noch Dinge enthalten, die VCR.NET 3.0 braucht (und eine aktualisierte Dokumentation, da graut es mir schon vor – kostet bestimmt wieder einen vollen Tag – so spartanisch die DVB.NET Homepage auch ist).

Der Download erfolgt über das Forum, da stehen auch die Zugangsdaten. Da es mit VCR.NET etwas Probleme bei der Installation unter Vista gab (ganz ehrlich: man kann es nun installieren, aber es läuft nicht), werde ich ab jetzt nicht mehr nur die MSI, sondern ein ZIP mit MSI und zugehöriger Setup.EXE bereitstellen.

Nachdem ich gestern drei Stunden durch einen Blue Screen und ein CheckDisk verloren habe (370 GB dauert halt, aber immerhin habe ich mein GB private Daten inklusive VCR.NET / DVB.NET Sourcen wieder – war ein ganz schöner Schreck in der Abendstunde, vor allem, da mein letztes Backup eine (Sourcen) respektive drei (Mails et al) Wochen alt war), versuche ich nun die mir zur Verfügung stehende Zeit konsequent für VCR.NET zu nutzen (DVB.NET Profile, Thin Client, viele kleine Features und einige Fixes). Mal sehen…

Verzwickte Zusammenhänge

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.

Kurze Unterbrechnung – kleines Tool

Vor ein paar Wochen wurde meine alte Sat Anlage erweitert. Zusätzlich zu 19°E empfange ich nun auch 28°E – insbesondere die englischen Sender. Bedingt durch einige technische Probleme ist die Anlage im Moment leider noch ziemlich verstellt, so dass ich erträglich Empfang eigentlich nur mit der neuen TechnoTrend S2-3200 ob ihres guten Tuners habe – das auch nicht immer fehlerfrei und praktisch ohne Schlechtwetterreserve. Ich hoffe, dass sich das noch vor dem Winter bessert.

Wie dem auch sei: aus Schlechtem auch was Gutes machen. Ich habe mir mal ein kleines DVB.NET Tool (geht nur mit der neusten, noch nicht offiziellen 3.0 Beta – die mit den Geräteprofilen) gebastelt, das Signalstärken protokolliert – allerdings nur mit einer Nexus-S, aber was soll’s. Dabei werden alle Transponder, auf denen gemäß Kanaldatei etwas empfangen wird, zufällig abgesucht und die Signalstärke separat pro LNB dargestellt. Das sieht bei mir (leider) etwa so aus.

signalrecorder.jpg

Links 19°E, rechts 28°E. Die vertikale Linie ist die High/Low Umschaltfrequenz (11.7), die horizontalen Linien sind bei 80%, 90% und 95% der Signalstärke. Dazu ist zu bemerken, dass die alte Anlage durchgängig bei über 97% war und das, obwohl sie gegenüber der Installation vor 5-6 Jahren schon nachgelassen hatte. Frequenzen gehen von links nach rechts, grüne Punkte zeigen eine horizontale Polarisation, gelbe eine vertikale. Da ich QuadLNBs mit dedizierten Zuordnungen (High/Low) x (H/V) habe, könnte man so unter Umständen auch auf defekte Leitungen schliessen. Scheint aber nicht der Fall zu sein.

Über die Interpretation des Bildes denke ich später mal nach – jetzt bin ich zu müde.