.NET 3.5 SP1 und ASP.NET Run-Time Hosting

VCR.NET ist ein Windows Dienst, der sich als ASP.NET Web Server präsentiert. Kern dazu ist eine Implementierung der HttpWorkerRequest Basisklasse. Die ursprüngliche Realisierung beschränkte sich auf das Notwendigste, i.e. die Methoden, die im Betrieb auch tatsächlich aufgerufen wurden. Seit SP1 von .NET 3.5 wird nun leider auch die Methode void SendResponseFromFile( string filename, long offset, long length ) für statische Inhalte verwendet (Bilder, HTML, CSS, …), was im konkreten Fall von VCR.NET dazu führte, dass die Anwendung zwar noch lief, aber sehr komisch aussah.

Glücklicherweise ist zumindest eine dumme Implementierung der Methode recht trivial, aber man muss es halt erst einmal tun. Wer also auch ASP.NET Run-Time Hosting betreibt und sich auf eine Minimalimplementierung stützt: lieber mal reinschauen, bevor es eine optisch unschöne Überraschung gibt.

Viel Spaß

Jochen

DVB.NET 3.5 und DVB-S2

Ich habe mir gerade eine Hauppauge Nova-HD-S2 eingebaut und festgestellt, dass die Senderliste von DVB.NET 3.5 für eine Unterstützung von DVB-S2 unzureichend ist. DVB.NET 3.5 weiß von einem Transponder zwar, dass es sich um einen DVB-S2 Transponder handelt, kennt aber weder Modulationsverfahren noch RollOff oder Pilot Parameter. Im Gegensatz zur TechnoTrend S2-3200 benötigt die Nova-HD-S2 diese Informationen aber zum Teil. Da gibt es auch keinen Work-Around, sondern nur ein weiteres Tüpfelchen für die Senderverwaltung von DVB.NET 4.0 (tatsächlich hatte ich das schon berücksichtigt, ohne die Details zu kennen).

Ausserdem ist die Nova pingeliger, was die Angabe der Fehlerkorrektur angeht. In DVB.NET 3.5 hat sich bezüglich des neuen Arte HD Transponders ein Fehler eingeschlichen: die FEC ist mit 3/4 vermerkt, korrekt ist aber 2/3. Glücklicherweise läßt sich das manuell für DVB.NET und VCR.NET korrigieren.

Immerhin: mit etwas Tricks erscheint nun Arte HD auch mit der Nova.

So long

Jochen

Was ist ein Sender?

Ok, erst mal eine selten dämliche Frage. Etwas präziser gefragt: was bedeutet es denn, eine Ausstrahlung eines Sender aufzuzeichnen? Am Anfang meiner Beschäftigung mit dem digitalen Empfang schien mir die Antwort trivial: Bild und Ton, what else? Tatsächlich ist es aber etwas komplizierter, da eine Ausstrahlung halt nicht nur aus einem Bild und einem Tonsignal besteht. Da sind erst mal alternative Tonspuren in anderen Sprachen (englisch, französisch, …) und / oder anderen Formaten (Dolby Digital, Zweikanal, …). Zumindest jetzt schon sind auch Videotext (und sei es nur zur Extraktion von Untertiteln) und DVB Untertitel ein Thema – letztere unter Umständen wieder mit verschiedenen Varianten verfügbar. Dazu kommen auch noch Informationen, die im Sinne der Spezifikation zwar nicht zur Ausstrahlung gehören, diese aber sinnvoll ergänzen können, wie etwa die elekronische Programmzeitschrift (EPG) und da vor allem die Daten zur Ausstrahlung selbst.

Also ist ein Sender die Summe aller dieser Teile und eine Aufzeichnung sollte all dies enthalten? Theroetisch ja, aber praktisch kann es gute Gründe geben, auf die Aufzeichnung aller Teile zu verzichten. In seltenen Fällen beschränkt die Hardware die Aufzeichnung aller Teile, wie etwa bei der TechnoTrend Premium Line (Hauppauge Nexus, … ): diese Karten können maximal 8 Teile gleichzeitig aufzeichnen, so dass etwa heute eine Aufzeichnung der Euronews mit acht Tonspuren zum Bild unmöglich ist. Aber auch rein pragmatische Gründe können einen dazu bewegen, auf Teile bewußt zu verzichten. Ich bin etwa zu faul, für jede Aufzeichnung ProjectX individuell zu konfigurieren. Wenn ich etwa eine Aufzeichnung mit VideoText habe, so versucht die gemeinsame Einstellung Untertitel auf den wichtigsten Seiten (149, 150, 777, 888) zu finden – und das dauert. Weiß ich, dass ich eine Aufzeichnung von einerm Sender mache, der eh keine Untertitel anbietet (Sat1, die RTL Gruppe, …), so verzichte ich einfach bewußt darauf, diesen Teil in die Aufzeichnung zu integrieren. Bei alternativen Tonspuren ist es ähnlich – wann hat das ZDF mal wirklich Dolby Surround oder einen Begleittext auf den zusätzlichen Tonspuren?

