Archiv für den Monat: Januar 2009

Bedingt durch seine Historie verbinden bisherige DVB.NET Versionen einen Verbraucher eines Teildatenstroms (Bild, Ton, Steuerdaten, Videotext, … – eindeutig spezifiziert durch eine Datenstromkennung PID) immer direkt mit den von den Hardwareabstraktionen angebotenen Filtern. Das hat einige eigenartige Effekte und ich möchte hier einen Aspekt kurz erläutern: außerhalb des halbstündigen Regionalfensters empfängt man auf WDR Bonn identisch das gleiche wie auf WDR Aachen. Technisch ist das so realisiert, dass beide Sender identische PID Kennungen für Bild und Ton melden. Wenn man in DVB.NET nun eine Aufzeichnung auf WDR Bonn starten würde, so wird ganz normal das gewünschte Ergebnis erzeugt. Wenn dann allerdings gleichzeitig eine Aufzeichnung auf WDR Aachen aktiviert wird, werden die notwendigen PID Kennungen neu angemeldet. Mit dem Effekt, dass die Bonn Aufzeichnung keine neuen Daten mehr erhält, sondern nur noch die Aachener. Noch häßlicher wird es, wenn man Bonn dann stoppt: nun werden die Filter abgemeldet und Aachen bekommt keine Daten mehr.

Sehr unbefriedigend! DVB.NET wird ab Version 3.9 die Konzepte strikt trennen. Es können pro Datenstromkennung (PID) beliebig viele Verbraucher angemeldet sein, die alle individiuell aktiviert oder deaktiviert werden können. Ein Filter der Hardwareabstraktion wird aktiviert, sobald mindestens ein Verbraucher aktiv ist. Er wird deaktiviert, wenn der letzte aktive Verbraucher deaktiviert oder abgemeldet wird (oder die Quellgruppe (früher Transponder genannt) gewechselt wird).

Mag sich wie ein Detail anhören, ist aber im Hinblick auf einige Probleme in der Vergangenheit ein wichtiger Schritt.

Bis bald

Jochen

Beginnend mit DVB.NET 3.9 verfolge ich ein etwas anderes Konzept, was das Laden der Bibliotheken angeht. Mehr oder weniger historisch bedingt durch die Notwendigkeit, die properitäre Treiberdatei (DLL) der Hauppauge Nexus im selben Verzeichnis zu haben wie die Anwendung [ja, da gibt es durchaus Alternativen, aber alle haben ihren eigenen kleinen Haken], die sie benutzt, brachte jede DVB.NET Anwendung letztlich die gesamte Bibliothek mit sich – siehe VCR.NET. Scheint es erst mal von Vorteil zu sein (DVB.NET und VCR.NET werden unabhängig voneinander installiert), kann es doch auch lästig sein (der Viewer MUSS in das DVB.NET Installationsverzeichnis, Fixes für DVB.NET MÜSSEN auch immer im VCR.NET eingespielt werden und so weiter).

Da ich es auch für bedenklich halte, DVB.NET Bibliotheken (Assemblies) mit teilweise sehr direktem Zugriff aus .NET heraus auf das Betriebssystem blind in das .NET GAC (Global Assembly Cache) zu installieren. habe ich folgende Lösung gewählt:

• DVB.NET installiert ab 3.9 eine einzige Bibliothek in den GAC
• Zukünftige Versionen werden diese nicht einfach ersetzen, sondern separate Varianten einstellen – DVB.NET Versionen sollen weiterhin parallel betrieben werden können
• Zusätzlich wird für jede Version ab 3.9 separat in der Registry vermerkt, wohin DVB.NET installiert wurde
• Jede DVB.NET Anwendung referenziert diese eine Bibliothek und initialisiert sie geeignet (sehr einfach gehalten)
• Werden DVB.NET Bibliotheken benötigt, so werden diese automatisch dem RunTime Unterverzeichnis des Installationsverzeichnisses entnommen
• Für propertitäre Treiber wird ein ähnlicher Mechanismus (Stichwort: SetDllDirectory) und das Unterverzeichnis Driver verwendet
• Ein grundsätzlicher Erweiterungsmechanismus kann von Anwendungen wie dem Administrationswerkzeug verwendet werden (hier das Unterverzeichnis Administration PlugIns)

