Transponderstatistik erstellen bei Verwendung von BDA Karten

Obwohl das im folgenden beschrieben Feature Standard in anderen Anwendungen ist und dort im Allgemeinen auch optisch ansprechend präsentiert wird, ist es doch neu in DVB.NET 3.0 und könnte den einen oder anderen trotz der mageren Darstellung als Textprotokoll interessieren – wohl kaum den Normalanwender, aber es gibt ja auch noch andere Neugierige da draussen.

Wenn DVB.NET 3.0 auf eine DVB Hardware über einen BDA Treiber zugreift (etwa bei der Hauppauge Nova-S Plus oder der TechnoTrend S2-3200), dann geschieht dies über so genannte DirectShow Filter. Für seine Kernaufgaben klinkt sich DVB.NET mit einem eigenen Filter in den Rohdatenstrom (Transport Stream des Senders), zerlegt diesen in seine Bestandteile und verteilt die einzelnen Datenströme gemäß der aktuellen Anforderung.

Wichtig ist, dass der gesamte Datenstrom durch DVB.NET läuft und während der Zerlegung intern einige Zähler mitgeführt werden. Diese Zähler können beim Beenden einer DVB.NET Anwendung in eine Datei geschrieben werden, wodurch man einen interessanten Einblick in die interne Struktur des Rohdatenstroms erhalten kann. Wird die Protokollierung in einer regulären DVB.NET Anwendung (Stream Manager, Quick Record, …) aktiviert, so wird das Protokoll im temporären Verzeichnis des Anwenders angelegt (C:\Documents and Settings\USER\Local Settings\Temp oder ähnliches). Bei einer Aktivierung für VCR.NET wird das temporäre Verzeichnis von Windows verwendet (%SystemRoot%\temp oder ähnliches), da VCR.NET als Windows Dienst unter dem LocalSystem Konto abgearbeitet wird und dieses kein Benutzerprofil besitzt. Man beachte, dass ein Protokolleintrag immer von Anfang bis Ende der Nutzung erfolgt und blind gegenüber Senderwechsel ist. Quick Record ist daher ein eher unüblicher Kandidat zur Erstellung eines Protokolls, VCR.NET schon fast ideal.

Die Aktivierung des Features erfolgt über einen Eintrag in der .NET Konfiguration des DVB.NET Programms, das ein Protokoll anlegen soll (etwa DVBStreamManager.exe.config oder auch JMS.DVBVCR.RecordingService.exe.config). Bei einer Eintragung bitte eine Sicherheitskopie anlegen und sorgfältig vorgehen – ein Fehleintrag kann dazu führen, dass das Programm nicht mehr startet, was beim VCR.NET besonders ärgerlich ist. Nach der Änderung muss das jeweilige Programm neu gestartet werden – auch das gilt besonders für den VCR.NET Windows Dienst. Der Eintrag selbst ist einfach:

<add key=“TSStatistics“ value=“True“ />

Ist das Erzeugen eines Protokolls aktiv, so wird eine Protokolldatei namens DVBNETTSStatistics.log fortlaufend gefüllt. Grundsätzlich werden die im Folgenden beschriebenen Eintragungen vorgenommen.

Immer, wenn ein Datenstromfilter (Bild, Ton, VideoText, EPG/Programmzeitschrift, PMT/PAT/Sendersuchlauf, …) nicht mehr benötigt wird, wird dessen Nutzung eingetragen:

2007.02.01 22:41:15 [00163] #290081 2376343552 ([8192..8192] 8192)

In eckigen Klammern steht der PID, hinter dem # die Anzahl der übertragenen Pakete (keine TS Pakete) und die Anzahl der übertragenen Bytes. Dahinter in Klammern minimale, maximale und mittlere Paketgröße. DVB.NET 3.0 überträgt Nutzdaten (PES Datenströme) in festen Blöcken von 8 kBytes ohne Rücksicht auf die Paketierung des Datenstroms. Die Weiterverarbeitung innerhalb von DVB.NET ist darauf vorbereitet. Bei Steuerdaten (SI Tabellen) werden tatsächlich immer ganze Tabellen übertragen, da sieht das schon interessanter aus, hier ein paar Zeilen aus meiner letzten Aktualisierung der Programmzeitschrift (PID 18 ist das EPG):