In DVB.NET und VCR.NET werden aus historischen Gründen Senderlisten gepflegt, in dem zu jedem Sender mitgeführt wird, welche Teile wie (über welche Datenstromkennung) aus dem digitalen Sendestrom extrahiert werden können. Dieser Ansatz ist schon länger nicht mehr zeitgemäß: einige Sender ändern diese Konfiguration voll dynamisch (PREMIERE grundsätzlich für Tonspuren, einige dritte Programme der ARD etwa bezüglich der Dolby Digital Spur), in festen Zeitfenstern (für die Regionalprogramm der ARD, so hat etwa WDR Bonn Abends eine halbe Stunde individuelles Programm) oder nach Lust und Laune (ITV häufig, BBC ab und zu, ARD und die ProSieben Gruppe im großen Stil Anfang 2008). Kurz gesagt: eigentlich ist ein Großteil der Senderliste unnötig und bei einer Aufzeichnung sollte dynamisch entschieden werden, welche Teile aufgenommen werden soll.

Auch dieser Ansatz hat durchaus einige Nachteile. Für meine Software konnte man bisher sagen, welche Teile integriert werden sollten und welche nicht. Da man nicht mehr weiß, was denn nun wirklich drin sein wird, beschränkt sich das auf Aussagen wie ‘aber auf keinen Fall mit VideoText für Sat.1’ – nicht wirklich eine schmerzhafte Änderung. Kritisch sind aber nun Aufzeichnungen über Karten mit technischen Beschränkungen wie der PremiumLine, da das Erreichen des Grenzwertes erst mit Beginn der Laufzeit kritisch wird – das Planen von Aufzeichnungen wird schwieriger (insbesondere, wenn man mehrere Sender gleichzeitig aufzeichnen möchte) und es kann zu unerwünschten Ergebnissen kommen (warum fehlt denn nun gerade die deutsche Tonspur und ähnliches).

Dazu kommt, dass sich die Konfiguration der Teile ja auch dynamische verändern kann. Nimmt man etwa das regionale Zeitfenster von WDR Bonn mit etwas Vorlauf auf, so ist die Konfigurationsveränderung in der Aufzeichnung. Bei Weiterführung in eine Aufzeichnungsdatei würde es nun dazu kommen, dass die Zeitbasis von Bild und Ton einen Sprung machen. Das alleine wäre noch unkritisch, da Nachbearbeitungsprogramme wie ProjectX damit im Allgemeinen klarkommen – vielleicht fehlen einige Bilder an der Sprungstelle selbst. Weniger großzügig wird allerdings damit umgegangen, wenn Teile nachträglich hinzukommen: oft wird nur die ursprüngliche Konfiguration berücksichtigt. Also bei PREMIERE könnte dann schon mal die englische Tonspur nur mit Mühe nutzbar sein, man müßte manuell die Stelle finden, an der die gewünschte Konfiguration vorliegt und erst dahinter mit dem Schnitt / der Analyse beginnen. Ähnliches für eine Aufzeichnung von KiKa mit VideoText, wenn man die erste Ausstrahlung des Tages nach der Sendepause haben möchte.

Eine Alternative, die VCR.NET geht, ist es, bei jedem Konfigurationswechsel eine neue Datei zu beginnen. Nun wird aus der einfachen Aufzeichnung eines Senders aber eine ganze Reihe von Einzeldateien: auch nicht sehr schön und von der Verwendung her oft eher lästig – aber hey, bei WDR Bonn hat mein Regionalfenster einer eigene Datei, cool, aber eher Bug als Feature. Und wehe, wenn die Sendeanstalt die Konfiguration fehlerhaft wechselt, etwa zu spät: eigentlich ist die englische Tonspur da, sie wird aber nicht aufgezeichnet, weil keine Zuordnung besteht (das gilt natürlich allgemein, nicht nur bei der Dateitrennung durch VCR.NET) – da ist dann auch nichts mehr zu retten.

