Kleine Rückschläge erhöhen die Spannung, oder?

Leider mußte ich mal wieder etwas in die Basis einsteigen. Ich nutze meine TechnoTrend S2-3200 seit einigen Monaten produktiv im VCR.NET. Einige (wenige, aber egal) Aufzeichnungen waren dabei ohne erkennbaren Grund völlig geschrottet. Das sah dann so aus, dass eine Weile fehlerfrei aufgezeichnet wurde und danach ein Bildblock (keine anderen Datenströme) von ca. 6 kB immer wieder wiederholt wird. Natürlich vermute ich, dass der Fehler sich irgendwo im DVB.NET versteckt, ich komme aber einfach nich dahinter, wo das sein könnte. Zudem der größte freie Puffer in der TS Generierung weniger als 200 Bytes groß ist und alle anderen Puffer in Einheiten von TS Paketen (184 Bytes) verwaltet werden. Und die sich wiederholenden Daten sind kein Vielfaches davon (genau 35 x 184 – 8 Bytes).

Da ich kein CI habe dachte ich mir, es kann ja nicht schaden, wenn ich auf die BDA Treiber umsteige (DiSEqC geht ja inzwischen). Aber auch da einige böse Überraschungen. Dass KiKa / ZDF Aufnahmen Fehler haben kann noch an meiner mangelhaft ausgerichteten Schlüssel liegen (die Nexus zeigt maximal 5dB auf dem ZDF Transponder, am Anfang vor einigen Jahren war ich mal auf 10dB oder so) – gestern war hier ziemliches Mistwetter. Aber was wirklich ärgerlich ist, ist der Sendersuchlauf. Zum einen werden nicht alle Sender gefunden (zuerst fehlten die DVB-S2 Sender, dann RTL, dann ZDF usw.), ohne dass ich auch nur eine Idee habe, wie das sein kann. Dann hängt sich der Suchlauf auch fast immer irgendwo auf (nun gut: die Transponderliste von EuroBird und Astra 2ABD enthält sehr viele Einträge, auf denen nichts gesendet wird, kann sein, dass die Karte da durcheinander kommt – aber warum geht es einwandfrei mit den konventionellen WDM Treibern).

Echt der Frust. Bevor ich VCR.NET weiter machen kann, muss ich mir den BDA Teil vom DVB.NET genauer anschauen – bei anderen Anwendung fluppt es ja auch, muss irgendwie an mir liegen. Ich habe die neuesten Treiber von TechnoTrend genommen, evt. ist da auch noch was zu tun. Nur: grundsätzlich läuft es halt…

Nun gut, soweit zum Status VCR.NET 3.0.

Viel Spaß

Jochen

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.