2007.02.03 18:01:07 [00018] #4641 4261011 ([18..4096] 918)
2007.02.03 18:02:09 [00018] #23587 9554622 ([18..3847] 405)
2007.02.03 18:03:10 [00018] #2236 2671201 ([18..4066] 1194)
2007.02.03 18:04:12 [00018] #4091 4208208 ([18..4063] 1028)

Nur am Ende einer DVB.NET Anwendung wird ein Gesamtprotokoll der durch DVB.NET analysierten Daten erstellt. Dieses beginnt immer mit einer Übersicht:

2007.02.01 22:41:17 cb=287822 b=27704594432 s=257372 p=147363495 enc=25321062
2007.02.01 22:41:17 strm=0 tbl=0 sync=5 err=10

Dabei bedeuten: cb=Anzahl der Aufrufe des DVB.NET DirectShow Filters durch das jeweilige BDA Gerät; b=Gesamtzahl der untersuchen Bytes; s=Durch Resynchronisation des Datenstroms (sync) verlorene Bytes; p=Anzahl der TS Pakete (à 188 Bytes); enc=Anzahl der verschlüsselten dadurch verworfenen TS Pakete; strm=Fehler bei der Analyse von PES Datenströmen; tbl=Fehler bei der Analyse von SI Tabellen; sync=Resynchronisationen durch nicht interpretierbare Daten; err=Anzahl der als fehlerhaft markierten und deswegen verworfenen TS Pakete.

Nun folgt für jeden Datenstrom dessen Datenvolumen:

2007.02.01 22:41:17 02047 #44
2007.02.01 22:41:17 00033 #12
2007.02.01 22:41:17 00255 #91
2007.02.01 22:41:17 00035 #9
2007.02.01 22:41:17 01791 #175
2007.02.01 22:41:17 01023 #136
2007.02.01 22:41:17 08191 #16160227

Die Zahl hinter der Uhrzeit ist der PID (dezimal), hinter dem # die Anzahl der zugehörigen TS Pakete. Interessant ist etwa der PID 8191, der nur Fülldaten enthält und letztlich eine Aussage über die verbleibende Datenkapazität im Rohdatenstrom ist.

Ich persönlich war überrascht zu sehen, dass die Rohdatenströme Bitraten von mehr als 30 MBit/s aufweisen (DVB-S). Und dass ich den Eindruck habe, als wenn DVB.NET die Zerlegung mindestens genauso gut kann, wie die Microsoft BDA Komponenten – zumindest was die Laufzeit angeht, funktional wurde diese Lösung gewählt, weil gerade die PSI zerlegung von Microsoft über den MPEG2 Demultiplexer unzureichend funktioniert.

Viel Spaß

Jochen

Über die Notwendigkeit der Deinstallation und andere Widrigkeiten der Installation

Inzwischen habe ich mich dazu durchgerungen bei VCR.NET zu empfehlen, vor einer Neuinstallation die vorherige Version zu deinstallieren – die verbleibenden Konfigurationsdateien sorgen dafür, dass die darauf folgende Installation mit den alten Einstellungen sofort loslegen kann.

Tatsächlich ist die Installation dafür vorgesehen, automatisch eine vorhandene Version zu deinstallieren und eine Installation unter Beibehaltung der Konfiguration durchzuführen. Das klappt auch – fast immer. Leider hat .NET ein paar Fallstricke, die ich zwar versuche, zu umgehen, aber ich bin mir nicht sicher, ob ich immer daran denke, denn wie gleich beschrieben ist es etwas lästig.

Die VCR.NET Installation erfolgt auf Basis eines MSI Setup Projektes, dass von Visual Studio 2005 angeboten wird. Da neben dem reinen Kopieren auch spezifischer Code ausgeführt werden muss, enthält das Projekt auch eine Installationskomponente und da liegt der Haken. Wenn eine Deinstallation ausgeführt wird, so muss diese Komponente geladen und ausgeführt werden – schön und gut. Genauso bei der Installation – auch klar, also wo liegt das Problem? Wenn Deinstallation und Installation in einem Schritt erfolgen und die Installationskomponente den gleichen Namen trägt, dann wird die Assembly im neuen MSI für die Installation nicht geladen – ist ja schon eine Assembly mit gleichem Namen im Speicher, wird schon die selbe sein, denkt sich .NET wohl. Ist es aber oft nicht! Darum muss ich bei jeder Änderung an der Installation (und das war für die 3.0 so einiges an Kleinkram) die Installationskomponente umbennen (der Name heute ist JMS.DVBVCR.Installer-14.dll, keine Ahnung, ob das im 3.0 Final auch so sein wird). Wenn ich das vergessen, passieren komische Dinge bei denjenigen, die genau ein Upgrade zwischen den Versionen machen, die den gleichen Namen aber unterschiedlichen Code für die Installationskomponente enthalten.