Die Aufzeichnung ganzer Transponder (Sendergruppen) scheint eine Alternative zu sein, erzeugt aber riesige Dateien (grob 14 GB pro Stunde) und macht die Nachbearbeitung eher mühsam.

Was ist also ein Sender? Erst einmal nur eine eindeutige Bezeichnung, die dessen Quelle beschreibt. Dazu gibt es in DVB das Tripel (Netzwerkkennung, Datenstromkennung, Dienstekennung), das etwa für das ZDF identisch ist, egal ob der Empfang direkt über Satellit oder einen Kabelanschluss erfolgt. Wenn ich also einen Sender aufzeichnen möchte, verwende ich einfach die eindeutige Bezeichnung und die dynamische Konfiguration (in der Hoffnung, dass die Sendeanstalt nicht mogelt).

Was gehört also in die Senderliste? Nun, das ist etwas schwieriger, denn der Anwender möchte sicher nicht die eindeutige Bezeichnung auswählen. Also ein eindeutiger Sendername muss schon her. Trivial, oder? Nicht wirklich, Sender wie ARTE gibt es etwa zweimal, wobei hier die Unterscheidung über die Schreibweise (einmal groß, einmal klein) oder den Dienstanbieter (einmal CANALSATELLITE, einmal ARD) möglich ist. Aber kurzzeitig während der Umstellung gab es unter anderem WDR5 des Anbieters ARD zweimal, da hilft nun gar nichts mehr. Ähnlich bei Astra 2, wo es fast nur den Anbieter BSkyB gibt und viele Namen doppelt vorkommen.

Und noch einen darauf gesetzt: hat man eine Software wie VCR.NET, mit der man Aufzeichnungen plant, und setzt mehr als eine DVB Hardware ein, so kann man eigentlich erwarten, dass eine automatische Verteilung der Aufzeichnungsaufräge an die Hardware stattfindet (VCR.NET macht das nicht!). Neben manuellen Wünschen (für wichtige Aufzeichnungen lieber mal DVB-S statt DVB-T nehmen, da die Qualität deutlich besser ist) gibt es auch harte Bedingungen, die bereits in der Senderliste verankert werden sollten. Hat etwa nur eine Hardware die Möglichkeit, über ein Common Interface (CI) eine PayTV Aufzeichnung zu entschlüsseln, so kann eine verschlüsselte Aufzeichnung auch nur von dieser ausgeführt werden. Daher sollte bei der Planung schon bekannt sein, dass eine Entschlüsselung notwendig ist – sonst kann es bei Beginn der Aufzeichnung zu einer bösen Überraschung kommen, wenn die einzig fähige Hardware gerade mit irgendetwas Unwichtigem beschäftigt ist. Also gehört in die Senderliste zumindest noch die Information, ob eine Sender verschlüsselt sendet oder nicht. Und wenn sich auch das dynamisch ändert…

Genug für heute (wer Tippfehler findet, darf sie behalten). Fazit für DVB.NET 4.0: Senderlisten werden ganz anders aussehen, Aufzeichnungen werden sich bevorzugt an der dynamischen Konfiguration orientieren.

Viel Spaß

Jochen

DVB.NET 4.0 and beyond

Inzwischen gibt es doch eine ganze Reihe kleiner und großer Dinge, die in DVB.NET nur unzureichend umgesetzt sind.

Einiges davon kommt sicher daher, dass DVB.NET ursprünglich für das properitäre SDK der TechnoTrend Premium Line entwickelt wurde und vor allem die BDA Abstraktion erst nachträglich da hinein gefummelt wurde – umgekehrt werde es sicher sinniger. Zudem wurden einige Konzepte der Senderverwaltung aus der Originalanwendung übernommen, die so einfach nicht (mehr) passend sind.

Dazu kommt sicher auch, dass ich sowohl im Bereich digitaler Empfang / DVB ein völliger Laie war und es sich bei DVB.NET um mein erstes größeres C# / .NET Projekt handelte. Ein bisschen was lernt man so im Laufe der Jahre doch dazu, so dass ich denke, dass man hier so einiges verbessern könnte.

Ich bin daher der Ansicht, dass mit der Version 3.5 ein guter Punkt erreicht ist, um einen Schnitt zu machen. Ich plane locker, für DVB.NET 4.0 ganz neu zu beginnen und nur die Erfahrungen der vergangenen Versionen zu nutzen – inwieweit auch Programmcode seinen Weg unverändert in die neue Version findet, wird sich im Einzelfall zeigen.

