VCR.NET 3.9 Verluste: Das Kreuz mit der Nexus

Dies ist der erste Artikel zum aktuellen Entwicklungsstand der nächsten Version 3.9 des VCR.NET Recording Service. Er wird vollständig auf den neuen Philosophien von DVB.NET 3.9 basieren und sowohl zu DVB.NET 3.9 / 4.0 als auch den veränderten Konzepten habe ich ja schon einiges beschrieben. Aus Platzgründen verzichte ich daher bei den VCR.NET 3.9 Artikeln darauf, alle Ideen und Vorstellung noch einmal zu erläutern. Allerdings haben einige der Veränderungen durchaus Auswirkungen auf den Betrieb von VCR.NET.

VCR.NET 3.9 wird in den Sendertabellen keine Detailinformationen zu den einzelnen Quellen mehr vermerken, etwa welche Tonspuren zum Zeitpunkt des letzten Sendersuchlauf präsent waren. Diese Informationen verändern sich bei einigen Sendern teilweise von Sendung zu Sendung (etwa Dolby Digital oder DVB Untertitel), so dass ein Eintrag in die Sendertabelle mehr ein Hinweis denn eine nützliche Information wäre. Die altbekannten Einstellungen ‚alle Sprachen‘, ‚Dolby Digital‘, ‚Videotext‘ und ‚DVB Untertitel‘ verstehen sich nun als Wünsche der Art: wenn die entsprechende Datenspur angeboten werden sollte, dann zeichne sie bitte mit auf.

Die meiste verfügbare DVB Hardware hat keine Einschränkung bezüglich der Anzahl der Datenströme, die gleichzeitig aufgezeichnet werden können. Den Wünschen kann daher in allen Fällen entsprochen werden. Die einzige Veränderung gegenüber früher ist, dass VCR.NET Änderungen an der Senderkonfiguration erkennt (Tonspuren werden hinzugeschaltet) und in diesen Fällen eine neue Aufzeichnungsdatei beginnt – wie bereits in der aktuellen Version etwa für die Lokalfenster vom WDR. Es muss sich zeigen, ob dieser Ansatz vernünftig ist – was, wenn ein Sender etwa mitten im Film eine Tonspur zuschaltet? Der Bruch der Dateien bedeutet dann ziemlich sicher auch einen Datenverlust.

Ganz anders sieht es aber bei Hardware aus, die von Natur aus nur eine begrenzte Anzahl von Datenströmen aufzeichnen kann. Insbesondere geht es hier um die Hauppauge Nexus / TechnoTrend Premium Line, für die DVB.NET und VCR.NET vor jetzt fast 6 Jahren einmal entwicklet wurden.

Bevor wir zu dem beschriebenen Effekt kommen, erst einmal etwas zu einem anderen Aspekt, der aber auf die selbe Art behandelt wird: den so genannten Mehrkanalaufzeichnungen. Hierbei werden mehrere Sender von einer Quellgruppe (früher Transponder genannt) gleichzeitig aufgezeichnet. Mit der Beschränkung der Nexus auf 8 Datenströme könnten somit etwa maximal vier Fernsehsender ohne Goodies (alternative Sprachen, …) gleichzeitg aufgezeichnet werden. Das Problem für VCR.NET ist nun die Planung der Aufzeichnungen und die Berücksichtigung dieser Beschränkungen: früher wurde auf Basis der scheinbar vollständigen Daten in der Senderliste geplant, also wenn ich nun einen Radiosender aufzeichne, der mit einer Stereo- und einer Dolbytonspur eingetragen ist, so wurden dafür zwei Datenströme reserviert, wenn der Wunsch ‚Dolby Digital‘ aktiviert wurde. Die Aufzeichnung versuchte dann auch stur nach der Senderliste die Datenspuren aufzuzeichnen – egal ob mit Daten beschickt oder nicht. Das konnte die Synchronisation der Aufzeichnungsdateien ganz schön durcheinanderbringen.