Genauso kann (aus anderen Gründen) keine Deinstallation auf Basis von .NET 1.1 (VCR.NET 2.6 oder früher) auf eine .NET 2.0 Version (2.7 oder später) in einem Schritt erfolgen. Wieder eine Ausnahme, die man erklären muss.

Wie gesagt: im Prinzip ist das Problem verstanden und im Griff, aber wer einfach nicht nachdenken möchte, macht erst mal die Deinstallation. Ich glaube sogar nicht mal, dass das viel langsamer ist.

Ja, und dann noch ein .NET Spielchen: bei der ersten Installation einer 3.0 Variante muss ein DVB.NET Geräteprofil ausgewählt werden. Um das zu vereinfachen, habe ich einen kleinen Assistenten gebastelt. Leider kennt die Installation nicht das Konzept des Hauptfensters einer Anwendung nicht (naja: vielleicht habe ich es auch nicht gefunden) und der Assistent wird ohne Owner / Parent geöffnet. Trotz diverser Anstrenungen (Top Fenster, ganz nach vorne geholt, …) passiert es ab und zu immer noch, dass der Assistent hinter dem Installationsfenster geöffnet ist und unsichtbar bleibt, bis man das Installationsfenster wegschiebt. Die Suche habe ich vorerst aufgegeben: der Assistent erscheint nun in der Windows Taskbar (wollte ich eigentlich vermeiden), so weiß man wenigstens, dass da was ist und kann ihn damit nach vorne holen.

So long

Jochen

Wenn man denkt, man wäre fertig…

Eben mal noch schnell testen, ob der VCR.NET mit dem Schlafzustand (Hibernate, S4) und dem Aufwachen auch richtig umgehen kann und dann ist die Beta fertig. Sieht auf den ersten Blick gut aus, auf den zweiten aber nicht: nach dem Aufwachen findet die TechnoTrend S2-3200 keine Sender – leider ein bekanntes Problem der BDA Treiber. Das hat zwar nichts mit VCR.NET zu tun, kann ich aber so auch nicht herausgeben.

Dafür ist in DVB.NET 3.0 ein interessantes Zusatzfeature entstanden: für die BDA Hardware Abstraktion kann nun eine Einstellung ResetAfterWakeup gesetzt werden (für alle TechnoTrend Budget Karten inklusive der S2-3200 passiert das erst einmal automatisch). Diese führt dazu, dass in der neuen Methode WakeUp der Abstraktion der Tuner deaktiviert (Disable im Gerätemanager) und wieder aktiviert (Enable) wird. Der VCR.NET ruft diese Methode nun immer vor der ersten Aufzeichnung nach dem Aufwachen aus dem Schlafzustand auf und erreicht so auch mit der S2-3200 zuverlässige Aufzeichnungen.

Neue Option in der Profilverwaltung

Im Gegensatz zu früher (der VCR.NET hatte mal so eine ähnliche Funktionalität für die TechnoTrend Premium Line 2.19 Beta Treiber) passiert das aber nur, wenn der VCR.NET es braucht. Andere Anwendungen hätten nach dem Aufwachen weiterhin das Problem und können die Karte nicht nutzen. Ich denke, für VCR.NET 3.0 werde ich das nicht einbauen aber man kann sich relativ einfach vorstellen, dass in einer zukünftigen Version der VCR.NET diese Reaktivierung einfach für alle eingebundenen Geräteprofile direkt nach dem Aufwachen macht. Hier muss man nur etwas mit dem Timing aufpassen: früher war das einfach, da am VCR.NET nur eine Karte hing!

Jochen

Erste echte Beta in Sicht…

Ich habe gerade die Grundfunktionalitäten von VCR.NET 3.0 Recording Service und Manager (jetzt neu: VCR.NET Control Center) so weit fertig gestellt, dass praktisch alle relevante Funktionalität der Vorgängerversion enthalten ist (Ausnahmen: Betrachten laufender Aufzeichnungen hackelt noch sehr; NVOD Anzeige zur laufenden Aufzeichnung; Extensions im Recording Manager). Ich muss allerdings noch zwei Kernfunktionalitäten selbst testen (Hibernate und Aufwachen; Sendersuchlauf mit mehreren, abhängigen Geräteprofilen), dann wäre es so weit… Allerdings kann ich aufgrund der wesentlichen Veränderungen das Ganze nicht ohne eine aktualisierte Installationsbeschreibung herausgeben, darum wird es wohl doch noch Ende der Woche werden.

