VCR.NET 3.9 Verluste: Aktualisierung der Version

Bisher habe ich mir immer sehr viel Mühe gegeben, dass bei einer aktualisierenden Installation (Deinstallation einer älteren Version und Installation der jeweils aktuellsten) der VCR.NET Recording Service sofort wieder einsetzbar ist. Das betrifft sowohl die Konfiguration als auch den Aufzeichnungsplan. Für 3.9 wird es einen Abstrich geben, der aber vermutlich kaum jemanden betrifft: erfolgt die Aktualisierung von einer Version vor 2.7 (ja, vor dem Punkt steht eine 2 und keine 3), so geht der Aufzeichnungsplan verloren. Die Konfiguration bleibt erhalten. Hintergrund ist, dass bis zur 2.6 die Aufzeichnungspläne als SOAP serialisierte XML Dateien gespeichert wurden und ab 2.7 ein neues Format verwendet wurde. VCR.NET hat beim ersten Starten automatisch eine verlustfreie Konvertierung vorgenommen. Mit 3.9 wurde das neue Format leicht modifiziert, um einige der Möglichkeiten der nächsten DVB.NET Generation schon einmal verfügbar zu machen. Auch hier gibt es wieder eine automatische Konvertierung, allerdings nur von dem 2.7er Format an – die doppelte Konvertierung wäre möglich, rechtfertigt sich aber nicht, da 2.6 einfach zu alt ist.

Wer denn dann wirklich eine 2.6 betreibt und unbedingt auf die 3.9 will: erst einmal irgendeine Zwischenversion installieren, VCR.NET einmal durchstarten und dann die Zwischenversion wieder deinstallieren. Das Durchstarten übernimmt den ersten Konvertierungsschritt.

Sollte es tatsächlich jemanden betreffen und Mühe machen: sorry!

Für die meisten anderen Anwender einfach zum Lesen und sofortigen Vergessen 🙂

Jochen

VCR.NET 3.9 Verluste: Optionsdienste (Services) von PREMIERE

Bisher war es möglich, einen Service (NVOD Film bei PREMIERE Direkt oder einen Sportkanal von PREMIERE SPORT) dadurch aufzuzeichnen, dass man eine Aufzeichnung auf dem zugehörigen Portal definierte und dann die NVOD Kennung spezifizierte – einfach wie Golf bei Sport, kryptisch wie D2-20:15 bei den Filmen. VCR.NET startet dann die Aufzeichnung auf dem Portal und beobachtete die Serviceinformationen, die in der elektronischen Programmzeitschrift mit übertragen wurden. Sobald der gewünschte Service verfügbar war, wurde die Aufzeichnung auf dem Portal beendet und auf für den Service neu gestartet.

Dieses Feature gibt es mit VCR.NET 3.9 gar nicht mehr. Zum einen glaube ich kaum, dass es produktiv genutzt wurde. Zum anderen bietet VCR.NET heute schon die Möglichkeit, die Programmzeitschrift der Dienste auszulesen und direkt eine Aufzeichnung auf dem entsprechenden Dienstkanal zu programmieren – natürlich geht das auch manuell, wenn man die Nummer des Dienstes kennt.

Bei der Konvertierung der Aufzeichnungsaufträge aus einer Vorgängerversion werden diese Daten erst einmal übernommen – die Konvertierung nimmt VCR.NET 3.9 beim ersten Starten automatisch vor. Allerdings werden diese Aufträge nicht bei der Planung berücksichtigt – ich habe die Absicht, diese wie Aufzeichnungen mit nicht mehr bekannten Sendern durch ein ? in der Oberfläche zu kennzeichnen, aber so weit ist 3.9 nach lange nicht.

Sollte sich tatsächlich jemand melden, der das Feature benutzt, werde ich das Ganze noch einmal überdenke. Bis dahin gehe ich von R.I.P. aus.

Jochen

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