VCR.NET 3.9 plant nun ausschließlich auf folgender Basis: ein Fernsehsender benötigt mindestens zwei, ein Radiosender mindestens einen Datenstrom. Bei der Planung können so vielen Sender gleichzeitig aufgezeichnet werden, wie diese Minimalsumme kleiner als 8 ist. Beim Starten der Aufzeichnung prüft VCR.NET (genauer: der verwendete DVB.NET Card Server), ob die tatsächliche aktuelle Konfiguration der Sender die Berücksichtigung aller Wünsche erlaubt. Ist das nicht der Fall, so werden die Wünsche nach einer internen Priorisierung verworfen – zuerst DVB Untertitel, etc. Würde man etwa ZDF und 3Sat parallel aufzeichnen wollen und alle Wünsche aktivieren (Bild und Standardton sowie alternative Sprachen (Zweikanal), Dolby Digital, Videotext und DVB Untertitel – das macht 6 Datenströme pro Sender), so wird VCR.NET jedem Sender 4 Datenströme zuteilen und in der aktuellen Implementierung die DVB Untertitel und Dolby Digital weglassen. Es wird sich zeigen, in welcher Form dieser Mechanismus dann in 4.0 landen wird – vorstellen kann man sich vieles an individueller Konfiguration. Für mich muss ich einfach den Aufwand gegen den Nutzen betrachten – wie oft gibt es durch den vorhandenen Algorithmus eine Situation, die vorher nicht erkannt wird und zu einem unbefriedigenden Aufzeichnungsergebnis führt? Ausdenken kann man sich vieles, es zählt nur die Realität.

Mit dem Ändern der Senderdaten ist es im Prinzip genau so. Wenn eine Änderung erkannt wird, stoppt VCR.NET die Aufzeichnung erst einmal. Danach wird auf Basis der ursprünglichen Wünsche eine neue Aufzeichnungskonfiguration ermittelt, die gemäß den noch verfügbaren Datenströmen ausgeführt werden kann und die Aufzeichnung darauf basierend neu gestartet. Wenn aus einem Radiosender nicht plötzlich ein Fernsehsender wird ist sichergestellt, dass zumindest die Minimalanforderung einmal Ton plus Bild (für Fernsehsender) erfüllt werden kann und die Aufzeichnung weiter geht. Lustiger wird das natürlich, wenn bei einer Mehrkanalaufzeichnung mehrere Sender mehrfach ihre Daten ändern – das ist aber eher selten. Tasächlich existent ist aber das Problem, dass einige Sender Datenströme gemeinsam nutzen – etwa die WDR Regionalsender den Videotext in den Regionalfenstern. In extremen Fällen kann es hier zu einer Fehlplanung kommen, ich denke aber, dass ich alle nicht manipulierten normalen Situationen im Griff habe.

Lange Rede kurzer Sinn: hat man eine Nexus, so sind ab sofort die Zusatzeinstellungen als Wünsche zu betrachten. Bei Mehrkanalaufzeichnungen oder der Aufzeichnung extremer Sender (Euronews mit Bild und 8 Tonspuren) muss man im Laufe der Zeit ein gewissen Gefühl für Problemsituationen entwickeln. So ist es leider – ich bin auch noch Nexus Anwender und bleibe da selbst am Ball. Auf der anderen Seite sollte es nun ohne aufwändige Manipulation der Senderlisten möglich sein, insbesondere auch Sender mit optionalen Tonspuren (Englisch bei Premiere, Dolby bei ARD Radiosendern, …) ohne weiter nachzudenken vollständig aufzuzeichnen.

So, dass muss erst mal reichen!

Jochen

DVB.NET 4.0 Konzepte: Abstraktion der ‚PID‘-Filter

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

DVB.NET 4.0 Konzepte: Installation und Verzeichnisse

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

So könnte es aussehen…

DVB.NET 4.0 Konzepte: Der Card Server

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

DVB.NET 4.0 Konzepte: Sendersuchlauf

Wie in den früheren Version werden auch DVB.NET 3.5.1ff Geräteprofile die Liste der Sender (Quellen in der neuen Notation) in sich tragen. Ebenso wird es möglich sein, gemeinsame Listen für verschiedene gleichartige Geräte zu verwenden – etwa ein DVB-S(2) Geräteprofil mit Senderliste für eine Hardware, die von anderer DVB-S(2) Hardware im gleichen Rechner mit genutzt wird. Dabei ist es jetzt auch möglich, unsinnige Quellgruppen (Transponder) aus der Referenz auszublenden – eine Hauppauge Nexus-S kann mit den DVB-S2 Quellgruppen einer TechnoTrend S2-3200 nichts anfangen.

Ebenso wie früher ist in einem Geräteprofil mit Quellen vermerkt, auf welcher Basis diese ermittelt wurden. Im Beispiel DVB-S (DVB-C und DVB-T sind diesbezüglich etwas einfacher) werden wie bisher erst einmal die einzelnen Satellitenantennen definiert, die von der jeweiligen Hardware mittels DiSEqC 1.0 angesteuert werden können (die alte Bezeichnung LNB wird durch den Begriff des Ursprungs ersetzt). Jeder Ursprung wird dann mit einer Satellitenkonfiguration verbunden, etwa Astra 1 auf 19.2° Ost. Und damit kommen wir zum eigentlichen Punkt dieses Artikels…