Auch für den VCR.NET Recording Service könnte die Version 4.0 einen Einschnitt bedeuten. Da sind meine Überlegungen noch ganz am Anfang, aber eine Option könnte es sein, dass es von mir nur eine Art DVB.NET Card Service gibt, der die Hardware bedient, Netzwerkstreaming ermöglicht und so weiter. Das eigentliche Planen der Aufzeichnungen könnte dann etwa durch For The Record erfolgen, das mit dem Card Service über einen Provider verbunden wird.

Ich werde versuchen, nach und nach ein bißchen von meinen Überlegungen und den ersten Schritten zu berichten. Für den Moment gilt noch: es wird nichts so heiß gegessen, wie es gekocht wird!

Bis bald

Jochen

Freud und Leid von Third Party Entwicklern

Als ich mir Anfang 2003 die Hauppauge Nexus zulegte und weder mit der Originalsoftware noch mit der damaligen Version der Watch TV Pro Phoenix auch nur annäherend das erreichte, was ich wollte (aufzeichnen), habe ich mich drangemacht, eine eigene Software zu machen (nun bekannt als VCR.NET Recording Service). Dazu konnte man sich damals bei TechnoTrend als Entwickler anmelden und nach Unterzeichnung einer Geheimhaltungsvereinbarung (NDA) bekam man eine Menge an Informationen. Leider wenig Dokumentation, aber ansonsten inklusive von Beispielen alles, was man brauchte, um die Nexus besser nutzen zu können, als die Programme, die mir sonst noch so zur Verfügung standen.

Die Nexus hat eine properitäre Schnittstelle, die mit nichts anderem zu vergleichen ist. Inzwischen wird für den Zugriff auf DVB Hardware fast ausschließlich der de facto Standard BDA von Microsoft verwendet. Leider umschließt dieser nicht alle notwendigen Aspekte des DVB Empfangs und es fehlen DVB-C, PayTV via CI/CAM, DiSEqC, DVB-S2 und vermutlich Dinge, die ich noch nicht gebraucht habe. Um eine Karte vollständig zu unterstützten, heißt es wieder Klinkenputzen (i.e. Hersteller anschreiben). Dazu ein kurzer Bericht meiner Erfahrungen (es kann natürlich sein, dass kommerzielle Entwicklungen da besser dran sind).

TechnoTrend liefert weiterhin sehr detaillierte Informationen, aber ohne wirkliche Dokumentation. An den Beispielen kann man zwar grob sehen, wie etwas gehen soll, aber dann und wann liegt der Teufel doch im Detail. Der Kontakt zu TechnoTrend ist sehr freundlich, aber leider muss man immer wieder aktiv nach aktuellen Versionen fragen – trotz Registrierung und per FAX bestätigtem NDA. Eine Reaktion gibt es höchstens auf 1 von 3 Anfragen und ab und an gibt es auch mal kommentarlos eine uralte Version. Aber innerhin: mit etwas Ausdauer bekommt man dann doch eine Menge. Negativ zu bemerken ist, dass einige Mechanismen wohl aus historischen Gründen noch sehr properitär sind und sich nicht den normalen Erweiterungsmechanismen von BDA anpassen. Schade eigentliche – die anderen können doch auch IKsPropertySet benutzen.

Bei Hauppauge ist es mir bei meiner ersten Anfrage gleich gelungen, die benötigten Informationen zu erhalten. Diese waren extrem knapp aber absolut ausreichend und der Anfrage angemessen. Danach gab es nie wieder eine Reaktion auf spätere Anfragen. Schade um den netten Kontakt.

Im Moment am positivsten zu bewerten ist Digital EveryWhere (FireDTV), die mir konkret zur Anfrage eine professionelle Dokumentation zugesendet haben (ok, über ein paar kleinere Copy&Paste Fehler der umfangreichen Beispielen sehen wir mal weg) und sogar noch sehr nett nachgefragt haben, ob ich mehr brauche. Zudem ist die Lösung sehr eng an BDA gekoppelt und ich kann nur sagen: weiter so!

Ein bißchen unglücklich bin ich noch mit meinem KNC Kontakt, der erst gut anlief. Aber nach einer Beta Version der aktuellen BDA Treiber tat sich dann auch auf Rückfrage hin nichts mehr. Schade!

Mal schauen, wie das so weiter geht.

Bis denn

Jochen