Bis dann

Jochen

Kompromisse überall?

Ich möchte hier kurz auf zwei der Kompromisse eingehen, die im Zusammenhang mit der Umstellung auf die Web Anwendung von VCR.NET 3.0 gemacht wurden.

Heute ist es im VCR.NET Recording Manager so, dass die Anzeige der geplanten Aufzeichnungen auf eine feste Anzahl beschränkt ist. Ein Blättern ist nicht möglich. Möchte man mehr sehen, als die Liste hergibt, so kann man zwar diese Anzahl erhöhen, wird aber bei der Abfrage eine erhebliche Mehrbelastung des Windows Dienstes feststellen. Die Ursache ist, dass recht pingelig ermittelt wird, welche Aufzeichnungen stattfinden. Bei überlappenden Aufzeichnungen muss immer die vorherige Aufzeichnung bekannt sein, damit der genaue Startpunkt und die damit resultierenden Konsequenzen für Mehrkanalaufzeichnungen korrekt berücksichtigt werden. Zu kompliziert? Ok, hier das Beispiel der Web Anwendung: diese erlaubt die Anzeige für ein festes Zeitintervall, sagen wir mal 7 Tage (das ist die Voreinstellung, die man verändern kann). Die erste Seite der Liste ist im Sinne des alten Recording Managers exakt. Man kann aber nun auch in die Zukunft schauen und sich den Plan der nächsten Woche anschauen. Dabei beginnt die Liste immer um 00:00 Mitternacht. Findet zu diesem Zeitpunkt keine Aufzeichnung statt, so ist die Anzeige exakt. Findet aber eine Aufzeichnung statt, die etwas früher beginnt – sagen wir mal um 23:00 – so wird diese als problematisch (beginnt zu spät) markiert. Eigentlich müßte in einem solchen Fall der Testzeitpunkt mindestens bis zum Beginn der Aufzeichnung zurück verschoben werden und die Auswertung erneut gemacht werden. Was aber, wenn zu diesem Zeitpunkt eine frühere Aufzeichnung noch läuft? Man sieht, dass ist etwas lästig in der Auswertung. Selbst wenn es technisch nicht oft vorkommen wird, der Algorithmus müßte alle Situationen abdecken. Der Kompromiß an dieser Stelle ist trivial: entsteht eine solche Situation, so schaut man sich einfach den Aufzeichnungsplan der Woche davor an – der letzte Eintrag gibt in allen praktisch relevanten Situationen die korrekten Aufzeichnungsdaten wieder [nicht praktisch relevant ist hier nur, dass über den gesamten Betrachtungszeitraum ununterbrochen Aufzeichnungen durchgeführt werden].

Ein ähnliches Problem ergibt sich bei der Programmzeitschrift (vormals EPG genannt). Hier kann in der Liste nun auch (vorwärts) geblättert werden. Dabei wird der Zeitpunkt des letzten Eintrags auf einer Anzeigeseite als Anfangspunkt für die nächste Seite genommen. Dabei erscheint genau dieser Eintrag erst einmal doppelt – das ist meiner Ansicht nach kein Problem. Es kann aber nun vorkommen, dass die erlaube Anzahl von Einträgen in der Liste (die vom Anwender festgelegt werden kann) nicht ausreicht, um alle Sendungen zu zeigen, die zu diesem Zeitpunkt beginnen (eine Begrenzung auf 20 Einträge bei einer Anzeige von 20:15 ist dabei so ein Fall). In dieser Situation würde der einfache Algorithmus immer wieder zur gleichen Seite blättern! Der Kompromiß hier ist genauso trivial wie oben: die erlaubte Anzahl wird in dieser Situation ignoriert und es werden so viele Sendungen aufgelistet, dass die letzte in der Liste einen anderen Startzeitpunkt als die erste hat.

epg1.jpgepg2.jpg

Im Moment denke ich, dass diese Kompromisse kein Problem in der Bedienbarkeit der Web Anwendung darstellen.

Jochen