Insgesamt enthält das Installationsverzeichnis von DVB.NET im Wesentlichen nur noch Anwendungen. Eine auf DVB.NET basierte selbst erstelle Anwendung muss eigentlich nur noch die eigenen Dateien kopieren und hat volle DVB.NET Unterstützung – inklusive eines vereinfachten Aktualisierungsmechanismus.

Ich hoffe, dadurch etwas Übersichtlichkeit in die Installation des DVB.NET Kerns und abhängiger Anwendungen zu bringen.

Wir werden sehen…

Jochen

Die nächste DVB.NET Version wird mehrere Schichten zum Zugriff auf DVB Hardware anbieten. Erst einmal unangetastet bleiben die DVB.NET 3.5 (und früher) Hardwareabstraktionen, wobei es aber sehr schwer sein wird, diese weiterhin direkt zu verwenden (mit Absicht). Tatsächlich zeigt es sich nun nach einiger Entwicklungszeit, dass dieser Kern so ziemlich das einzige ist, was in die neue Version unverändert eingeht.

Dazu ein kleiner Einschub: Anders als ursprünglich geplant gibt es sehr viel Neues in DVB.NET, so dass ich mich entschieden habe, die nächste Version 3.9 (aka Fast-4.0) zu taufen. Für die viele Arbeit und die realisierten Konzepte ist 3.5.1 einfach zu schwach und alles dazwischen wäre nur gemogelt. Es geht auf die 4.0 zu – das wäre meine Botschaft!

Doch zurück zum Thema. Für jemanden, der eigene DVB Software auf Basis von DVB.NET entwickeln möchte, ist der Zugriff über die (neuen) Geräteprofile der vorgeschlagene Ansatz. In meinem Fall wird das etwa der DVB.NET / VCR.NET Viewer sein, der (auch) direkt auf die lokale DVB Hardware zugreifen soll. Damit man sich nicht mit unnötigem Balast abplagt wird es hierzu eine Basisinstallation DVB.NET Library geben, die im wesentlichen die Bibliotheken enthält – und einen minimalen Satz von Werkzeugen etwa für die Pflege von Profilen oder den Sendersuchlauf. Eine separate Installation DVB.NET Tools wird einige zusätzliche Anwendungen zum Testen und Spielen mit der Bibliothek enthalten.

Neu ist die Installation DVB.NET Server, die den so genannten DVB.NET Card Server enthält. Dieser wird eine wesentliche Grundlage für VCR.NET 3.9 (oder andere Aufzeichnungsdienste wie für 4TheRecord locker geplant) bieten. Hier geht es nicht um den elementaren Zugriff auf die DVB Hardware, wie ihn die Geräteprofile bieten. Vielmehr bietet ein Card Server Funktionen wie die folgenden an:

• Aufzeichnen mehrerer Sender gleichzeitig in unterschiedliche Dateien mit optionalem Netzwerkversand
• Aktualisieren der Programmzeitschrift
• Durchführen eines Sendersuchlaufs
• …

Insgesamt werden sehr wenige, komplexe Funktionen angeboten.

Den Card Server wird es in zwei Varianten mit identischer Schnittselle geben. Im Normalbetrieb wird für jedes aktive DVB Gerät ein eigener Prozess gestartet. Damit wird die höchste Stabilität erreicht und vor allem vermieden, dass sich etwa unterschiedliche BDA Treiben in einer Anwendung stören. VCR.NET nutzt diese Möglichkeit schon seit Jahren erfolgreich. Alternativ kann der Card Server aber auch in eine Anwendung geladen und dort direkt angesteuert werden. Die Installation enthält zum Spielen ein kleines Testprogramm, mit dem sich die wichtigsten Funktionalitäten des Card Servers in beiden Varianten erschliessen lassen.

Bis später

Jochen