Für jeden Satelliten (ähnlich für DVB-C und DVB-T, hier geht es nur um das Prinzip) wird erst einmal eine Liste aller Quellgruppen (Transponder) verwendet, die bei einem Suchlauf angesteuert und nach Quellen (Fernsehen, Radio, Sonstiges) abgesucht werden sollen. Anders als bisher geht nun DVB.NET 3.5.1ff hin und ermittelt nach dem Ansteuern einer Quellgruppe die Gesamtkonfiguration des Satelliten über die so genannte SI Tabelle Network Information Table (NIT). Hier können etwa Quellgruppen vermerkt sein, die in der statischen (evtl. veralteten) Liste nicht vorhanden sind (man denke etwa an die neuen Frequenzen für Phoenix et al). Optional können Frequenzen und andere Empfangsparameter korrigiert sein – DVB.NET benutzt hier einen etwas entspannteren Vergleichsalgorithgmus, der auch Quellgruppen mit leicht veränderter Frequenz korrekt als identisch erkennt. Ein Sendersuchlauf berücksichtigt die Daten der NIT vorrangig. Da diese Informationen relativ selten gesendet werden (es kann schon mal über 10 Sekunden dauern, bis diese zur Verfügung stehen), versucht DVB.NET den Abruf so selten wie möglich vorzunehmen. Konkret wird die NIT nur für die Quellgruppen angefordert, die sich in der ursprünglichen (statischen) Liste befunden haben und nicht durch die NIT einer so ausgewerteten Quellgruppe schon bestätigt wurden.

Darin stecken zwei Ideen und ein Zwang. Die primäre Idee ist es, die Liste der Quellgruppen pro Satellit auf ein Minimum zu beschränken – DVB.NET 3.5.1ff wird dazu auch ein eigenes Werkzeug anbieten, dass zu einer Liste einen minimalen Satz von Quellgruppen ermittelt, über deren NIT Informationen die Liste rekonstruiert werden kann. Astra 1 ist da ein sehr gutes Vorbild: hier reicht eine einzige (!) Quellgruppe, um alle Frequenzen zu erfassen. Zusätzlich soll es aber auch möglich sein, mehr als eine Quellgruppe für die Ermittelung der vollständigen Liste einsetzen zu können – vital für DVB-T, daher der Zwang. Die zweite Idee schließlich ist die Annahme, dass NIT Informationen für Gruppen von Quellgruppen identisch sind – i.e. wenn die NIT der Quellgruppe A B enthält, dann wird A auch in der NIT von B vorhanden sein und die NIT von B ist mit der von A identisch. Damit kann bei den langen Listen, die aus der alten DVB.NET Version übernommen wurden, das Warten auf die NIT soweit als möglich reduziert werden. Ob das so passt, werden wir sehen… Ziel ist es, für die wichtigsten Ursprünge irgendwann einmal minimierte Listen zu haben – DVB-S ebenso wie DVB-C und DVB-T.

Ansonsten ist ein Suchlauf nicht viel anders als früher. Lediglich der Umfang der Informationen im Geräteprofil ist dramatisch reduziert – es werden keinerlei Datenstromkennungen (PID) mehr fest eingetragen – dazu an anderer Stelle mehr. Nach einen Suchlauf wird die neue Liste üblicherweise mit der alten zusammengeführt, i.e. die neuen Quellen ersetzen die alten, aber gerade nicht verfügbare Quellen werden nicht entfernt (etwa bedingt durch eine zeitliche Beschränkung der Ausstrahlung). Bekannte Mechanismen wie das Ausblenden von Quellgruppen und Quellen oder das Anpassen von Quellinformationen wie dem Sendernamen werden ebenso unterstützt.

Ok, zum Schluss: der gesamte Algorithmus für den Sendersuchlauf soll weitgehend konfigurierbar als eigenständige Komponente (.NET Klasse) nutzbar (! angeboten war es immer schon, nur die Nutzung war kniffelig !) angeboten werden. Diese wird dann nicht nur im neuen DVB.NET Konfigurationswerkzeug, sondern auch in VCR.NET 3.5.1 genutzt.

Puh, das war wieder viel zu viel. Genug!

Jochen

DVB.NET 3.5.1 Suchlauf