Design und Implementierung eines Mehrbenutzer- Szenarios ... - NMM

U N I V E R S I T A S 

S I S 

S A R A V I E N 

Design und Implementierung eines Mehrbenutzer- 

Szenarios in einer verteilten TV-Umgebung 

Christoph Wellner 

Diplomarbeit 

nach einem Thema von Prof. Dr.-Ing. Philipp Slusallek 

Naturwissenschaftlich-Technische Fakultät I 

Fachrichtung 6.2 – Informatik 

Universität des Saarlandes, Saarbrücken, 2006

Hiermit erkläre ich an Eides statt, dass ich die vorliegende Arbeit selbständig 

verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel 

verwendet habe. 

Saarbrücken, 24. Januar 2006.

Ich danke . . . 

. . . Prof. Slusallek für die Vergabe des Themas der Diplomarbeit. 

. . . Marco Lohse und Michael Repplinger für die ausgezeichnete 

Betreuung. 

. . . Der gesamten NMM-Gruppe. 

. . . Meinen Eltern Helga und Erich Wellner für das Ermöglichen 

dieses Studiums und die moralische Unterstützung. 

. . . Meinem Bruder Andreas und meinen Großeltern.

Inhaltsverzeichnis 

1 Einleitung 3 

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 

1.2 Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 

1.3 Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 

2 Verwandte Projekte 9 

2.1 Fernseher und Settop-Boxen . . . . . . . . . . . . . . . . . . . . 10 

2.2 Kommerzielle Anwendungen und Systeme . . . . . . . . . . . . . 12 

2.2.1 Alleinstehende Programme . . . . . . . . . . . . . . . . . 12 

2.2.2 Home Entertainment Systeme . . . . . . . . . . . . . . . 13 

2.2.2.1 Windows Media Center Edition . . . . . . . . . 13 

2.2.2.2 SageTV2 . . . . . . . . . . . . . . . . . . . . . 15 

2.2.2.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . 16 

2.3 Open Source Anwendungen . . . . . . . . . . . . . . . . . . . . 16 

2.3.1 Alleinstehende Programme . . . . . . . . . . . . . . . . . 16 

2.3.1.1 xawtv . . . . . . . . . . . . . . . . . . . . . . 17 

2.3.1.2 vcr - Kommandozeilen-Videorekorder . . . . . 17 

2.3.1.3 WebVCR+ . . . . . . . . . . . . . . . . . . . . 18 

2.3.1.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . 18 

2.3.2 Home Entertainment Systeme . . . . . . . . . . . . . . . 19 

2.3.2.1 VDR . . . . . . . . . . . . . . . . . . . . . . . 19 

2.3.2.2 Freevo . . . . . . . . . . . . . . . . . . . . . . 21 

2.3.2.3 MythTV . . . . . . . . . . . . . . . . . . . . . 22 

2.3.2.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . 22 

2.4 Forschungprojekte . . . . . . . . . . . . . . . . . . . . . . . . . 24 

2.4.1 TVAnytime-Forum . . . . . . . . . . . . . . . . . . . . . 24 

2.4.2 WWICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

2.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . 25 

3 Netzwerk-Integrierte Multimedia Middleware 27 

3.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 

3.1.1 Knoten . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 

3.1.2 Jacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 

3.1.3 Nachrichtensystem . . . . . . . . . . . . . . . . . . . . . 29 

3.1.4 Verteilte Flussgraphen . . . . . . . . . . . . . . . . . . . 30 

3.2 Middleware-Dienste . . . . . . . . . . . . . . . . . . . . . . . . . 31 

3.2.1 Geräteverwaltung . . . . . . . . . . . . . . . . . . . . . . 31 

3.2.2 Session-Sharing . . . . . . . . . . . . . . . . . . . . . . 32 

i

INHALTSVERZEICHNIS 

ii 

3.3 Die Multimedia-Box . . . . . . . . . . . . . . . . . . . . . . . . 34 

3.3.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 34 

3.3.2 Anwendungs-Framework . . . . . . . . . . . . . . . . . . 35 


4 Realisierung einer elektronischen Programmzeitschrift 39 

4.1 Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 

4.2 Quellen für EPG-Informationen . . . . . . . . . . . . . . . . . . 45 

4.2.1 Integration verfügbarer EPG-Quellen . . . . . . . . . . . 45 

4.2.2 Übertragung der Informationen . . . . . . . . . . . . . . 50 

4.2.3 XMLTV-Plugin . . . . . . . . . . . . . . . . . . . . . . . 53 

4.2.4 nxtvepg-Plugin . . . . . . . . . . . . . . . . . . . . . . . 61 

4.2.5 DVB-EPG-Plugin . . . . . . . . . . . . . . . . . . . . . . 62 

4.3 Verwaltung der EPG-Informationen . . . . . . . . . . . . . . . . 64 

4.3.1 Einfügen der Daten . . . . . . . . . . . . . . . . . . . . . 69 

4.3.2 Abfragen und Durchsuchen der Daten . . . . . . . . . . . 71 

4.4 Verteilung einer Anfrage im Netzwerk . . . . . . . . . . . . . . . 75 

4.4.1 Der EPG als eigenständige Anwendung . . . . . . . . . . 85 

4.5 Integration in die Multimedia-Box . . . . . . . . . . . . . . . . . 85 

4.5.1 Der TVGuide-Zustand . . . . . . . . . . . . . . . . . . . 85 

4.5.2 Der Search-Zustand . . . . . . . . . . . . . . . . . . . . 90 

4.5.3 EPG-Informationen im LiveTV-Zustand . . . . . . . . . . 95 


5 Realisierung von Szenarien des Mehrbenutzer-TV 99 

5.1 Verwendung einer Quelle durch eine Anwendung . . . . . . . . . 101 

5.2 Zugriff einer Anwendung auf mehrere Quellen . . . . . . . . . . 101 

5.2.1 Die globale Kanalliste . . . . . . . . . . . . . . . . . . . 102 

5.2.1.1 Datenstruktur der globalen Kanalliste . . . . . . 103 

5.2.1.2 Auslesen der Kanäle einer TV-Quelle . . . . . . 105 

5.2.2 Ein Videorekorder auf Basis von NMM . . . . . . . . . . 106 

5.2.2.1 Realisierung des Videorekorders . . . . . . . . 108 

5.2.2.2 Einprogrammieren von Aufnahmen . . . . . . . 113 

5.2.2.3 Erkennen und Auflösen von Konflikten . . . . . 115 

5.2.2.4 Starten und Beenden von Aufnahmen . . . . . . 117 

5.2.2.5 Automatisches Wiederholen von Aufnahmen . . 120 

5.2.2.6 Ändern und Löschen von Aufnahmen . . . . . . 121 

5.2.2.7 Der Videorekorder als separate Anwendung . . 122 

5.3 Zugriff mehrerer Anwendungen auf mehrere Quellen . . . . . . . 122 

5.3.1 Zusammenspiel EPG - LiveTV/Videorekorder . . . . . . . 124 

5.3.2 Zusammenspiel Live TV - Live TV . . . . . . . . . . . . 125 

5.3.3 Zusammenspiel LiveTV - Videorekorder . . . . . . . . . 126 

5.3.4 Zusammenspiel EPG - Live TV - Videorekorder . . . . . 127 

5.3.5 Festlegung des Verwendungszwecks einer Quelle . . . . . 130 

5.3.6 Bestimmung einer verwendbaren Quelle . . . . . . . . . . 133 

5.4 Integration in die Multimedia-Box . . . . . . . . . . . . . . . . . 137 

5.4.1 Der TVTimer-Zustand . . . . . . . . . . . . . . . . . . . 137 

5.4.2 Der LiveTV-Zustand . . . . . . . . . . . . . . . . . . . . 140



6 Zusammenfassung und Ausblick 145 

6.1 Erreichte Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 

6.2 Erweiterungsmöglichkeiten . . . . . . . . . . . . . . . . . . . . . 147 

6.2.1 EPG-Plugins . . . . . . . . . . . . . . . . . . . . . . . . 147 

6.2.2 Benachrichtigung über eintreffende EPG-Informationen . 148 

6.2.3 Zusammenschluß mehrerer Videorekorder . . . . . . . . . 148 

6.2.4 Master-Slave-Konzept auf Middleware-Ebene . . . . . . . 149 

A Neue Konfigurations-Variablen in der Multimedia-Box 151 

A.1 Konfiguration des EPG . . . . . . . . . . . . . . . . . . . . . . . 151 

A.2 Konfiguration des Videorekorders . . . . . . . . . . . . . . . . . 152 

A.3 Konfiguration von Live TV . . . . . . . . . . . . . . . . . . . . . 153 

B Konfigurations-Dateien 155 

B.1 Default-Konfigurations-Dateien für EPG-Plugins . . . . . . . . . 155 

B.2 Datei zur Angabe von Aliasen für Sendernamen . . . . . . . . . . 156 

B.3 Videorekorder und Live TV . . . . . . . . . . . . . . . . . . . . . 156 

1


2

Kapitel 1 

Einleitung 

1.1 Motivation 

In der heutigen Zeit schreitet die Vernetzung von Unterhaltungsgeräten immer weiter 

voran. Dies zeigt sich vor allem darin, dass immer mehr Geräte auf den Markt 

gebracht werden, die einen Netzwerkanschluss enthalten. Eine solche Vorrichtung 

ermöglicht deren Einbindung in ein Home Entertainment Netzwerk und die Kommunikation 

verschiedener Multimediageräte untereinander. Somit lässt sich z.B. 

eine DVD, die im Arbeitszimmer in einem Personal Computer (PC) eingelegt ist, 

im Wohnzimmer auf einem Fernsehgrät wiedergeben. Die wohl am meisten genutzte 

Form der Unterhaltung ist jedoch nach wie vor das Fernsehen. 

Als Fernsehen bezeichnet man heute im Speziellen eine Technik, bei der die Bilder 

bewegt sind und zusätzlich passender Ton übertragen wird [Wikc]. Die Inhalte werden 

von Rundfunkanstalten bereitgestellt und von einem Sender über einen Kanal 

zu einem Empfänger übertragen. Deshalb werden die Rundfunkanstalten auch als 

Sender bezeichnet. Jeder Sender überträgt die Daten über einen eindeutigen Kanal, 

weshalb diese Begriffe in dieser Arbeit synonym verwendet werden. Die einzelnen 

Inhalte werden als Sendung bezeichnet, woraus sich das Programm eines Senders 

zusammensetzt. Die Sendungen können entweder direkt auf einem Fernsehgerät 

verfolgt werden, was als Live TV bezeichnet wird, oder zu einer späteren Wiedergabe 

auf entsprechenden Medien gespeichert werden. Die dafür notwendigen Geräte 

werden Videorekorder genannt, welche zu vorgegebenen Zeiten Sendungen aufzeichnen 

und zu einem späteren Zeitpunkt wiedergeben können. Zur Übertragung 

der Fernsehsignale werden heutzutage unterschiedliche Techniken verwendet. 

Die älteste Art der Übertragung ist die analoge Technik. Die Daten werden per 

Satellit, Kabel oder Antenne in die Haushalte geliefert, welche sich in dem unterschiedlichen 

Angebot bereitgestellter Sender unterscheiden. Im Gegensatz zu 

der Übertragung per Satellit ist die Auswahl an Sendern über Kabel oder Antenne 

regional unterschiedlich. Zudem werden per Satellit weit über 100 Sender 

bereitgestellt [ASTa], während per Kabel der Empfang auf 30 Sender beschränkt 

ist [Kabb]. Neben den Audio- und Video-Daten wird als Zusatzdienst der Tele- 

3

KAPITEL 1. Einleitung 

4 

text [ETS97c], auch Videotext genannt, übertragen, durch diesen u.a. Informationen 

über das Programm eines Senders abgerufen werden können. Mittlerweile wird 

die analoge Übertragungstechnik durch die digitale abgelöst. Diese zeichnet sich 

durch eine bessere Bild- und Tonqualität im Vergleich zur analogen Technik aus, da 

sich digitale Signale mittels Fehlerkorrektur verlustfrei übertragen und außerdem 

mit geringen Qualitätsverlusten stark komprimieren lassen [Wika]. Zur Kompression 

der Daten wird beim digitalen Fernsehen der MPEG-2-Standard [ISO04] verwendet. 

Im Gegensatz zur unkomprimierten Übertragung des analogen TV-Signals 

können beim Digitalfernsehen insgesamt mehr Bild- und Audio-Daten übertragen 

werden, was zu einem rauschärmeren Bild und einem klareren Klang führt. 

Neben dem Videotext sind bei der digitalen Übertragung zusätzliche Dienste verfügbar. 

So können verschiedene Multimedia-Dienste unter Verwendung des MHP- 

Standards [ETS03] bereitgestellt werden. Zusätzlich wird mit dem Fernsehsignal 

ein Elektronischer Programmführer (Electronic Programme Guide (EPG) übertragen, 

der Programm-Informationen zu Sendungen der verschiedenen Sender enthält. 

Ein EPG ist die digitale Form einer gedruckten Programmzeitschrift, die Informationen 

zu einzelnen Sendungen bereitstellt [Wikb]. Diese enthalten zu jeder Sendung 

neben der Start- und Endzeit den Titel der Sendung sowie eine Beschreibung 

deren Inhalts und können während des Fernsehens angezeigt und sogar durchsucht 

werden. Seit 1997 werden auch mittels des analogen Fernsehsignals EPG- 

Informationen übertragen [ETS97b]. Es gibt jedoch heutzutage nur wenige Geräte, 

die diese Daten lesen und anzeigen können. Durch die Nutzung von TV-Karten 

können diese Informationen auch auf PCs genutzt werden. Zum Erhalt von EPG- 

Informationen ist der Computer jedoch nicht ausschließlich auf die Verwendung 

von TV-Karten beschränkt. Durch die Anbindung an das Internet kann er auf eine 

größere Auswahl an EPG-Quellen zurückgreifen. Diese und die TV-Quellen unterscheiden 

sich jedoch meist in der Anzahl der Sender, für die Daten bereitgestellt 

werden, durch deren Informationsgehalt und den Zeitraum, für den Informationen 

zur Verfügung gestellt werden. Zur Nutzung dieser Daten könnte eine Anwendung 

ihre Informationen von unterschiedlichen EPG-Quellen sammeln um so möglichst 

umfangreiche Daten für alle gewünschten Kanäle für einen größt möglichen Zeitraum 

zur Verfügung zu haben. 

Die Nutzung der Informationen muss jedoch nicht auf eine Anwendung beschränkt 

sein. So ist es möglich, dass verschiedenen Programmen, ohne direkten Zugriff 

auf eine EPG-Quelle, Informationen von anderen zur Verfügung gestellt werden. 

So könnte ein PC keinen Zugang zum Internet besitzen, jedoch einen anderen PC 

erreichen, der eine solche Anbindung hat. Die Anwendung mit Internetanbindung 

stellt nun durch eine Netzwerkschnittstelle die gewünschten Daten zur Abfrage 

bereit. Andere Applikationen können das Fehlen von Daten erkennen und diese 

schließlich von dort erfragen. Auf diese Weise ist es möglich die eigenen EPG- 

Informationen zu vervollständigen und anderen zur Nutzung freizugeben. 

Eine TV-Karte erlaubt dem PC nicht nur das Sammeln von EPG-Informationen, 

sondern selbstverständlich auch den Zugriff auf das Fernsehprogramm der einzelnen 

Sender. Diese Daten können wiederum für Live TV genutzt oder aufgezeichnet 

werden. Innerhalb eines Netzwerks können diese TV-Karten auch solchen PCs zu-

gängig gemacht werden, die selbst keine TV-Karte besitzen. So ist es in einem Home 

Entertainment Netzwerk möglich z.B. von der Küche aus die TV-Karte eines 

in einem anderen Raum befindlichen Rechners zu verwenden um während einer 

Kochsendung die Rezepte gleich in die Tat umzusetzen. 

Meist besteht ein Haushalt aus mehreren Parteien mit unterschiedlichen Interessen, 

insbesondere bzgl. ihrer Fernsehgewohnheiten. Dazu zählt nicht nur Live TV, 

sondern auch das Aufnehmen von Sendungen durch einen Videorekorder. Zur Vermeidung 

von Interessenskonflikten, das Live TV betreffend, müsste theoretisch in 

jedem Haushalt für jeden Teilnehmer eine TV-Quelle vorhanden sein. Weiterhin 

müsste für jeden zur Verfügung stehenden Kanal eine TV-Quelle existieren, damit 

zu jeder Zeit eine Sendung mittels eines Videorekorders aufgenommen werden 

kann ohne Gefahr zu laufen, dass dies auf Grund mangelnder TV-Quellen scheitert. 

Zur Verdeutlichung sei ein Beispiel angeführt: Ein Zwei-Personen Haushalt 

kann über das Kabelnetz 30 Kanäle empfangen. Um zu jeder Zeit jeden Kanal aufnehmen 

zu können, müssten 30 Videorekorder zur Verfügung stehen. Durch Einbeziehen 

des Live TV erhöht sich die notwendige Anzahl der Geräte zum Fernsehempfang 

auf 32. In der Regel ist jedoch eine solch große Anzahl von TV-Geräten 

nicht vorhanden, sodass ggf. mehrere Personen die gleiche TV-Quelle verwenden 

wollen. 

Aus diesem Grund sind die verfügbaren TV-Quellen je nach der momentan gewünschten 

Verwendungsart automatisch zu verwalten. Unter Verwendungsart wird 

das Benutzen einer TV-Quelle zu einem bestimmten Zweck verstanden, wie z.B. 

zur Aufnahme einer Sendung oder für Live TV. Dazu muss dynamisch festgestellt 

werden, für welchen Zweck die TV-Quelle aktuell verwendet wird und abhängig 

davon, welche Kontrollmöglichkeit für den entsprechenden Benutzer besteht. Eine 

TV-Quelle könnte auch von mehreren Benutzern gemeinsam verwendet werden, 

sodass diese die Audio-Video-Daten der selben TV-Karte entweder aufzeichnen 

oder auf unterschiedlichen Geräten darstellen. Dabei muss festgestellt werden, wer 

bei der TV-Quelle den Kanal wechseln darf. Es gilt zu vermeiden, dass z.B. eine 

Aufnahme durch den EPG unterbrochen wird, weil dieser von dem nächsten Kanal 

Informationen sammeln will, oder während Live TV der Kanal durch den EPG 

gewechselt wird. 

1.2 Ziele 

Ziel dieser Diplomarbeit ist die Erweiterung des am Lehrstuhl für Computergraphik 

entwickelten Home Entertainment Systems Multimedia-Box. Dies soll um 

eine Elektronische Programmzeitschrift erweitert werden, die bisher nicht realisiert 

wurde. Der EPG soll Daten von unterschiedlichen Quellen gleichzeitig abfragen 

und lokal speichern sowie durch eine entsprechende Schnittstelle über das 

Netzwerk angesprochen werden und mit anderen EPGs Daten austauschen können. 

Außerdem sollen die Live TV-Funktionalität und der Videorekorder um die 

Möglichkeit des Zugriffs auf mehrere TV-Quellen erweitert werden. Diese unterstützten 

bisher lediglich eine lokale oder im Netzwerk verteilte TV-Karte. Wei- 

1.2. ZIELE 

5


6 

terhin wird die Realisierung der Konzepte des Mehrbenutzer-TV angestrebt, wodurch 

eine Einschränkung der Kontrollmöglichkeit der genannten Anwendungen 

bei einem gemeinsamen Zugriff auf eine TV-Quelle vorgenommen werden soll. 

Diese Kontrollmöglichkeit der Anwendungen beschränkt sich in dieser Arbeit auf 

das Einstellen des benötigten Senders bei einer TV-Quelle. Darf eine Anwendung 

den Kanal wechseln, wird von einem kontrollierenden Zugriff gesprochen. Die 

Multimedia-Box und der vor dieser Arbeit erreichte Status der genannten Funktionalitäten 

werden in Abschnitt 3.3 genauer vorgestellt. 

Zur Realisierung des EPG müssen zuerst die entsprechenden Voraussetzungen geschaffen 

werden. Dazu zählen vor allem das Bestimmen und das Verwenden von 

möglichen Informationsquellen. Zahlreiche Anlaufstellen bietet das Internet zur 

Beschaffung von EPG-Daten, zudem existieren die bereits angesprochenen TV- 

Übertragungstechniken, die solche Informationen in den Datenstrom integrieren. 

Sie sind jedoch unterschiedlich formatiert und müssen deshalb zuerst in ein einheitliches 

Format gebracht werden. Je nach Anbieter haben solche Daten unterschiedlichen 

Informationsgehalt. Der eine liefert genauere Zeiten, ein anderer mehr 

Informationen zu Fernsehsendungen. Für eine Sammlung von möglichst aktuellen 

und umfangreichen Daten müssen daher die verschiedenen Quellen priorisiert werden. 

Dies dient der Entscheidung darüber, welche Informationen den vorhandenen 

hinzugefügt oder verworfen werden können. Dazu sind sowohl eine Architektur 

erforderlich, die das parallele Abfragen mehrerer Quellen unterstützt, als auch Regeln 

zur Bestimmung, welche Informationen zu verwenden und gegebenenfalls als 

gleichwertig zusammenzuführen sind. Die gesammelten Daten sollen permanent 

verfügbar sein, was u.a. bedeutet, dass nach dem Starten der Anwendung die schon 

gesammelten Informationen direkt abrufbar sind, weshalb sie für einen schnellen 

Zugriff lokal auf der Festplatte gespeichert werden sollen. 

Ein zusätzliches Ziel ist die Erweiterung des EPG um Netzwerkunterstützung. Dies 

bedeutet, dass er sich bei Bedarf mit im Netzwerk verteilten EPGs verbinden soll 

und diese nach Daten abfragen kann. Dazu soll festgestellt werden, ob eine Verteilung 

der Anfrage im Netzwerk notwendig ist. Dies erfordert eine Überprüfung der 

lokal ermittelten Abfrageergebnisse bzgl. eventuell fehlender Daten. Dieses Vorgehen 

soll durch die Implementierung einer Peer-to-Peer-Funktionalität realisiert 

werden. In einem Peer-to-Peer-Netz sind alle Computer gleichberechtigt und in 

der Lage sowohl Dienste in Anspruch zu nehmen als auch solche zur Verfügung 

zu stellen. Die Computer können als Arbeitsstationen genutzt werden, aber auch 

Aufgaben im Netz übernehmen [Wikf]. 

Weiterhin soll in dieser Arbeit das Mehrbenutzer-TV realisiert werden. Darunter 

versteht man Anwendungsszenarien, in denen der Zugriff mehrerer Benutzer auf 

mehrere TV-Quellen automatisch geregelt wird. Als Benutzer werden in dieser Arbeit 

zum einen Anwendungen wie der EPG oder der Videorekorder bezeichnet, die 

selbstständig auf eine TV-Karte zugreifen um z.B. einen Kanal einzustellen und 

zum anderen Anwender, die mit Hilfe eines Programms für Live TV kontrollierend 

auf eine TV-Karte zugreifen können. Die Szenarien beschreiben Wechselwirkungen, 

welche bei einem gemeinsamen Zugriff der genannten Anwendungen auf 

eine TV-Quelle auftreten. Unter einem gemeinsamen Zugriff zweier Anwendungen 

wird die gleichzeitige Verwendung einer Quelle durch diese Anwendungen

verstanden, d.h. beide greifen gemeinsam auf die Daten der Quelle zu. Dazu sollen 

die in der Multimedia-Box vorhandene Funktionalität für das Live TV und der 

Videorekorder ausgebaut werden. Als weitere Anwendung kommt der EPG hinzu, 

der durch Zugriff auf eine digitale TV-Karte Programm-Informationen sammelt. 

Für diese Anwendungen soll ein Algorithmus entwickelt werden, der automatisch 

verwendbare TV-Quellen ermittelt. Weiterhin soll eine Beschränkung der Kontrollmöglichkeit 

der einzelnen Anwendungen bei einem gemeinsamen Zugriff auf eine 

TV-Karte gegeben sein. Dies erfordert das Aufstellen von Regeln um festzulegen, 

welche Anwendung in diesem Fall den Kanal wechseln darf. Diese Beschränkung 

dient auch als Kriterium für eine verwendbare TV-Quelle zur Feststellung, ob eine 

Anwendung den geforderten Kanal einstellen darf, wenn die Quelle schon anderweitig 

verwendet wird. Als Vorlage dient dabei der in [LRS05] vorgestellte 

Algorithmus zur dynamischen Zuteilung von TV-Quellen. 

Zuerst ist jedoch festzulegen, welche TV-Quellen verwendet werden sollen. Diese 

können zum einen lokal oder in einem über das Netzwerk ansprechbaren Rechner 

existieren. Zur Kommunikation mit den entsprechenden Geräten ist eine Middleware 

erforderlich, die einen transparenten Zugriff auf lokale sowie im Netzwerk 

verteilte Ressourcen bietet. Diese Funktionalität wird von der Netzwerk-Integrierten 

Multimedia Middleware (NMM) bereitgestellt, welche in Kapitel 3 vorgestellt wird. 

Als Middleware wird eine Software-Infrastruktur für verteilte Systeme bezeichnet. 

Sie dient als Abstraktionsschicht zwischen der Anwendung und dem Betriebssystem 

und verbirgt die netzwerkspezifischen Eigenschaften des Systems vor dem 

Entwickler. Somit erhält der Entwickler einen transparenten Zugriff auf im Netzwerk 

verteilte Ressourcen. Der Begriff transparent bedeutet, dass die verteilte 

Kommunikation vor der Anwendung verborgen bleibt und der direkte Zugriff auf 

verteilte Ressourcen ermöglicht wird. 

Weiterhin muss ermittelt und gespeichert werden, welche Sender die zu verwendenden 

TV-Karten bereitstellen. Dies schließt das Erkennen der Verfügbarkeit eines 

Senders über mehrere TV-Quellen mit ein. In diesem Fall muss eine Hierarchie 

derer festgelegt werden, die z.B. die Qualitätsaspekte von Übertragungstechniken 

berücksichtigt, sodass Anwendungen immer eine TV-Karte mit der höchst möglichen 

Präferenz zugewiesen wird. Zudem muss festgelegt werden, welche Anwendungen 

kontrollierend auf eine TV-Quelle zugreifen können, um evtl. den Kanal zu 

wechseln. Dies erfordert eine Hierarchie der Anwendungen, welche festlegt, dass 

niedriger priorisierte Anwendungen die entsprechende TV-Quelle zwar verwenden, 

jedoch nicht kontrollieren können. In dieser Arbeit soll zum einen dynamisch 

ermittelt werden, ob eine TV-Quelle von einem EPG, Live TV oder dem Videorekorder 

verwendet wird zum anderen die Kontrollmöglichkeit der Anwendungen 

unter Berücksichtung der Hierarchie eingeschränkt werden. 

Der Videorekorder soll sowohl den Zugriff auf mehrere lokal oder im Netzwerk 

verfügbare TV-Karten als auch das Programmieren von Aufnahmen durch mehrere 

Benutzer unterstützen. Des Weiteren wird die Realisierung einer Konflikterkennung 

angestrebt, die zum einen den entsprechenden Aufnahmen freie TV-Karten 

zuweist, zum anderen dem Benutzer anzeigt, welche der einzelnen Aufnahmen auf 

Grund fehlender Ressourcen nicht programmiert werden konnte. Dafür soll in der 

1.2. ZIELE 

7


8 

Multimedia-Box die Möglichkeit der manuellen Auflösung von Konflikten vorgesehen 

sein. Dies beinhaltet die Anzeige von nicht programmierbaren Aufnahmen 

sowie deren Zuordnung zu einprogrammierten Aufnahmen, mit denen sie in Konflikt 

stehen. 

1.3 Gliederung 

In der vorliegenden Diplomarbeit gibt Kapitel 2 eine Übersicht über ausgewählte 

Programme, die dem Zugriff auf TV-Karten oder EPG-Informationen dienen. 

Dazu werden verschiedene Vertreter aus dem Bereich der kommerziellen Anwendungen 

und dem Open-Source-Bereich betrachtet. Diese gliedern sich wiederum 

in alleinstehende Programme, die ausschließlich den Zugriff auf TV-Quellen oder 

EPG-Informationen ermöglichen und Home Entertainment Systeme, welche diese 

und weitere Funktionalitäten in einer Anwendung vereinen. Zuletzt werden Forschungsprojekte 

vorgestellt, die im Umfeld der verteilten TV-Anwendungen angesiedelt 

sind. 

Inhalt des Kapitels 3 ist die Vorstellung der Netzwerk-Integrierten Multimedia 

Middleware (NMM), welche am Lehrstuhl für Computergraphik an der Universtät 

des Saarlandes entwickelt wird. Sie dient als Grundlage für die Implementierung 

der in dieser Diplomarbeit entwickelten Konzepte und Programme. 

In Kapitel 4 wird die realisierte Elektronische Programmzeitschrift beschrieben, 

welche Informationen von verschiedenen Quellen sammelt und zur Verfügung stellt. 

Neben der Peer-to-Peer-Funktionalität zur Realisierung eines verteilten EPGs wird 

die Integration des EPG in die Multimedia-Box besprochen. 

In Kapitel 5 werden Szenarien erläutert, in denen mehrere Benutzer auf mehrere 

TV-Quellen zugreifen, die Realisierung des Videorekorders beschrieben und ein 

Algorithmus entwickelt, der auf Grundlage verschiedener Kriterien eine verwendbare 

TV-Quelle ermittelt um Konflikte in der Ressourcennutzung zu vermeiden. 

Das Kapitel endet mit der Integration dieser Konzepte in die Multimedia-Box. 

Zum Abschluss gibt Kapitel 6 einen Überblick über die erreichten Ziele und Erweiterungsmöglichkeiten 

der vorliegenden Arbeit.

Kapitel 2 

Verwandte Projekte 

In diesem Kapitel werden zu der vorliegenden Arbeit verwandte Programme und 

Projekte vorgestellt. Sie bieten die Möglichkeit TV-Sendungen anzusehen, aufzuzeichnen 

oder EPG-Informationen anzuzeigen bzw. diese Funktionen zu vereinen. 

Am verbreitesten sind nach wie vor Hardwarelösungen wie Settop-Boxen und 

Fernsehgeräte, die EPG-Informationen sammeln und anzeigen bzw. Videorekorder 

zur zeitgesteuerten Aufnahme einer Sendung. Dies sind oft eigenständige Geräte, 

die nicht miteinander kommunizieren können. So kann z.B ein Videorekorder nicht 

auf die von einer Settop-Box gesammelten EPG-Informationen zugreifen. 

Des Weiteren gibt es eine Vielzahl an Computerprogrammen und Dienstleistungen, 

die dazu verwendet werden können TV-Sendungen von einer in einem PC eingebauten 

TV-Karte aufzunehmen oder EPG-Informationen anzuzeigen. Die Programme 

können entweder käuflich erworben werden oder sind kostenlos als Open 

Source verfügbar. Neben Home Entertainment Systemen existieren viele kleine 

Programme, welche die gewünschten Aufgaben erfüllen, jedoch fehlt ihnen eine 

einheitliche Benutzeroberfläche. Home Entertainment Systeme verbinden diese 

Funktionalität unter einer einheitlichen Benutzeroberfläche. Sie bieten neben Live 

TV und einem Videorekorder zusätzlich einen EPG, mit dessen Hilfe Aufnahmen 

programmiert und Informationen zu Sendungen während Live TV bereitgestellt 

und angezeigt werden können. 

Home Entertainment Systeme bieten neben der TV-Funktionalität noch weitere 

Möglichkeiten der Medienwiedergabe wie z.B. das Abspielen einer DVD oder Musikdateien. 

Da dies jedoch für diese Arbeit nicht relevant ist, wird auf eine weitere 

Erläuterung verzichtet. 

Zur Vollständigkeit sind als Quellen für Programm-Informationen auch die Printmedien 

zu nennen. Neben Programmzeitschriften, die das Programm im Ein- oder 

Zwei-Wochenrhythmus angeben, ist das Fernsehprogramm eines Tages in vielen 

Tageszeitungen enthalten. Da sich diese Arbeit jedoch u.a. auf das digitale Erstellen 

einer Programmzeitschrift konzentriert, werden die Printmedien nicht näher 

betrachtet. 

9

KAPITEL 2. Verwandte Projekte 

10 

Zuerst wird in Abschnitt 2.1 darüber informiert, wie Settop-Boxen und Fernsehgeräte 

EPG-Informationen sammeln und anzeigen. 

In Abschnitt 2.2 werden kommerzielle Anwendungen behandelt, was sich in die 

Betrachtung einzelner kleinerer Programme in Abschnitt 2.2.1, gefolgt von der 

Vorstellung kommerzieller Home Entertainment Systeme in Abschnitt 2.2.2, gliedert. 

Im darauf folgenden Abschnitt 2.3 werden Programme aus dem Open Source- 

Bereich vorgestellt. Auch dieser wird in Abschnitt 2.3.1 in die Betrachtung einzelner 

Programme und in Abschnitt 2.3.2 in die Vorstellung von Home Entertainment 

Systemen in Abschnitt 2.3.2 aufgeteilt. 

Abschnitt 2.4 stellt einige Ansätze aus der Forschung vor. Dazu werden das TV- 

Anytime Forum und WWICE betrachtet. 

Einige der hier vorgestellten Programme greifen zum Sammeln von EPG-Informationen 

auf die XMLTV-Werkzeuge, die ihre Daten aus dem Internet beziehen, und 

die Anwendung nxtvepg zurück, welche die analogen TV-Signale auswertet. Diese 

werden in Abschnitt 4.2.3 bzw. Abschnitt 4.2.4 ausführlich vorgestellt, da sie dem 

in dieser Arbeit entwickelten EPG ebenfalls als Quellen dienen. 

2.1 Fernseher und Settop-Boxen 

Mittlerweile bietet jeder Fernseher durch Zugriff auf den Videotext [ETS97c] die 

Möglichkeit Informationen über das Programm eines Senders bereitzustellen. Die 

Daten werden nicht lokal gespeichert, sondern von den Rundfunkanstalten als Bilddaten 

mit dem Fernsehsignal in einer Endlosschleife übertragen. Bei Bedarf können 

einzelne Seiten durch Angabe der gewünschten Seitennummer abgerufen und 

angezeigt werden. Die Programm-Informationen sind zudem, wie Abbildung 2.1 

zeigt, in der Regel auf den jeweiligen Sender beschränkt. Für einen kompletten 

Überblick über das Programm aller Sender muss der Videotext eines jeden Kanals 

aufgerufen werden. Diese Daten können nur angezeigt, aber nicht durchsucht 

werden. 

Heutzutage bieten manche Fernseher zudem noch Unterstützung für nexTView- 

EPG [ETS97b]. Diese Daten werden von einem Dienstleister über die Austastlücke 

des Videotextes übertragen. Sie enthalten Informationen für mehrere Sender 

und werden je nach Land von einem oder zwei Sendern übertragen. Der Nachteil 

besteht darin, dass der entsprechende Kanal für eine gewisse Zeit eingestellt 

bleiben muss um die Daten zu sammeln. Abbildung 2.2 zeigt die Darstellung der 

Informationen bei einem Grundig Sydney SE7240 Fernsehgerät. Hier gehen die 

Daten nach dem Abschalten des Gerätes verloren. 

Settop-Boxen dienen dem Dekodieren von digitalen TV-Signalen (Digital Video 

Broadcast (DVB)). Diese Signale enthalten auch Programm-Informationen, die 

von den Settop-Boxen gesammelt und angezeigt werden. Auch hier gehen die In-

2.1. FERNSEHER UND SETTOP-BOXEN 

Abbildung 2.1: Der Videotext der ARD. Auf der ersten Seite wird angezeigt, was 

aktuell und im Anschluss gesendet wird (links). Auf weiteren Seiten erhält man 

den Überblick über das Tagesprogramm (rechts). 

Abbildung 2.2: Der TV Guide des Grundig Sydney SE7240 bietet die Möglichkeit 

Informationen nach vorgegebenen Kriterien zu sortieren. 

11


12 

Abbildung 2.3: InterVideo’s MSIPVS liegt der MSI VOX USB2.0 TV Box [MSIC] 

bei. Die Abbildung zeigt das Live TV-Bild (links) und den EPG (rechts), der die 

Webseite von tvtv.de anzeigt. 

formationen nach dem Ausschalten oftmals noch verloren. Moderne Settop-Boxen 

können mittlerweile jedoch auch Fernsehsendungen sowie EPG-Informationen auf 

internen Festplatten ablegen. 

Die hier vorgestellten Mechanismen können die Informationen oftmals nicht permanent 

speichern, sodass bei jedem Anschalten des Fernsehers oder der Settop- 

Box die Daten erneut gesammelt werden. Zudem sind zur Unterstützung von Live 

TV, einem Videorekorder und eines EPG oftmals Kombinationen dieser Geräte 

notwendig. 

2.2 Kommerzielle Anwendungen und Systeme 

Im Bereich der kommerziellen Anwendungen und Systeme gibt es eine Vielzahl an 

Programmen, die Zugriff auf TV-Karten bieten oder EPG-Informationen anzeigen. 

Im Folgenden wird eine kleine Auswahl davon vorgestellt. 

2.2.1 Alleinstehende Programme 

Allen TV-Karten liegen auf ihre Bedürfnisse zugeschnittene Programme bei. Diese 

bieten zumindest die Möglichkeit TV-Programme anzusehen und währenddessen 

aufzuzeichnen. Vielfach ist auch ein Videorekorder verfügbar um Sendungen zu 

bestimmten Zeiten aufzunehmen. Dabei wird auf nur eine Karte zur Aufnahme 

zugegriffen. Wenn ein EPG vorhanden ist, zeigt dieser die Internetseite eines entsprechenden 

Providers an, wie in Abbildung 2.3 zu sehen ist. Dieser Mechanismus 

unterstützt jedoch nicht das Programmieren von Aufnahmen durch die Auswahl 

einer Sendung im EPG. Außerdem ist mit diesen Programmen weder die Nutzung

2.2. KOMMERZIELLE ANWENDUNGEN UND SYSTEME 

Abbildung 2.4: Kann eine Sendung mangels freier TV-Ressourcen nicht aufgezeichnet 

werden, bietet die Windows Media Center Edition die manuelle Auflösung 

des Konflikts an. (Bildquelle: [Thu]) 

im Netzwerk verteilter Ressourcen noch der gemeinsame Zugriff auf eine TV-Karte 

durch mehrere Anwendungen möglich. 

Für die gesteckten Ziele sind diese Programme nicht verwendbar, da sie nicht den 

gemeinsamen Zugriff auf Ressourcen offerieren. Des Weiteren bieten sie keine Interaktion 

zwischen Videorekorder, Live TV und EPG. 

2.2.2 Home Entertainment Systeme 

Im Bereich der kommerziellen Software existieren mehrere Implementierungen 

von Home Entertainment Systemen. Ein Testbericht verschiedener Media Center 

Programme für Microsoft Windows findet sich z.B. in [Zot05]. Die beiden interessantesten 

Vertreter werden im Folgenden vorgestellt. 

2.2.2.1 Windows Media Center Edition 

Die Windows Media Center Edition 2005 (MCE) [Micb] ist ein Home Entertainment 

System von Microsoft. Es unterstützt sowohl Live TV als auch Videorekorderfunktionalität. 

Darüber hinaus enthält es eine elektronische Programmzeitschrift, 

die einen Überblick über das TV-Programm gewährt. 

Als TV-Quelle werden digitale und analoge TV-Karten unterstützt, wobei der Zugriff 

nicht auf eine einzige TV-Karte beschränkt ist. Der Videorekorder verteilt 

Aufnahmen auf vorhandene TV-Karten und erkennt, wenn eine Sendung mangels 

freier Ressourcen nicht aufgenommen werden kann. Diesbezüglich wird eine manuelle 

Konfliktauflösung angeboten, mit deren Hilfe ggf. Ressourcen durch Löschen 

einprogrammierter Aufnahmen freigegeben werden können (siehe Abbildung 

2.4). 

Der EPG ist von einem Service-Provider gespeist, auf den per Internet zugegrif- 

13


14 

Abbildung 2.5: Der EPG der Microsoft Windows Media Center Edition stellt das 

Tagesprogramm als Tabelle dar, wobei die Zeilen das Programm der einzelnen Sender 

enthalten. (Bildquelle: [Thu]) 

Abbildung 2.6: Der Videorekorder der MS MCE bietet die Möglichkeit programmierte 

Aufnahmen nach verschiedenen Kriterien zu filtern und zeigt zugehörige 

EPG-Informationen an. (Bildquelle: [Thu]) 

fen wird. Die Daten werden anschließend lokal gespeichert. Als Quelle für EPG- 

Informationen ist die Media Center Edition auf den Service-Provider beschränkt, 

alternative Quellen werden nicht unterstützt. Die Programm-Informationen werden, 

wie in Abbildung 2.5 gezeigt, in einer Tabelle dargestellt, wobei neben einer 

erweiterten Beschreibung zusätzlich das Live TV-Bild des jeweils ausgewählten 

Senders sichtbar ist. Darüberhinaus werden EPG-Informationen im Videorekorder 

bzgl. einer Aufnahme dargestellt (siehe Abbildung 2.6). Außerdem können die 

EPG-Daten nach vorgegebenen Kriterien gefiltert werden, z.B. nach Kategorien, 

Stichworten, etc.. Unterstützt wird ebensfalls das Programmieren einer Aufnahme 

durch Auswahl einer Sendung im EPG, wobei auch eine Serie zu unterschiedlichen 

Zeiten und auf verschiedenen Sendern basierend auf EPG-Informationen automatisch 

aufgenommen werden kann. 

Die Windows Media Center Edition ermöglicht selbst keinen Zugriff auf entfernte 

Ressourcen, wodurch die Möglichkeit des Mehrbenutzer-TV im Sinne dieser Arbeit 

nicht gegeben ist. Die Netzwerkfunktionalität wird mittels zusätzlicher Hard-

2.2. KOMMERZIELLE ANWENDUNGEN UND SYSTEME 

Abbildung 2.7: Der EPG von SageTV2. Auch hier werden die Informationen in 

Tabellenform angezeigt. (Bildquelle: [Fre]) 

ware realisiert, welche Media Center Extender [Mica] genannt wird. Diese Hardware 

dient jedoch lediglich dem Zugriff auf eine Media Center Edition-Anwendung 

um deren graphische Benutzeroberfläche auf einem angeschlossenen Fernseher anzuzeigen 

und Eingaben über eine Fernbedienung an diese zurückzuleiten. So können 

auf dem PC verfügbare Multimedia-Inhalte zugegriffen werden. Die Microsoft 

Media Center Edition kann sich jedoch dadurch nicht entfernter Ressourcen bedienen. 

2.2.2.2 SageTV2 

SageTV2 [Fre] von Frey Technologies ist ein kommerzieller Videorekorder, der 

mehrere TV-Karten unterstützt. Ebenso bietet er Unterstützung für Live TV und 

enthält einen integrierten EPG. 

Die TV-Quellen können dabei lokal oder im Netzwerk verteilt sein. Zum Ansprechen 

der entfernten TV-Quellen stellt Frey Technologies das Programm SageTV 

Recorder zur Verfügung um die entfernte TV-Karte zu nutzen. Aufnahmen werden 

jedoch auf dem entfernten Rechner abgelegt und müssen über ein entsprechendes 

Netzwerk-Dateisystem zugängig gemacht werden. 

Für die USA und Kanada werden EPG-Daten von speziellen Service-Providern 

bereitgestellt. Außerhalb dieser Gebiete ist nur die Verwendung der XMLTV-Programme 

[XML] möglich. Sie dienen dem in dieser Arbeit entwickelten EPG ebenfalls 

als Quelle und werden in Abschnitt 4.2 genauer betrachtet. Die Daten für das 

Tagesprogramm werden in einer Tabelle angezeigt (siehe Abbildung 2.7). Hieraus 

können Aufnahmen direkt im Videorekorder einprogrammiert werden. SageTV2 

bietet außerdem die Möglichkeit Aufnahmen automatisch zu programmieren, indem 

man bestimmte Kriterien bezüglich der EPG-Informationen festlegt. Treffen 

die Angaben bei einer Sendung zu, wird für diese Sendung von selbst eine Aufnahme 

getätigt. 

15


16 

2.2.2.3 Fazit 

Beide in diesem Abschnitt vorgestellten Home Entertainment System können lediglich 

von einer Quelle EPG-Informationen sammeln. Diese werden von einem 

speziellen Dienst zur Verfügung gestellt, der bei SageTV ausschließlich auf Nordamerika 

beschränkt ist. Für den in dieser Arbeit entwickelten EPG soll das Sammeln 

der Daten von mehreren unterschiedlichen Quellen möglich sein. Auf die 

verfügbaren Informationen kann ausschließlich die lokale Anwendung zugreifen, 

ein Austausch der Informationen über das Netzwerk ist nicht möglich. Ein Ziel 

dieser Arbeit besteht jedoch darin den EPG über das Netzwerk ansprechen zu können 

um anderen Anwendungen Daten zur Verfügung zu stellen bzw. von diesen zu 

erfragen. 

Die TV-Funktionaliät beider Home Entertainment Systeme bietet die Unterstützung 

mehrerer lokal vorhandener TV-Quellen. SageTV2 kann zudem auf im Netzwerk 

verteilte TV-Ressourcen zugreifen. Es wird jedoch nur ein einzelner Benutzer 

unterstützt, wodurch eine Beschränkung der Kontrolle über eine TV-Karte bei Zugriff 

mehrerer Anwendungen für LiveTV nicht gegeben ist. Für die Erweiterung 

der Multimedia-Box in dieser Arbeit soll der Zugriff auf im Netzwerk verteilte 

TV-Ressourcen, im Gegensatz zur Windows Media Center Edition, ohne spezielle 

Hardware möglich sein. Weiterhin sollen ebenfalls mehrere analoge und digitale 

TV-Quellen angesprochen und zusätzlich der kontrollierende Zugriff bei Live TV 

automatisch geregelt werden können. 

Zur Aufnahme einer Sendungen bieten beide Home Entertainment System sowohl 

eine manuelle Programmierung als auch das Auswählen einer aufzunehmenden 

Sendung im EPG. Zudem können Aufnahmen automatisch basierend auf ihren 

EPG-Informationen wiederholt werden. Diese Funktionalität soll ebenfalls für die 

Multimedia-Box realisiert werden. 

2.3 Open Source Anwendungen 

Im Bereich der Open Source-Software existieren auch viele unterschiedliche Programme 

zum Zugriff auf TV-Quellen oder EPG-Daten. Diese reichen von einfachen 

Anwendungen zum Ansprechen einer TV-Karte bis zu komplexen Home Entertainment 

Systemen, die viele Funktionalitäten vereinen. 

2.3.1 Alleinstehende Programme 

Im Folgenden werden einzelne kleine Programme aus dem Open Source-Bereich 

betrachtet.

2.3. OPEN SOURCE ANWENDUNGEN 

Abbildung 2.8: Durch die Unterstützung des Programmes nxtvepg lassen sich bei 

xawtv EPG-Informationen zur aktuellen Sendung anzeigen. 

2.3.1.1 xawtv 

xawtv [Knob] ist eine Anwendung zum Bedienen von analogen TV-Karten. Eine 

Liste unterstützter Karten ist auf der Webseite verfügbar. Zum Zeitpunkt dieser 

Arbeit wurde damit begonnen Unterstützung für digitale TV-Karten zu integrieren. 

Das Programm kann die entsprechenden Videodaten anzeigen oder in eine Datei 

auf die Festplatte schreiben. Es bietet keine Unterstützung zur zeitlich gesteuerten 

Aufnahme und der Zugriff ist auf eine lokale TV-Karte beschränkt. Weiterhin ist 

es mit xawtv nicht möglich auf eine belegte TV-Quelle zuzugreifen, sodass zwei 

Instanzen des Programmes nicht die gleiche verwenden können. 

xawtv selbst bietet keine EPG-Funktionalität, kann jedoch in Verbindung mit nxtvepg 

[Zoe] den Titel der aktuellen Sendung anzeigen (siehe Abbildung 2.8). 

2.3.1.2 vcr - Kommandozeilen-Videorekorder 

vcr [Avo] ist eine Kommandozeilen-Applikation zur Aufnahme von TV-Sendungen, 

die ebenfalls nur analoge TV-Karten untersützt. Im Gegensatz zu xawtv ist keine 

Unterstützung für digitale TV-Karten vorgesehen. Sie dient ausschließlich zur Aufnahme 

von TV-Sendungen, d.h. dass mit diesem Programm Live TV nicht möglich 

ist. Man kann die Laufzeit einer Aufzeichnung angeben, sodass in Verbindung mit 

cron [Vix93] auch das Aufnehmen zu bestimmten Zeiten realisiert werden kann. 

Das Programm vcr bietet nur die Möglichkeit eine lokale TV-Karte anzusprechen 

und enthält keine Konflikterkennung. Weiterhin fehlt die Möglichkeit des Zugriffs 

zweier Instanzen von vcr auf die gleiche TV-Quelle. Das Programm selbst unterstützt 

keinen EPG, sodass keine Informationen zu Aufnahmen angezeigt oder 

gespeichert werden können. 

17


18 

Abbildung 2.9: Das Hauptmenü von WebVCR+ zeigt alle einprogrammierten Sendungen 

inklusive vorhandener EPG-Informationen. (Bildquelle: [Web]) 

2.3.1.3 WebVCR+ 

WebVCR+ [Web] bietet selbst keine Möglichkeit zur Aufnahme, sondern dient nur 

als graphische Benutzeroberfläche für externe Programme wie z.B. vcr. Es verbindet 

die Aufnahme-Eigenschaften des Programmes mit einem EPG. Als Quelle 

für Programm-Informationen dienen die XMLTV-Programme [XML]. Dadurch ist 

sowohl die Aufnahme einer Sendung durch deren Auswahl im EPG als auch die 

Anzeige entsprechender Informationen zu programmierten Aufnahmen möglich 

(siehe Abbildung 2.9). 

Da zur Aufnahme auch das Programm vcr verwendet wird, unterliegt WebVCR+ 

bei einem Zugriff auf TV-Quellen den in Abschnitt 2.3.1.2 schon erwähnten Beschränkungen. 

2.3.1.4 Fazit 

Die in diesem Abschnitt vorgestellten Programme bieten lediglich Unterstützung 

für eine einzelne lokale TV-Karte. Da diese Anwendungen direkt über den Treiber 

mit den verwendeten Hardware kommunizieren ist ein gemeinsamer Zugriff mehrerer 

Anwendungen auf eine TV-Quelle nicht möglich. Weiterhin fehlt die Möglichkeit 

der Verwendung im Netzwerk verteilter TV-Karten, wodurch eine Betrachtung 

der Zugriffskontrolle, wie sie in dieser Arbeit realisiert werden soll, entfällt. 

Die Anzeige von EPG-Informationen bei Live TV soll nicht nur, wie bei xawtv, 

auf den Titel der aktuellen Sendung beschränkt sein, sondern bei Bedarf alle zu der 

Sendung vorhandenen Informationen anzeigen.


Abbildung 2.10: Während Live TV werden bei VDR EPG-Informationen zur momentan 

laufenden und folgenden Sendung eingeblendet. (Bildquelle: [Sch]) 

2.3.2 Home Entertainment Systeme 

Auch im Open Source-Bereich existieren verschiedene Home Entertainment Systeme, 

deren bekannteste Vertreter im Folgenden vorgestellt werden. 

2.3.2.1 VDR 

Klaus Schmiedinger’s Video Disk Rekorder (VDR) [Sch] ist ein Projekt, in dem 

eine Software entwickelt wurde, mit deren Hilfe ein PC zu einem digitalen Satellitenreceiver 

inklusive eines Video Disk Rekorders erweitert wird. Dabei werden 

mehrere DVB-Karten gleichzeitig unterstützt, wovon mindestens eine Karte eine 

’full featured’-Karte mit Videoausgang sein muss. Solche Karten besitzen einen 

eingebauten MPEG2-Dekoder, über den die Video-Daten an ein angeschlossenes 

Anzeige-Gerät übertragen werden. 

Der VDR bezieht EPG-Daten aus dem DVB-Datenstrom und legt sie im Hauptspeicher 

ab. Diese Daten können nach folgenden Kriterien angezeigt werden: 

• Sortiert nach Zeit, wobei Informationen zu momentan laufenden oder unmittelbar 

nachfolgenden Sendungen angezeigt werden (siehe Abbildung 2.10). 

• Sortiert nach Kanal, wobei Informationen zu Sendungen des entsprechenden 

Tagesprogramms angezeigt werden (siehe Abbildung 2.11). 

Außerdem können zu einzelnen Sendungen erweiterte Informationen eingeblendet 

werden, was ebenfalls in Abbildung 2.11 zu sehen ist. Aufnahmen können entweder 

manuell oder über den EPG programmiert werden. Dazu werden auch die entsprechenden 

EPG-Informationen angezeigt. Bei Konflikten verteilt der VDR die 

Aufnahmen auf die verfügbaren Karten. Diesen kann vom Benutzer eine Priorität 

zugewiesen werden, dass bei einer Überschneidung diejenige mit der höchsten 

Priorität gestartet wird. Die Benutzeroberfläche des Videorekorders sowie die Anzeige 

einprogrammierter Aufzeichnungen sind in Abbildung 2.12 zu sehen. 

19


20 

Abbildung 2.11: Der EPG von VDR zeigt das Tagesprogramm eines Senders als 

Liste(rechts). Zu einzelnen Sendungen kann man bei Bedarf zusätzliche Informationen 

abrufen (rechts). (Bildquelle: [Sch]) 

Abbildung 2.12: Die Abbildung zeigt den Videorekorder des VDR. Das linke Bild 

zeigt die Eingabemaske zum Programmieren einer Aufnahme. Rechts sieht man 

einprogrammierte Aufnahmen im Überblick. (Bildquelle: [Sch])


Der VDR besitzt eine Plugin-Struktur, mit deren Hilfe Funktionalität nachgerüstet 

werden kann. Im Folgenden werden ausgewählte Plugins vorgestellt. Eine Liste 

verfügbarer Plugins kann auf der Webseite des Projekts [Sch] eingesehen werden. 

• Das von Andreas Kool entwickelte Plugin AnalogTV [Koo] ermöglicht den 

Zugriff auf analoge TV-Karten sowie das Einbinden von nxtvepg [Zoe]. 

• Das Plugin Client/Server Streaming von Sascha Volkenandt [Vol] erweitert 

den VDR um Netzwerkfunktionalität. Es ermöglicht den Zugriff auf 

im Netzwerk verteilte VDR-Applikationen und auf somit bereitgestellte TV- 

Karten. Als zugreifende Anwendung kann entweder wiederum eine VDR- 

Applikation oder ein Streaming-Client wie z.B. mplayer [MPl] verwendet 

werden. Die Übertragung der Kontrolldaten, z.B. zum Setzen eines Kanals, 

geschieht über das selbst implementierte Protokoll VTP (Video Transfer Protokoll), 

während die Übertragung von Multimedia-Daten mittels eines einfachen 

HTTP-Streaming-Protokolls vorgenommen wird. Dies erlaubt den Zugriff 

auf im Netzwerk verteilte TV-Quellen. Im Falle von Live TV erhält der 

Client, welcher auf die entfernte TV-Karte zugreift, die Kontolle über die 

TV-Karte und kann den Kanal wechseln. Die zu der TV-Karte lokale Anwendung 

kann den Kanal lediglich innerhalb des eingestellten Kanal-Bouquets 

wechseln. Sollte die lokale Anwendung jedoch gerade eine Sendung aufzeichnen, 

kann der Kanal nicht gewechselt werden. In dem Fall, dass sowohl 

der Client als auch der Server für eine Aufnahme die gleiche TV-Karte verwenden 

wird keine Zugriffsbeschränkung vorgenommen. Beide Anwendungen 

dürfen den gewünschten Kanal einstellen. Dies hat den Nachteil, dass die 

zuerst gestartete Aufnahme unterbrochen wird. EPG-Informationen werden 

ebenfalls übertragen, jedoch nicht innerhalb des MPEG-Stroms. Sie werden 

nach dem Verbinden mit der Server-Anwendung von dieser erfragt. 

• Christian Wieninger hat durch die Realisierung des Plugins EPGSearch [Wie] 

den VDR um eine Suche in den EPG-Daten erweitert. Damit können EPG- 

Daten nach verschiedenen Kriterien durchsucht sowie Aufnahmen auf Basis 

von EPG-Informationen automatisch programmiert werden. 

2.3.2.2 Freevo 

Freevo [Lag] ist ein in Python implementiertes Home Entertainment System, das 

zum Abspielen von Multimedia-Inhalten externe Programme, wie z.B. der Mediaplayer 

mplayer [MPl], verwendet. Es unterstützt mehrere lokale TV-Karten, von 

denen jedoch nur eine zur Aufnahme verwendet werden kann. Ein gemeinsamer 

Zugriff auf Ressourcen ist nicht möglich. Ebenso fehlt eine Netzwerkunterstützung, 

wodurch sich ein Mehrbenutzer-Szenario, wie für diese Arbeit angedacht, 

nicht realisieren lässt. Als TV-Quellen kommen hier sowohl analoge Karten als 

auch DVB-Karten zum Einsatz. 

Als EPG-Quelle dienen XMLTV und nxtvepg, deren Informationen in einer Tabellenansicht 

dargestellt werden (siehe Abbildung 2.13). Aufnahmen können auch 

hier entweder durch Auswahl im EPG oder manuell eingegeben werden. 

21


22 

Abbildung 2.13: Der EPG von Freevo zeigt EPG-Informationen in einer Tabellen- 

Übersicht an. (Bildquelle: [Lag]) 

2.3.2.3 MythTV 

MythTV [Ric] ist ein Projekt von Isaac Richards. Es bietet Unterstützung für mehrere 

TV-Karten, sowohl analog als auch digital. Die Karten können über das Netzwerk 

verteilt sein, was durch die Aufteilung von MythTV in Front- und Backend 

realisiert wird. Das Backend übernimmt dabei Funktionalitäten wie das Kommunizieren 

mit der entsprechenden Hardware oder das Aufnehmen von Sendungen. 

Das Frontend verbindet sich mit dem Backend und bietet damit die graphische 

Benutzeroberfläche zur Steuerung der Anwendung. Der verteilte Zugriff auf TV- 

Ressourcen geschieht dann über das Verbinden mehrerer Backends untereinander. 

Dabei muss immer ein Master-Backend vorhanden sein, mit dem sich das Frontend 

verbindet und das alle Informationen über verfügbare TV-Karten enthält. Mit 

MythTV ist es nicht möglich, dass eine TV-Quelle von dem Videorekorder und 

Live TV gleichzeitig verwendet werden kann. Im Falle einer Aufnahme wird der 

Zugriff von anderen Anwendungen verweigert, ebenso wird Live TV die TV-Karte 

entzogen, sollte diese als Quelle für eine Aufnahme verwendet werden. 

Als EPG-Quelle dienen XMLTV oder nxtvepg, deren Daten in einer MySQL- 

Datenbank [MyS] abgelegt werden. Die gesammelten Informationen werden tabellarisch 

dargestellt und dienen der Information über die aktuelle Sendung bei 

Live TV (siehe Abbildung 2.14). MythTV bietet auch die Möglichkeit nach Titeln 

zu suchen, die mit einem ausgewählten Buchstaben beginnen. 

In MythTV kann man ebenfalls Aufnahmen mittels des EPG oder manuell programmieren. 

Durch die Anzeige überlappender Aufnahmen wird die Auswahl einer 

Aufzeichnung zugelassen, wenn auftretende Konflikte aufgelöst werden sollen. 

Die entsprechende graphische Benutzeroberfläche ist in Abbildung 2.15 zu sehen. 

2.3.2.4 Fazit 

Alle in diesem Abschnitt vorgestellten Home Entertainment Systeme bieten einen 

EPG zur Anzeige von Programm-Informationen. Dieser kann von unterschiedli-


Abbildung 2.14: Der EPG von MythTV zeigt EPG-Informationen bei Live TV 

(links) als auch in einer Tabelle für alle Kanäle an (rechts). (Bildquelle: [Ric]) 

Abbildung 2.15: In dieser Eingabe können bei MythTV Konflikte aufgelöst werden. 

(Bildquelle: [Ric]) 

23


24 

chen Quellen gespeist werden, wobei jedoch nur eine gleichzeitig abgefragt werden 

kann. Für die Multimedia-Box soll ebenfalls die Verwendung von XMLTV, 

nxtvepg und DVB als EPG-Quellen realisiert werden, wobei deren gleichzeitige 

Verwendung unterstützt werden soll. 

MythTV und VDR bieten zudem die Möglichkeit, auf diese Daten per Netzwerk 

zuzugreifen. Bei MythTV beschränkt sich dies jedoch auf den Zugriff mehrerer 

Anwendungen auf die gleiche MySQL-Datenbank. Bei VDR werden die Informationen 

bei einem Zugriff auf eine entfernte TV-Karte vom Server zum Client 

übertragen. Die verteilt laufenden Anwendungen sind jedoch auf die Verwendung 

der gleichen Quelle beschränkt und können fehlende Informationen nicht erkennen 

und somit erfragen. 

Die TV-Funktionalität der vorgestellten Home Entertainment Systeme unterstützt 

den Zugriff auf mehrere lokale TV-Karten. Lediglich MythTV und VDR können 

auch auf im Netzwerk verteilte TV-Karten zugreifen, wobei VDR zusätzlich den 

gemeinsamen Zugriff mehrerer Anwendungen auf eine TV-Quelle erlaubt. MythTV 

untersützt dies nicht, sondern gestattet nur die exklusive Verwendung einer 

TV-Quelle. Beide Anwendungen räumen dem Videorekorder eine höhere Prioriät 

als Live TV ein, d.h. sobald eine Aufnahme startet, übernimmt der Videorekorder 

die Kontrolle über die entsprechende TV-Karte und wechselt den Kanal. Die Live 

TV-Anwendungen können nun bei VDR nicht mehr den Kanal wechseln, bzw. ihr 

wird bei MythTV die TV-Karte entzogen. 

Die TV-Funktionalität der Multimedia-Box soll ebenfalls mehrere lokale sowie im 

Netzwerk verteilte, analoge und digitale TV-Quellen nutzen können. Dazu zählt 

auch die Realisierung eines gemeinsamen Zugriffs mehrerer Anwendungen und 

die automatische Regelung deren Kontrollmöglichkeiten. Dabei soll im Falle von 

Live TV nicht davon ausgegangen werden, dass diese lediglich von einer einzelnen 

Person gesteuert werden, sondern mehrere Benutzer durch ihre Anwendung auf die 

TV-Karten zugreifen. Dies erfordert das Festlegen einer Regel, welche Anwendung 

berechtigt ist einen Kanalwechsel vorzunehmen. 

2.4 Forschungprojekte 

Im Bereich der Forschung existieren verschiedene Ansätze die Möglichkeiten der 

Übertragungstechniken des Fernsehens zu erweitern oder vorhandene Technologien 

in verschiedene TV-Szenarien zu integrieren. Ausgewählte Projekte werden im 

Folgenden vorgestellt. 

2.4.1 TVAnytime-Forum 

Das TV-Anytime Forum (TVAF) [TVA] ist eine gemeinnützige Vereinigung von 

Organisationen, deren Arbeit in verschiedene technische und nicht-technische Arbeitsgruppen 

unterteilt ist. Das TVAF entwickelt Spezifikationen für speicherba-

sierte A/V-Dienste wie z.B. Personal Digital Recorder. 

2.5. ZUSAMMENFASSUNG 

Ziel des TVAF ist die Forcierung der Entwicklung von TV inklusive der damit verbundenen 

Multimedia-Diensten und deren Verwaltung auf Speichermedien, unabhängig 

von der Art der Verbreitung. Dies ist in zwei Phasen aufgeteilt. In der ersten 

Phase sollen Spezifikationen erstellt werden um Daten aus TV-Übertragungen und 

Online-Quellen auf lokalen Speichermedien zu verwalten. In der zweiten Phase 

sollen diese Daten innerhalb eines Heimnetzwerks verfügbar gemacht werden. 

Eine Implementierung dieser Konzepte wurde durch das STORit-Projekt [STO02] 

realisiert. Als TV-Quellen dienen sowohl digitale Quellen als auch das Internet. Die 

entwickelte STORit-Box beinhaltet u.a. einen Videorekorder und einen EPG, wodurch 

Aufnahmen aus dem EPG heraus programmiert werden können. Als Quelle 

für den EPG dient der digitale Fernsehstrom. Die STORit-Box besitzt jedoch keine 

Netzwerk-Unterstüzung, womit ein Zugriff auf verteilte Ressourcen entfällt. 

2.4.2 WWICE 

Das Window to the World of Information, Communication and Entertainment (WWI- 

CE) [BBE + 00] System ist eine Architektur für digitale innerhäusliche Netzwerke 

(In-Home digital networks - IHDN). Das Hauptaugenmerk liegt dabei auf einer 

Architektur für verteilte digitale Audio/Video-Systeme. Der Zugriff auf Geräte soll 

für den Benutzer transparent sein, d.h. er soll sich nicht darum kümmern müssen, 

wo die Daten gespeichert sind oder in welchem Raum sich das von ihm benutzte 

Gerät befindet. 

Das System gliedert sich in vier Ebenen. Auf der untersten Ebene, der Plattform- 

Ebene, wird die Abstraktionen für die verwendeten Geräte bereitstellt. Die Middleware-Ebene 

stellt die Funktionalität zum einfachen Realisieren von Anwendungen 

bereit. Auf der Anwendungs-Ebene wird die Implementierung der Benutzer-Funktionalität 

bereitgestellt. Die höchste Ebene ist die UI-Ebene, auf der die graphische 

Benutzerschnittstelle implementiert wird. 

WWICE bietet Zugriff auf mehrere lokale oder im Netzwerk verteilte TV-Ressourcen, 

wie es für die Multimedia-Box realisiert werden soll. Weiterhin wird der 

Zugriff mehrerer Anwenungen auf die gleiche TV-Ressource unterstützt. Über eine 

Regelung der Kontrolle von Anwendungen bei einem gemeinsamen Zugriff auf 

eine TV-Quelle konnte nichts in Erfahrung gebracht werden. 

2.5 Zusammenfassung 

Die alleinstehenden Programme unterstützen lediglich den Zugriff auf eine einzige 

lokale TV-Karte. Sie bieten nicht alle gewünschten Funktionalitäten in Bezug auf 

Live TV, Videorekorder und EPG, sondern stellen lediglich Teile davon bereit. Des 

Weiteren ist ein gemeinsamer Zugriff mehrerer solcher Anwendungen auf eine TV- 

Karte nicht möglich. 

25


26 

Die vorgestellten Home Entertainment Systeme bieten alle einen EPG, Videorekorder 

sowie die Möglichkeit des Live TV. Die EPG-Daten werden dazu verwendet 

um Aufnahmen zu programmieren und Informationen über das Programm eines 

Senders zu liefern. Alle Programme bieten jedoch nur die Auswahl einer einzigen 

zu verwendenden EPG-Quelle, sodass ein gleichzeitiges Sammeln von Daten 

unterschiedlicher Quellen nicht möglich ist. Weiterhin besteht keine Möglichkeit 

Lücken in den EPG-Daten zu erkennen und fehlende Informationen bei im Netzwerk 

laufenden Anwendungen zu erfragen. 

Außerdem bieten alle Home Entertainment Systeme Unterstützung für mehrere lokale 

TV-Karten. Die meisten können zudem im Netzwerk verteile TV-Quellen nutzen. 

Ein gemeinsamer Zugriff auf eine dieser Ressourcen durch Live TV und den 

Videorekorder wird von den wenigsten Programmen unterstützt. Dann wird entweder 

Live TV die TV-Karte entzogen und für den Videorekorder verwendet oder 

letzterer erhält die Kontrolle über die Karte und blockiert somit den Kanalwechsel, 

bis die Aufnahme endet. 

Alle Anwendungen sind so ausgelegt, indem sie bei Live TV davon ausgehen, dass 

dies lediglich von einem Benutzer verwendet wird. Dies bedeutet, dass bei einem 

gemeinsamen Zugriff mehrerer Live TV-Anwendungen diejenige die kontrollierenden 

Zugriff erhält, welche sich als letzte auf die TV-Quelle aufgeschaltet hat. In 

dieser Arbeit soll jedoch davon ausgenagen werden, dass Live TV-Anwendungen 

von unterschiedlichen Benutzern verwendet werden. Dabei soll derjenige die Kontrolle 

erhalten, der als erster eine TV-Karte angefordert hat, was von keiner der 

vorgestellten Anwendungen unterstützt wird.

Kapitel 3 

Netzwerk-Integrierte Multimedia 

Middleware 

Die Netzwerk-Integrierte Multimedia Middleware (NMM) [LRS02] wird am Lehrstuhl 

für Computergraphik an der Universität des Saarlandes entwickelt. NMM ist 

ein in C++ [Str98] implementiertes Open Source-Projekt zur Bereitstellung einer 

einheitlichen Middleware für den Entwurf von Multimedia-Programmen für das 

freie Betriebssystem Linux. Zum Zeitpunkt dieser Arbeit wurde damit begonnen 

NMM auch nach Microsoft Windows zu portieren. Der aktuelle Entwicklungsstand 

von NMM kann auf der Homepage des Projekts [NMM] nachgelesen werden. 

Ein zentraler Bestandteil von NMM ist die transparente Verwendung von im Netzwerk 

verteilten Soft- und Hardwarekomponenten. So kann eine in einem entfernten 

Rechner installierte TV-Karte transparent angesprochen werden, ohne dass sich der 

Programmierer um die Netzwerkkommunikation der beiden Rechner Gedanken 

machen muss. So ist es für den Entwickler irrelevant, ob die TV-Karte in dem lokalen 

oder entfernten Rechner eingebaut ist. Die Art und Weise, wie die TV-Karte 

angesteuert wird, ist aus Sicht des Programmierers identisch. 

NMM dient dabei auch als Schnittstelle zwischen dem Betriebssystem, das die 

im PC installierte Hardware anspricht, und den Programmen, die diese Hardware 

verwenden. Durch das Konzept der Middleware werden dem Programmierer 

abstrahierte Methoden zur Steuerung der Hardware zur Verfügung gestellt, dass 

dieser die benötigten Systemkomponenten nicht direkt ansprechen muss. Zudem 

ist die einfache Integration neuer und bereits existierender Technologien möglich, 

wodurch diese den Anwendungen zugänglich gemacht werden. 

Im Folgenden werden die für diese Arbeit relevanten Aspekte von NMM dargelegt. 

Abschnitt 3.1 stellt Grundlagen der Middleware vor, Abschnitt 3.2 beschreibt die 

benötigten Dienste, die durch NMM bereitgestellt werden. Abschließend folgt eine 

Einführung in das Home Entertainment System Multimedia-Box (MMBox), das 

auf Grundlage von NMM entwickelt wurde (siehe Abschnitt 3.3). 

27

KAPITEL 3. Netzwerk-Integrierte Multimedia Middleware 

28 

3.1 Grundlagen 

In diesem Abschnitt werden die in der Arbeit verwendeten, grundlegenden Elemente 

von NMM vorgestellt, die zur Realisierung der gewünschten Verarbeitung 

von Multimedia-Daten notwendig sind. 

3.1.1 Knoten 

Knoten übernehmen die funktionellen Aufgaben in NMM. Sie sorgen dafür, dass 

z.B. eine Datei ausgelesen oder Audio-Daten in ein bestimmtes Format umgewandelt 

werden. Jeder Knoten besitzt entweder einen Eingang, über den er Daten empfangen 

oder einen Ausgang, über den er Daten versenden kann, bzw. mindestens 

einen Ein- und Ausgang. Dabei wird zwischen verschiedenen Knotentypen unterschieden: 

Quellknoten Diese Knoten besitzen keine Eingänge, sondern genau einen Ausgang. 

Sie erstellen Multimedia-Daten oder lesen sie von entsprechenden Geräten. 

Senkeknoten Diese Knoten besitzen genau einen Eingang und empfangen Multimedia-Daten. 

Converterknoten Knoten dieses Typs besitzen einen Eingang und einen Ausgang. 

Sie konvertieren Multimedia-Daten von einem Format in ein anderes. 

Filterknoten Diese Knoten besitzen ebenfalls einen Eingang und einen Ausgang 

und verändern nicht das Format der Multimedia-Daten, sondern lediglich die 

Daten selbst. 

Demultiplexerknoten Diese Knoten besitzen einen Eingang und mehrere Ausgänge. 

Sie spalten z.B. Audio-Video-Ströme in einen Audio-Strom und einen 

Video-Strom auf. 

Multiplexerknoten Diese Knoten sind das Gegenteil eines Demultiplexerknotens. 

Sie besitzen mehrere Eingänge und einen Ausgang und verweben z.B. Audiound 

Video-Ströme zu einem Audio-Video-Strom. 

3.1.2 Jacks 

Zur Realisierung einer bestimmten Multimediaverarbeitung müssen die entsprechenden 

Knoten miteinander verbunden werden. Dies geschieht durch das Verbinden 

der Ein- bzw. Ausgänge von Knoten, die in NMM Jacks genannt werden. 

Eine solche Verbindung wird als Kante bezeichnet. Dabei wird ein output-jack eines 

Knotens mit genau einem input-jack des Folgeknotens verbunden. Jeder Jack 

kennt das Multimedia-Format, das er überträgt. Mögliche Parameter, die durch dieses 

Format spezifiziert werden, sind die Auflösung von Video-Daten oder die Bitrate 

kodierter Audio- oder Video-Daten. Details über Formate in NMM können

DVBRead- 

Node 

MPEGDemux- 

Node 

MPEGVideo- 

DecodeNode 

MPEGAudio- 

DecodeNode 

3.1. GRUNDLAGEN 

XDisplay- 

Node 

Playback- 

Node 

Abbildung 3.1: Flussgraph zur Wiedergabe der Audio- und Video-Daten einer 

digitalen TV-Quelle. 

in [Wam01] nachgelesen werden. Durch das Verbinden der Knoten entsteht ein 

gerichteter Graph, der in NMM Flussgraph genannt wird. 

In dieser Arbeit soll die Funktionalität für Live TV, einen Videorekorder und einen 

EPG, der Daten über eine digitale TV-Karte sammelt, realisiert werden. Zur Verarbeitung 

der Multimedia-Daten werden entsprechende Knoten benötigt um u.a. TV- 

Quellen anzusprechen oder Audio- und Video-Daten wiederzugeben, die NMM zu 

diesen Zwecken bereitstellt. Dies sind er DVBReadNode zum Zugriff auf digitale 

TV-Karten und der IVTVReadNode zum Ansteuern einer analogen WinTV PVR 

350 TV-Karte von Hauppauge [Hau]. Die Win TV PVR besitzt einen Hardware- 

MPEG-Encoder, mit dem die TV-Daten in das Videoformat MPEG-2 [ISO04] umgewandelt 

werden. Als Ausgabeformat liefern somit beide Knoten einen MPEG- 

2-Video-Strom, der im Falle des Videorekorders in eine Datei geschrieben und im 

Falle von Live TV angezeigt wird. Zum Schreiben von Dateien stellt NMM den 

GenericWriteNode zur Verfügung. Zur Wiedergabe der Audio- und Video- 

Daten muss der MPEG-2-Strom zuerst mittels des MPEGDemuxNode in einen 

Audio- und Video-Strom aufgeteilt werden. Der Audio-Strom wird mittels des 

MPEGAudioDecodeNode dekodiert und durch den PlaybackNode über eine 

Soundkarte ausgegeben. Der Video-Strom wird unter Verwendung des MPEG- 

VideoDecodeNode dekodiert und durch den XDisplayNode auf einem Bildschirm 

dargestellt. Abbildung 3.1 zeigt einen entsprechenden Graphen zur Darstellung 

der von einer digitalen TV-Quelle gelieferten Audio- und Video-Daten. 

3.1.3 Nachrichtensystem 

Zur Kommunikation der Knoten, sowohl mit der Anwendung als auch untereinander 

stellt, NMM das Nachrichtensystem (engl. Messaging-System) bereit. Dieses 

besteht aus zwei Arten von Nachrichten: 

• Multimedia-Daten werden in Quellknoten generiert und als Buffer über verbundene 

Jacks zu benachbarten Knoten bis zu einer Senke geschickt. 

• Nachrichten vom Typ composite event (CEvent) sind eine Sammlung von 

29


30 

Anwendung 

Netzwerk 

MP3Read 

Node 

Netzwerk 

MPEGAudio 

DecodeNode 

Methoden-Aufruf über Interface 

Datenfluss der Multimedia-Daten 

Netzwerk 

Playback 

Node 

Abbildung 3.2: Flussgraph zum Abspielen einer MP3-Datei. Die Anwendung und 

die Knoten liegen jeweils auf einem separaten Rechner. 

Nachrichten vom Typ Event und werden dazu verwendet das Knotenverhalten 

zu kontrollieren. Dies kann sowohl in-stream geschehen, d.h. die Nachrichten 

werden über die Jacks von Knoten zu Knoten geschickt als auch outof-band, 

d.h die Nachrichten werden von der Anwendung zum Knoten geschickt. 

3.1.4 Verteilte Flussgraphen 

In Abschnitt 3.1.2 wurde bereits erwähnt, dass die Verarbeitung von Multimedia- 

Daten in NMM durch einen gerichteten Graphen bewerkstelligt wird. Die Knoten 

eines NMM-Flussgraphen können dabei beliebig über das Netzwerk verteilt sein, 

was in Abbildung 3.2 dargestellt ist. Damit die Knoten jedoch weiterhin miteinander 

kommunizieren können, müssen die Events vor Versendung über das Netzwerk 

serialisiert und auf der Empfängerseite wieder deserialisiert werden. Dies bezeichnet 

die Transformation von Objekten in eine Zeichenkette und wieder zurück. Liegen 

zwei Knoten auf demselben Rechner und sind nicht im Netzwerk verteilt, wird 

auf Serialisierung verzichtet. Dies ermöglicht den für diese Arbeit geforderten Zugriff 

auf im Netzwerk verteilte Ressourcen. Eine ausführliche Beschreibung kann 

in [Rep03] nachgelesen werden. 

Eine Kontrolle der im Netzwerk verteilten Knoten ist immer noch notwendig um 

bei einer entfernten TV-Quelle den gewünschten Kanal zu setzen. Da jedoch ein 

einfacher Methodenaufruf über das Netzwerk nicht möglich ist, werden in NMM 

die schon vorgestellten out-of-band-Events verwendet. Um das Versenden der Events 

wiederum vor dem Programmierer zu verbergen, stellt NMM das System der Interfaces 

bereit. Dies ermöglicht dem Programmierer den gewohnten Methodenaufruf 

zur Steuerung der Knoten und ist zudem typsicherer als das manuelle Versenden 

der Events. 

Die Methoden, die über ein Interface verfügbar sein sollen, werden mit der Interface 

Definition Language [Loh03] festgelegt, woraus mit Hilfe eines IDL-Compilers

3.2. MIDDLEWARE-DIENSTE 

schließlich zwei Klassen erzeugt werden. Die Interface-Klasse stellt öffentliche 

Methoden bereit, die intern das korrespondierende Event erstellen. Die Implementierungs-Klasse 

dient dem Programmierer als Oberklasse, von der er seine Klasse 

ableitet. 

Dieser Mechanismus wird verwendet um auf entfernten TV-Karten den gewünschten 

Kanal zu setzen. Dazu implementiert jeder Knoten zum Zugriff auf eine TV- 

Quelle das ITVCard-Interface, über dessen setChannel(...)-Methode ein 

bestimmter Kanal eingestellt werden kann. 

Zusätzlich können bei einzelnen Knoten EventListener-Objekte für Events registriert 

werden. Somit ist eine Benachrichtigung möglich, wenn das entsprechende 

Event den Knoten erreicht oder von diesem versendet wird, worauf eine Anwendung 

entsprechend reagieren kann [Loh05]. Dieser Mechanismus wird zur Feststellung 

verwendet, ob während eines gemeinsamen Zugriffs mehrerer Anwendungen 

auf eine TV-Quelle eine Applikation den Kanal wechselt. 

3.2 Middleware-Dienste 

Für den Zugriff auf lokale und verteilte Ressourcen stellt NMM verschiedene Dienste 

zur Verfügung. 

3.2.1 Geräteverwaltung 

Die Bereitstellung von verfügbaren NMM-Knoten übernimmt die Geräteverwaltung, 

die in NMM Registry genannt wird. Diese erlaubt das Suchen, Reservieren 

und Instanziieren von verfügbaren Knoten auf lokalen oder entfernten Rechnern. 

Jeder Rechner stellt hierfür durch NMM eine serverregistry bereit. Für jeden Knoten 

speichert die Registry eine Knotenbeschreibung, die u.a. den Namen des Knotens 

sowie dessen bereitgestellte Interfaces enthält. Die Anwendung benutzt einen 

clientregistry um Anfragen an den Registry-Server zu schicken. Nach einer erfolgreichen 

Anfrage reserviert die Registry die gewünschten Knoten, welche schließlich 

entweder auf dem lokalen oder entfernten Rechner erstellt werden. 

Mit Hilfe dieser Architektur können auch eigene Dienste eingerichtet und somit 

ein einfaches Objekt um Netzwerktransparenz erweitert werden. Dazu muss eine 

Klasse, welche den Dienst realisiert, ein oder mehrere Interfaces implementieren. 

Ein Objekt dieser Klasse wird als NMM-Objekt bezeichnet. Dies kann nun als Service 

in einer entfernten Registry eingerichtet und per Interface abgefragt werden. 

Lokal wird eine Verbindung mit Hilfe eines Service-Proxys zu der entfernten Registry 

hergestellt und das entsprechende Interface angefordert um auf das Objekt 

zuzugreifen. 

Durch dieses Vorgehen wird in der vorliegenden Arbeit ermöglicht auf entfernten 

Rechnern einen EPG oder Videorekorder zur Verfügung zu stellen, womit sich eine 

Anwendung bei Bedarf verbindet um diese nutzen zu können. 

31


32 

Beispiel: 

Es folgt nun ein Beispiel, das veranschaulichen soll, wie ein einfaches Objekt um 

Netzwerktransparenz erweitert werden kann. Es wird zuerst gezeigt, wie ein Interface 

und anschließend das Objekt selbst definiert werden. Letzteres wird danach 

als Service auf einem entfernten Rechner registriert und angesprochen. 

Zuerst beschreibt man das Interface IObjekt mittels IDL: 

module IObjekt{ 

void eineMethode(); 

} 

Die durch den IDL-Compiler erzeugte Impl-Klasse IObjektImpl dient als Oberklasse 

für die Klasse Objekt: 

class Objekt: 

public IObjektImpl 

{ 

void eineMethode(); 

}; 

Auf der Gegenseite, dem entfernten Rechner, kann ein Objekt dieser Klasse nun 

als Service registriert werden: 

SReferenceManager::registerService("objekt_service", 

*Objekt); 

Die Verbindung zu der entfernten Registry des Rechners ’host’ wird nun mittels 

der ServiceProxy-Klasse hergestellt und das Interface IObjekt angefordert: 

ServiceProxy proxy; 

NMMObject *o = proxy.connectTo("host","objekt_service"); 

IObjekt *io = o->getParentObject() 

->getInterface(); 

Nun kann die Methode des Interface aufgerufen werden: 

io->eineMethode(); 

3.2.2 Session-Sharing 

Ein in dieser Arbeit gefordertes Szenario ist der gleichzeitige Zugriff von Anwendungen 

auf eine TV-Quelle. Dies erfordert einen Mechanismus in NMM, der die 

gemeinsame Verwendung von Knoten durch mehrere Flussgraphen erlaubt. Solch 

ein Dienst wird durch das Session-Sharing bereitgestellt [LRS03]. Eine Session 

ist eine Abstraktion für einen Flussgraphen mit bereits angeforderten und verbundenen 

Knoten. Innerhalb dieses Flussgraphen ist es möglich Knoten freizugeben, 

damit andere Flussgraphen diese mitverwenden können (zu sharen). Bei Verwendung 

eines Knotens durch einen einzigen Flussgraphen wird von einer exklusiven

(a) Laufende Session 

(b) Gesharte laufende Session 

Anfrage 

DVDRead 

Node 

DVDRead 

Node 

"audio0" 

MPEG 

Demux 

Node 

MPEG 

Demux 

Node 

"video" 

"audio1" 

Audio 

Decode 

Node 

Video 

Decode 

Node 

Audio 

Decode 

Node 

localhost 

Playback 

Node 

Display 

Node 

Playback 

Node 

localhost 

DVDRead 

DVDRead Node 

Node 

MPEG 

Demux 

Node 

3.2. MIDDLEWARE-DIENSTE 

"audio0" 

"video" 

Laufende Session "audio1" 

Audio 

Decode 

Node 

Video 

Decode 

Node 

Audio 

Decode 

Node 

Playback 

Node 

Display 

Node 

Playback 

Node 

Abbildung 3.3: 

Beispiel zur Funktionsweise des Session-Sharing. Die Anfrage nach einer unterschiedlichen 

Audiospur einer laufenden Session wird durch den Session-Sharing- 

Algorithmus auf die Verwendung eines Teilgraphen abgebildet. (Abbildung nach 

[LRS03]) 

Verwendung gesprochen. Das Mitverwenden eines Knotens durch einen zweiten 

Flussgrahen wird als gesharte Verwendung bezeichnet. Dies erfordert für jeden 

Knoten eines Flussgraphen die Angabe einer Anforderungs-Richtlinie um festzulegen, 

welche Knoten geshart verwendet werden dürfen. Folgende Modi sind möglich: 

Shared Fordere explizit einen schon erstellten Knoten zur gesharten Verwendung 

an. 

Exclusive Fordere den Knoten zur exklusiven Verwendung an. 

Exclusive or Shared Fordere einen Knoten zur exklusiven Verwendung an. Schlägt 

dies fehl, versuche einen Knoten zur gesharten Verwendung anzufordern. 

Shared or Exclusive Fordere zuerst einen Knoten zur gesharten Verwendung an. 

Schlägt dies fehl, fordere einen Knoten zur exklusiven Verwendung an. 

Exclusive then Shared Fordere einen Knoten zur exklusiven Verwendung an und 

gib ihn bei Erfolg für gesharte Verwendungen frei. 

Shared or Exclusive then Shared Fordere zuerst einen Knoten zur gesharten Verwendung 

an. Ist dies erfolglos, fordere den Knoten zur exklusiven Verwendung 

an und gib ihn bei Erfolg für gesharte Verwendungen frei . 

Exclusive then Shared or Shared Fordere zuerst einen Knoten zur exklusiven Verwendung 

an und gib ihn dann für gesharte Verwendungen frei. Ist dies erfolglos, 

fordere einen Knoten zur gesharten Verwendung an. 

Abbildung 3.3 zeigt die Funktionsweise des Session-Sharing anhand eines Flussgraphen 

zum Lesen einer DVD. Hier soll auf unterschiedliche Audiospuren der 

gleichen DVD zugegriffen werden. 

Teil a) der Abbildung zeigt die dazu notwendigen Graphen. Als laufende Session 

ist der komplette Graph zur Wiedergabe der Audio- und Video-Daten der DVD 

zu sehen. Dieser wurde bereits angefordert und gestartet. Der untere Graph soll 

33


34 

Abbildung 3.4: Die Abbildung zeigt zum einen die Hardware der Multimedia-Box 

(links, Bildquelle: [NMM]), einen Desktop-PC mit angeschlossenem Fernsehgerät 

und zum anderen das Hauptmenu der Anwendung (rechts). 

lediglich Audio-Daten lesen und wiedergeben. Die grau unterlegten Knoten sind 

jeweils zur gesharten Verwendung freigegeben. 

Bei der Anforderung des zweiten Graphen versucht der Session-Sharing-Algorithmus 

nun einen größtmöglichen gemeinsamen Teilgraphen zu finden, indem er die 

neue Anfrage auf die schon laufende Session abbildet. 

Abbildung 3.3 b) zeigt das Resultat des Session-Sharing-Algorithmus. Der DVD- 

ReadNode und der MPEGDemuxNode werden von beiden Graphen benutzt. Die 

restlichen Knoten werden von den entsprechenden Graphen exklusiv verwendet. 

Der neue Graph hat nun Zugriff auf eine andere Audiospur und kann diese wiedergeben. 

3.3 Die Multimedia-Box 

Die Multimedia-Box (MMBox) ist ein Home Entertainment System, das im Rahmen 

eines Fortgeschrittenen-Praktikums [BCE + 02] am Lehrstuhl für Computergraphik 

der Universität des Saarlandes entwickelt und in [Kle03] weitergeführt 

wurde. 

3.3.1 Hardware 

Die Hardware der Multimedia-Box (siehe Abbildung 3.4) besteht aus handelsüblichen 

PC-Komponenten, welche folgenden Kriterien genügen sollte: 

• Das Gehäuse des PCs besitzt ein ansprechendes Äußeres und hat einen niedrigen 

Geräuschpegel, damit sich die Multimedia-Box nahtlos in ein Wohnzimmer-Ambiente 

einfügt. 

• Ein normaler Fernseher dient als Ausgabe-Gerät.

3.3. DIE MULTIMEDIA-BOX 

• Zur einfachen Bedienung wird eine Infrarot-Fernbedienung verwendet, deren 

Signale über einen integrierten Infrarot-Empfänger empfangen werden. 

• Die Multimedia-Box besitzt einen Netzwerkanschluss um auf Netzwerkressourcen 

zugreifen oder über das Netzwerk angesprochen werden zu können. 

3.3.2 Anwendungs-Framework 

Bei der Entwicklung der Multimedia-Box-Anwendung wurde das Hauptaugenmerk 

darauf gelegt, dass sie leicht konfiguriert und modifiziert werden kann. Die 

Anwendung hat daher eine Plugin-Struktur und kann mit Hilfe eines XML-Dokuments 

beliebig zusammengestellt werden. Dies beschreibt zum einen die Menüstruktur 

(Menü-Zustände) zum anderen die Funktionalitäten (Aktions-Zustände), 

wie z.B. Live TV oder DVD. Jeder dieser Zustände muss dabei unterschiedlich 

auf Benutzereingaben reagieren. Zur Realisierung dieses Verhaltens wurde das 

Zustand-Entwurfsmuster [GHJV95] angewandt. Darin wird beschrieben, wie ein 

Objekt sein Verhalten ändern kann, wenn sein Zustand wechselt. 

Der XML-Parser der Multimedia-Box liest beim Start das oben genannte XML- 

Dokument ein, erstellt auf Grund der darin enthaltenen Informationen u.a. die Menüstruktur 

der Anwendung und legt die einzelnen Instanzen der Zustände an. 

Zur Konfiguration der einzelnen Zustände greift die Multimedia-Box auf eine Datei 

zu, die im $HOME-Verzeichnis des Benutzers abgelegt ist. Diese trägt den Namen 

.mmboxrc und wird beim Starten der Anwendung ausgelesen. Sie enthält Variablen 

mit zugewiesenen Werten, worauf die entsprechenden Zustände zugreifen und 

sich konfigurieren können. In der Konfigurations-Datei kann u.a. der rootpath 

angegeben werden, wodurch ein Verzeichnis festgelegt wird, in das die Multimedia- 

Box Dateien schreiben oder daraus lesen kann. Für die im Laufe dieser Arbeit entwickelten 

Zustände wurden neue Variablen eingeführt, die im Anhang A aufgelistet 

sind. 

Zur Anzeige der graphischen Bedienelemente der Multimedia-Box wird der OSD- 

ManagerNode verwendet. Dieser ist für die Anzeige von Widgets oder Fortschrittsanzeigen 

verantwortlich. Als Widget bezeichnet man in der Multimedia- 

Box graphische Interaktions-Objekte, die auf einem Display angezeigt werden können 

und gegebenenfalls auf Benutzereingaben reagieren. Neben Widgets zur Fortschrittsanzeige, 

Anzeige eines Bildes etc. existiert das TextView-Widget, das der 

Darstellung von Textzeilen dient, zwischen denen der Benutzer navigieren und selektieren 

kann. Durch bereitgestellte Decorator können diese weiterhin u.a. mit einem 

Rahmen oder Scrollbalken versehen werden. Widgets und Decorator können 

zu komplexen Anzeige-Elementen, Widgetunits genannt, zusammengefasst werden. 

Die Funktionsweise des OSDManagers sowie Details zu Anzeige-Elementen 

der Multimedia-Box können in [Kle03] nachgelesen werden. Im Laufe dieser Arbeit 

wurden weitere Widgetunits zur Anzeige und Eingabe von Text erstellt, wie in 

Abschnitt 4.5 vorgestellt. 

Da manche Zustände Audio- bzw. Video-Daten wiedergeben, werden die Knoten 

35


36 

Benutzereingabe 

Applikation 

DVD-Zustand 

Menü-Zustand 

Globale Knoten 

OSDManager 

Node XDisplay 

Node 

Playback 

Node 

Abbildung 3.5: Das Anwendungs-Framework der Multimedia-Box. Der aktive Zustand 

(hier: der DVD-Zustand) hat den Eingabefokus und ist mit den globalen Senken 

der Multimedia-Box zur Ausgabe der Audio- und Video-Daten verbunden. 

(Abbildung nach [Kle03]) 

OSDManagerNode, XDisplayNode und PlaybackNode global zur Verfügung 

gestellt. Jeder Zustand kann jederzeit durch einen anderen ersetzt werden, 

indem der vorige von den globalen Knoten getrennt wird und diese mit dem neuen 

verbunden werden. 

Das MMBox-Framework ist anhand des DVD-Zustands in Abbildung 3.5 dargestellt. 

Dieser legt alle Knoten an, die zum Auslesen der DVD und zum Verarbeiten 

der Daten nötig sind. Zur Ausgabe der Daten wird der Teilgraph mit den globalen 

Senken der MMBox verbunden. Da nicht jeder Zustand alle globalen Knoten 

benötigt, ist es möglich, dass mehrere Zustände gleichzeitig aktiv sind. Dies erlaubt 

das Abspielen einer DVD und gleichzeitiges Navigieren im Hauptmenü der 

Anwendung. Dazu werden, wie in Abbildung 3.6 zu sehen ist, die entsprechenden 

Knoten des DVD-Zustandes mit den globalen Senken verbunden, damit die Audiound 

Video-Daten abgespielt werden können. Der Menu-Zustand besitzt den Eingabefokus, 

wodurch in den Menüs navigiert werden kann. Zur Unterstützung dieser 

Funktionalität besitzt der OSDManagerNode zwei Eingänge für Bild-Daten, die 

übereinander gelegt und schließlich auf einem Bildschirm angezeigt werden können. 

Vor Beginn dieser Arbeit stellte die Multimedia-Box bereits jeweils einen Zustand 

für Live TV und den Videorekorder zur Verfügung. Der LiveTV-Zustand unterstützte 

den Zugriff auf eine lokale oder im Netzwerk verteilte TV-Karte. Dies konnte 

entweder eine digitale oder analoge TV-Karte sein. Mangels eines EPG konnten 

keine entsprechenden Informationen angezeigt werden. Der LiveTV-Zustand enthielt 

jedoch bereits die Möglichkeit des Timeshifting, das Pausieren des momentanen 

TV-Programms, was in dieser Arbeit erhalten blieb. Die Funktionalität des 

Timeshifting wird in NMM durch den MPEGTimeShiftingNode bereitgestellt. 

Der Videorekorder, der in der Multimedia-Box durch den TVTimer-Zustand reali-

Benutzereingabe 

Applikation 

Menü-Zustand 

DVD-Zustand 

3.3. DIE MULTIMEDIA-BOX 

Globale Knoten 

OSDManager 

Node XDisplay 

Node 

Playback 

Node 

Abbildung 3.6: MMBox-Anwendung mit mehreren aktiven Zuständen. Ein 

Zustand hat immer den Eingabefokus, hier der Menü-Zustand. (Abbildung 

nach [Kle03]) 

siert war, unterstützte zuvor ebenfalls nur eine lokale oder im Netzwerk verteilte 

TV-Karte, welche parallel von dem LiveTV-Zustand verwendet wurde. Das bedeutete, 

dass die TV-Karte während einer Aufnahme dem LiveTV-Zustand nicht mehr 

zur Verfügung stand. Ein gleichzeitiges Aufnehmen und Betrachten einer Sendung 

war daher nicht möglich. Weiterhin fehlten dem Videorekorder eine manuelle Konfliktauflösung 

sowie mangels EPG die Möglichkeit der Anzeige entsprechender Informationen 

zu Aufnahmen. Für die eigentliche Aufzeichnung einer Sendung existierte 

der DVBRecorder-Zustand, welcher zum frühzeitigen Abbrechen der Aufnahme 

mit Hilfe des Tasklist-Zustandes beendet werden musste. 

Auch auf dem momentanen Entwicklungs-Stand bietet der Tasklist-Zustand eine 

Übersicht über alle momentan aktiven Zustände der Multimedia-Box ggf. in sie zu 

wechseln oder sie zu beenden. Weiterhin besitzt er die Möglichkeit sich mit Zuständen 

zu verbinden, die in anderen Multimedia-Boxen innerhalb des Netzwerks 

aktiv sind. 

Die meisten Fernbedienungen besitzen heutzutage farbige Funktionstasten (rot, 

grün, gelb und blau) zum Aufrufen besonderer Funktionalitäten. Zur Unterstützung 

dieser Funktionstasten bietet die Multimedia-Box die ColorBar an. Sie blendet 

die korrespondierenden Farbflächen am unteren Bildschirmrand ein, sobald ihnen 

ein kurzer erklärender Text zugewiesen wurde. Die zugeordneten Funktionalitäten 

können innerhalb eines Zustandes dynamisch verändert werden und so auf die 

aktuelle Anzeige abgestimmte Funktionen bereitstellen. 

37


38 


In diesem Kapitel wurde die Netzwerk-Integrierte Multimedia Middleware (NMM) 

vorgestellt und deren grundlegenden Konzepte sowie die Unterstützung des Zugriffs 

auf im Netzwerk verteilte Ressourcen betrachtet. Es folgte die Erläuterung 

der Geräteverwaltung und des Session-Sharing-Dienstes, der es erlaubt, dass Knoten 

von mehreren Flussgraphen gemeinsam verwendet werden. Zum Schluss wurde 

die Multimedia-Box-Anwendung vorgestellt, die auf der Grundlage von NMM 

entwickelt wurde und im Laufe dieser Arbeit erweitert wird. Dies beinhaltete einen 

Statusbericht des LiveTV- und TVTimer-Zustandes vor den Erweiterungen.

Kapitel 4 

Realisierung einer elektronischen 

Programmzeitschrift 

In diesem Kapitel wird die Realisierung einer elektronischen Programmzeitschrift 

(Electronic Programme Guide – EPG) zur Integration in die Multimedia-Box beschrieben. 

Ein EPG ist die digitale Form einer gedruckten Programmzeitschrift, die 

Informationen zu einzelnen Sendungen bereitstellt [Wikb]. 

Zu Beginn wird in Abschnitt 4.1 ein Überblick über die Anforderungen an den 

EPG und die gesteckten Ziele gegeben. Zur Beschaffung von EPG-Daten existiert 

eine Vielzahl von Quellen, die mit unterschiedlichen Mechanismen angesprochen 

werden. Die verwendeten Quellen und das Einbinden derer wird in Abschnitt 4.2 

vorgestellt. Weiterhin sollen die so gesammelten Daten auf der Festplatte abgespeichert 

und zu einer späteren Verwendung bereitgestellt werden. Das Speichern und 

Abfragen der Informationen wird in Abschnitt 4.3 erläutert. 

Der EPG soll die besondere Funktionalität besitzen bei einer Abfrage fehlende 

Informationen festzustellen und diese bei anderen im Netzwerk verteilten EPGs zu 

erfragen. Die Vorgehensweise der realisierten Peer-to-Peer-Funktionalität wird in 

Abschnitt 4.4 erklärt. 

Zudem werden im Abschnitt 4.5 die Multimedia-Box-Zustände beschrieben, die 

zum Zugriff auf die EPG-Daten und zu deren Anzeige erstellt wurden. 

4.1 Übersicht 

Mit den Informationen einer elektronischen Programmzeitschrift lässt sich ein Programmüberblick 

über TV-Sendungen realisieren, den die gedruckten TV-Zeitschriften 

nicht ermöglichen. 

Die EPG-Informationen können für verschiedene Zwecke genutzt werden. Sie dienen 

zur Anzeige bei Live TV, damit der Benutzer zu jeder Zeit informiert ist, welche 

Sendung er zur Zeit verfolgt und welche sich anschließt. Der Benutzer kann 

39

KAPITEL 4. Realisierung einer elektronischen Programmzeitschrift 

40 

Anwendung Anwendung 

EPG 

Netzwerk 

Internet 

EPG-Quelle 

Abbildung 4.1: Zwei Anwendungen sammeln selbst keine EPG-Informationen, 

sondern greifen über das Netzwerk auf einen zentralen EPG zu, der seine Daten 

von Quelle aus dem Internet bezieht. 

sich aber auch einen Überblick über das Tagesprogramm eines bestimmten Senders 

anzeigen lassen bzw. es nach bestimmten Kriterien durchsuchen. Die notwendigen 

Daten müssen zuvor bei einem EPG erfragt werden. 

Der EPG soll über das Netzwerk angesprochen werden können. Dies ermöglicht 

die Realisierung eines Szenarios, in dem der EPG als zentraler Server zur Verfügung 

gestellt wird, mit dem sich Anwendungen verbinden und Daten erfragen 

lassen. Dies ist in Abbildung 4.1 graphisch dargestellt. Die Anwendungen sammeln 

selbst keine Daten, sondern erfragen diese ausschließlich von dem zentralen 

EPG. Dieser bezieht seine Informationen von einer Quelle aus dem Internet. 

Als Quelle zur Beschaffung von EPG-Informationen können das Internet, das digitale 

sowie das analoge Fernsehen dienen. Zur Erweiterung des EPG um Abfragemöglichkeiten 

neuer Quellen soll eine Plugin-Struktur realisiert werden, die 

das Einbinden neuer EPG-Plugins erleichtert. Die vielen unterschiedlichen Quellen 

stellen Daten in unterschiedlicher Qualität bereit. So sind bei einem Anbieter 

die Informationen umfangreicher, bei einem anderen die Start- und Endzeiten der 

Sendungen genauer. Damit stets auf optimale Daten zugegriffen werden kann, soll 

der EPG das Sammeln von mehreren Quellen unterstützen. Als EPG-Quellen werden 

in dieser Arbeit die XMLTV-Programme zum Zugriff auf Daten im Internet, 

nxtvepg zum Auslesen des analogen Fernsehsignals sowie die EPG-Informationen 

von DVB verwendet. 

Damit die Daten permanent verfügbar sind und schnell abgerufen werden können 

sind sie auf der Festplatte zu speichern. So kann bei einem Neustart der Applikation 

auf schon gesammelte Daten direkt zugegriffen werden. Der Vorteil einer solch 

schnellen Abfrage von angeforderten Informationen verlangt eine effiziente Datenhaltung. 

Weiterhin muss bei Verwendung mehrerer Quellen entschieden werden, 

welche Informationen gespeichert und welche verworfen werden. Da die EPG-

Quellen Daten in unterschiedlicher Qualität liefern, erfordert dies eine Regelung, 

die festlegt, von welchen Quellen Daten bevorzugt werden sollen. Folglich werden 

den EPG-Quellen Prioritäten zugewiesen, d.h. neue Daten können verworfen 

werden, falls die vorhandenen Informationen zu einer Sendung von einer höher 

priorisierten Quelle stammen als die Neuen oder die vorhandenen EPG-Daten ersetzt 

werden. Die Vergabe der Prioritäten wird in Abschnitt 4.3 besprochen. 

Ein weiteres Problem bei dieser Vorgehensweise ist die Erkennung von Informationen 

zu demselben Sender bei Verwendung unterschiedlicher Quellen, da die Sender 

mitunter nicht einheitlich bezeichnet werden. So kann z.B. eine Quelle Informationen 

für den Sender ’Pro 7’, eine weitere Daten für ’Pro Sieben’ bereitstellen. Für 

einen bestimmten Sender existieren lediglich unterschiedliche Schreibweisen. Zudem 

können auch verschiedene Namen für einen Sender existieren, so wird z.B. die 

ARD manchmal auch mit ’Das Erste’ bezeichnet. Der EPG muss feststellen können, 

dass beide Schreibweisen denselben Sender bezeichnen. Dies erfolgt durch die 

Angabe von Aliasen, wodurch alternative Schreibweisen eines Senders bestimmt 

werden. Das Festlegen von Aliasen wird in Abschnitt 4.3.1 beschrieben. 

Eine einfache Datenhaltung und leichte Zuordnung der Programm-Informationen 

zu Kanälen erfordert die eindeutige Identifizierung eines Kanals, wozu jeder eine 

individuelle Kanal-ID besitzt. Die ID besteht aus einer Zeichenkette, welche 

von EPG-Quellen festgelegt wird. Die Quellen verwenden selbst Kanal-ID’s um 

Sender zu identifizieren, welche innerhalb des EPGs wiederverwendet werden. Da 

diese jedoch unterschiedliche IDs für die gleichen Kanäle benutzen, muss eine Regelung 

für die zu verwendende ID getroffen werden. Weil der EPG nicht erkennen 

kann, für welche Kanäle die Quelle Daten bereitstellt, bevor diese nicht entsprechende 

Informationen gesendet hat, wird intern einem Kanal die ID von der Quelle 

zugewiesen, die als erste Daten für den entsprechenden Sender liefert. Außer der 

ID enthalten die Kanal-Informationen auch den Sendernamen, welcher ebenfalls 

dem EPG hinzugefügt wird. Eine Gefahr besteht darin, dass verschiedene EPG- 

Quellen für unterschiedliche Sender die gleiche ID verwenden. Die Programme 

des XMLTV-Pakets vergeben IDs in Form einer URL (z.B. ard.de für den Sender 

ARD), bei DVB sind die Sender durch eine Zahl, Service-ID genannt, gekennzeichnet, 

bei dem Programm nxtvepg besteht die ID aus den Buchstaben ’CNI’, 

gefolgt von einer Zahl, welche die ID des Senders im TV-Strom repräsentiert. Daher 

ist die Wahrscheinlichkeit, dass zwei Sender durch die gleiche ID gekennzeichnet 

werden, sehr gering, was für die in dieser Arbeit gesteckten Ziele ausreichend 

ist. 

Weitere Unterschiede der EPG-Quellen sind zum einen die Anzahl der Sender 

und zum anderen die Zeiträume, für die Informationen bereitgestellt werden. In 

manchen Szenarien kann ein EPG jedoch auf Grund technischer Beschränkungen 

nicht alle Quellen verwenden, wodurch Informationen für verschiedene Sender 

bzw. Tage nicht zur Verfügung stehen können. Diese Lücken in der Datenhaltung 

sollen möglichst geschlossen werden. Zu diesem Zweck soll der EPG die 

Funktionalität unterstützen fehlende Daten zu erkennen und bei verteilt laufenden 

EPG-Anwendungen zu erfragen. Dazu müssen die Ansprache des EPG über das 

Netzwerk und die Serialisierung der Daten gewährleistet sein. Dieser unterstützt 

ein Peer-to-Peer-Konzept, das eventuell vorhandene Lücken in den Informationen 

4.1. ÜBERSICHT 

41


42 

EPG-Quelle 

EPG-Quelle 

Internet 

Anwendung 

mit lokalem EPG 

EPG 

EPG 

Netzwerk 

Netzwerk 

EPG 

mit lokaler 

analoger TV-Karte 

Zugriff auf EPG-Quellen 

Zugriff auf EPG 

digitale 

TV-Karte 

Abbildung 4.2: Die Anwendung sammelt Daten für ihren lokalen EPG von einer 

digitalen TV-Karte. Bei fehlenden Informationen werden im Netzwerk verteilte 

EPGs abgefragt. Diese beziehen Daten entweder aus dem Internet oder von einer 

analogen TV-Karte. 

schließen soll. Dazu zählt auch das Erfragen von Daten zu TV-Sendern, die nicht 

durch die Quellen des lokalen EPG abgedeckt sind. Dies erfordert das Erfragen 

nach verfügbaren Sender-Informationen bei entfernten EPGs. 

Abbildung 4.2 zeigt ein Szenario für einen verteilten EPG. Der EPG der Anwendung 

selbst sammelt Daten von einer digitalen TV-Karte, die im Netzwerk verfügbar 

ist. Die verteilten EPGs beziehen entweder Daten aus dem Internet oder 

erhalten sie von einer analogen TV-Karte. Diese werden von dem lokalen EPG der 

Anwendung durch einen Peer-to-Peer-Zugriff abgefragt. Er spricht dafür zwei verteilte 

EPGs direkt an, wobei einer von ihnen eine Anfrage zusätzlich weiterleitet. 

Erfragte Daten werden von allen Rechnern an die Anwendung zurückgegeben. Der 

lokale EPG fügt die neuen Informationen seinen bereits vorhandenen hinzu. 

Realisierung 

Zur Realisierung wurde der EPG in verschiedene Klassen aufgeteilt. Das Design 

ist inspiriert von dem Entwurfsmuster Visitor [GHJV95]. Eine Anfrage oder ein 

Ergebnis wird von einzelnen, zwischengeschalteten Objekten geprüft und weitergeleitet. 

Den EPG betreffend werden die Abfrage-Ergebnisse von einem Objekt 

auf Vollständigkeit geprüft um ggf. im Netzwerk verteilte EPGs nach fehlenden 

Daten zu fragen. Diese Funktionalität wird in Abschnitt 4.4 vorgestellt. 

Die Anwendung kommuniziert ausschließlich mit der TVGuide-Klasse über de-

Abbildung 4.3: Die Klasse TVGuide implementiert die Interfaces ITVGuide 

und ITVGuideEvents. 

ren ITVGuide-Interface, wodurch die geforderte Ansprache des EPG über das 

Netzwerk möglich ist. Abbildung 4.3 zeigt die zugehörigen Klassendiagramme. 

Die Verarbeitungs-Klassen sowie deren Zusammenhänge, die in Abbildung 4.4 zu 

sehen sind, heißen: 

TVGuide ist die Haupt-Klasse, über die alle Anfragen laufen, die Objekte der 

nachfolgenden Klassen erstellt und alle verfügbaren EPG-Plugins verwaltet. 

TVGuideDatamanagement ist die Datenhaltungs-Klasse, die für das Suchen 

und Einsortieren von Daten in die Verzeichnisstruktur verantwortlich ist. 

TVGuidePeerConnector Diese Klasse prüft ggf. Abfrageergebnisse aus der 

lokalen Datenbank auf Vollständigkeit und stellt Verbindungen zu EPG’s im 

Netzwerk her um bei Bedarf fehlende Informationen zu erfragen. 

TVGuideConfigurator Diese Klasse liest Konfigurations-Parameter aus einer 

Datei oder von der Kommandozeile und nimmt auf deren Basis die Einstellungen 

des EPGs vor. 

Eine graphische Benutzeroberfläche zur Anzeige von EPG-Daten soll nach Möglichkeit 

benachrichtigt werden, wenn der EPG neue Informationen zur Verfügung 

stellt. Da, wie in Abschnitt 4.3 erklärt, eine Entscheidung über das Hinzufügen 

neuer Informationen getroffen wird, sollte die Anzeige nur aktualisiert werden, 

wenn solche auch wirklich vorhanden sind. Zu diesem Zweck implementiert die 

4.1. ÜBERSICHT 

43


44 

Abbildung 4.4: Dieses Diagramm zeigt die Beziehungen der Klassen des EPG 

zueinander. 

TVGuide-Klasse das ITVGuideEvent-Interface. Durch das Event-System von 

NMM kann eine Anwendung bei Bedarf einen EventListener (siehe Abschnitt 3.1.4) 

bei dem Objekt der TVGuide-Klasse für die entsprechenden Events registrieren 

und auf diese geeignet reagieren. 

Konfiguration des EPG 

Ein Objekt der TVGuide-Klasse wird unter Verwendung eines von zwei Konstruktoren 

erstellt: 

TVGuide(NMMApplication *app, NMMConfig* conf); 

TVGuide(NMMApplication *app, int argc, char **argv); 

Beide Konstruktoren erhalten einen Zeiger auf eine NMMApplication. Er bietet 

EPG-Plugins die Möglichkeit, Knoten von der Geräteverwaltung von NMM anzufordern, 

wovon in dieser Arbeit das DVBEPG-Plugin profitiert. So ist es diesem 

möglich, Knoten für einen Zugriff auf digitale TV-Karten anzufordern. Die restlichen 

Parameter dienen der Konfiguration des EPG. Bei Verwendung des ersten 

Konstruktors muss ein Zeiger auf ein Objekt der Klasse NMMConfig übergeben 

werden. Diese Klasse liest Konfigurations-Variablen und die gesetzten Werte aus 

einer Datei und können anschließend von dieser erfragt werden. Konfigurations- 

Variablen für den EPG sind in Anhang A aufgelistet. Der zweite Konstruktor dient 

der Konfiguration des EPG über Kommandozeilen-Parameter. Das Feld argv enthält 

die komplette Kommandozeile, welche von dem EPG geparst und ausgewertet 

wird. Der EPG unterstützt die folgenden Kommandozeilen-Parameter: 

-d legt das Verzeichnis fest, in dem EPG-Daten abgespeichert 

werden sollen. 

-s legt fest, welches Plugin zum Sammeln von EPG-Informationen 

verwendet werden soll. Mehrere Plugins können durch weitere mehrfache 

Verwendung von -s ausgewählt werden.

4.2. QUELLEN FÜR EPG-INFORMATIONEN 

-e : Legt einen Rechner fest, zu dem sich der EPG verbinden 

kann, um fehlende Daten zu erfragen. Diese Option kann mehrfach angegeben 

werden. 

Die verwendeten Quellen sowie das Einbinden derer in den EPG werden nun im 

Folgenden beschrieben. 

4.2 Quellen für EPG-Informationen 

Zur Bereitstellung im EPG müssen die Informationen zuerst gesammelt werden. 

Dazu existieren mehrere Quellen, aus denen solche Daten bezogen werden können. 

Damit diese Quellen leicht eingebunden und der EPG auch zukünftig einfach um 

neue ergänzt werden kann, wurde eine Plugin-Struktur realisiert. 

4.2.1 Integration verfügbarer EPG-Quellen 

Zur Realisierung der Plugin-Struktur wird eine Klasse benötigt, bei der sich die 

EPG-Plugins selbst registrieren und schließlich dort verwaltet werden. Zu Beginn 

müssen die vorhandenen EPG-Plugins erst ermittelt werden. Dies geschieht 

über das dynamische Laden der Bibliothek eines Plugins. Eine Bibliothek ist eine 

Sammlung von Routinen, Programmteilen oder Programmen, die häufig gebraucht 

werden und vom Hauptprogramm aus dieser abgerufen werden können (Quelle: 

[ITW]). Dazu existiert in NMM das dev-lib-Verzeichnis, welches alle zur 

Verfügung stehenden Bibliotheken enthält, die dynamisch geladen werden können. 

Das Laden der Plugins erfolgt dann mit Hilfe des PluginManagers [Rep03]. 

Die Funktion 

void PluginManager::loadExternalPlugins(string directory); 

lädt alle in dem Verzeichnis dev-lib/ enthaltenen Bibliotheken. 

Dies wird mit folgendem Auszug aus dem Quellcode der TVGuide-Klasse 

realisiert: 

/ ∗ 

Z u e r s t 

werden 

∗ / 

muss das I n t e r f a c e des PluginManagers a n g e f o d e r t 

IPluginManager_var 

pm(SPluginManager::getInstance() 

.getCheckedInterface()); 

/ ∗ 

Dann wird der Pfad des dev−l i b −V e r z e i c h n i s s e s e r m i t t e l t 

∗ / 

string pluginDir = getNMMPluginDir() + "/tvguide"; 

45


46 

Abbildung 4.5: Die Klasse TVGuidePluginManager listet alle verfügbaren 

EPG-Plugins. 

/ ∗ 

S c h l i e s s l i c h 

g e l a d e n 

∗ / 

werden d i e EPG−P l u g i n s aus diesem V e r z e i c h n i s 

pm->loadExternalPlugins(pluginDir); 

Die in dem angegebenen Verzeichnis enthaltenen Plugins werden beim Laden automatisch 

beim TVGuidePluginManager gelistet, dessen Klassendiagramm 

in Abbildung 4.5 gezeigt wird. Dieser übernimmt die Verwaltung der verfügbaren 

EPG-Plugins. Er ist als Singleton [GHJV95] implementiert um sicherzustellen, 

dass jedes Plugin in einer Anwendung auf die gleiche Instanz des TVGuide- 

PluginManagers zugreifen kann. 

Jedes EPG-Plugin registriert sich beim Laden der Bibliothek selbstständig bei dem 

TVGuidePluginManager durch folgende Code-Zeile im Konstruktor der TV- 

GuidePlugin-Klasse: 

STVGuidePluginManager::getInstance().registerPlugin(this); 

Die Vorgehensweise des Registrierens eines Plugins beim TVGuidePluginManager 

ist in Abbilding 4.6 dargestellt. 

Die EPG-Plugins selbst sind in Anlehnung an die NMM-Plugins realisiert [LRS02]. 

Dazu wird die Klasse TVGuidePlugin bereitgestellt, die als Oberklasse der einzelnen 

Plugins dient. Diese Oberklasse implementiert das ITVGuidePlugin- 

Interface, über das allgemeine Methoden zum Starten, Initialisieren, Stoppen und 

Deinitialisieren eines EPG-Plugins aufgerufen werden können (siehe Abbildung 4.7). 

Theoretisch wäre es damit möglich die EPG-Plugins auch transparent über das 

Netzwerk zu verteilen. NMM unterstützte zum Zeitpunkt dieser Arbeit jedoch nur 

die Verwaltung von NMM-Knoten in der Geräteverwaltung. Da die EPG-Plugins 

keine NMM-Knoten sind können sie nicht von einer Registry verwaltet werden, 

denn sie besitzen weder Ein- noch Ausgänge. Um dennoch ein Ansprechen der 

EPG-Plugins über das Netzwerk zu ermöglichen, könnte der in Abschnitt 3.2 vorgestellten 

Mechanismus zur Erweiterung einfacher Objekte um Netzwerktranspa-


Abbildung 4.6: Beim Instantiieren der TVGuide-Klasse werden durch 

den loadLibrary-Aufruf die TVGuidePlugins geladen, die sich bei dem 

TVGuidePluginManager registrieren. Anschließend kann über das Objekt der 

TVGuide-Klasse das entsprechende Plugin-Interface angefordert werden. 

Abbildung 4.7: Die Klasse TVGuidePlugin implementiert das Interface 

ITVGuidePlugin. 

47


48 

Abbildung 4.8: Die Zustände und Zustandsübergänge eines TVGuidePlugin. 

renz verwendet werden um jedes einzelne EPG-Plugin als Dienst anzubieten. In 

NMM werden über diesen Weg jedoch nur Middleware-Dienste angeboten. Da 

EPG-Plugins keine Dienste darstellen wurde auf diese Art der Realisierung verzichtet. 

Die TVGuidePlugin-Oberklasse stellt virtuelle Methoden bereit, die von den 

abgeleiteten Klassen implementiert werden müssen. In Anlehnung an NMM-Knoten 

wurde ein Zustandsmodell realisiert, welches den Status eines EPG-Plugins anzeigt. 

Die Zustandsübergange und die für einen Zustandswechsel relevanten Methoden 

werden in Abbildung 4.8 gezeigt. Dadurch kann festgestellt werden, ob 

alle benötigten Ressourcen zum Ausführen eines Plugins vorhanden sind und es 

gestartet werden kann. Diese Zustände sind im einzelnen: 

CONSTRUCTED Das Plugin wurde erstellt. 

INITIALIZED Hier wird geprüft, ob alle benötigten Ressourcen zur Ausführung 

des Plugins vorhanden sind. 

STARTED Das Plugin wurde gestartet und sammelt Daten. 

Um die Plugin-spezifischen Änderungen bei einem Zustandswechsel zu realisieren, 

existiert für jeden Zustand eine Methode mit dem Präfix ’do’, welche von dem 

Programmierer implementiert werden muss. Diese Vorgehensweise basiert auf dem 

Entwurfsmuster Template-Method [GHJV95]. 

Zusätzlich zu der Oberklasse TVGuidePlugin implementiert jedes Plugin ein 

eigenes Interface, mit dessen Hilfe Plugin-spezifische Einstellungen vorgenommen 

werden können. Die Anwendung kann das entsprechende Interface anfordern und 

auf diese Weise nur für das jeweilige Plugin relevante Parameter konfigurieren. Ein 

Beispiel ist in Abschnitt 4.2.3 aufgeführt. Jedes Plugin enthält eine vorgegebene 

Konfiguration, sodass es direkt nach dem Laden gestartet werden kann. Für Plugins, 

deren Konfiguration nicht automatisch festgelegt werden kann, existiert eine 

Konfigurations-Datei, die nach dem Erstellen des Plugin von diesem ausgelesen 

wird und sich somit selbst konfiguriert. 

Die von einem EPG-Plugin gesammelten Daten sind schließlich von einem EPG zu 

verwalten. Daher muss das Plugin wissen, wohin es die gesammelten Daten senden 

soll. Zu diesem Zweck wird ihm das ITVGuide-Interface des EPGs übergeben,


der die Daten verwalten soll. Dieses Interface wird über das ITVGuideProducer- 

Interface gesetzt, welches jedes Plugin implementiert. Nach dem Laden der Plugins 

wird geprüft, ob diese auch ausgeführt werden können. Dazu werden sie in den 

Zustand INITIALIZED versetzt. Sollte dies fehl schlagen, wird das entsprechende 

Plugin wieder gelöscht und steht folglich nicht mehr zur Verfügung. Andernfalls 

wird dem Plugin durch Aufrufen der Methode registerTVGuide(...) dessen 

ITVGuideProducer-Interface der EPG bekannt gemacht, zu dem es seine 

gesammelten Daten senden soll. 

Nachdem die ausführbaren Plugins ermittelt wurden, sind daraus die zu startenden 

Plugins auszuwählen, was von dem TVGuideConfigurator durch Auswerten 

der Konfigurations-Einstellungen vorgenommen wird. Die Plugins werden durch 

Angabe eines Kürzels, z.B. xmltv für das XMLTVPlugin, ausgewählt. Bei einer 

Kommandozeilen-Konfiguration können die Kürzel mittels des Optionsschalters 

-s spezifiziert werden. In einer Konfigurations-Datei geschieht dies durch Angabe 

einer oder mehrerer epgsource-Variablen (siehe Anhang A). Es wird geprüft, 

ob das Kürzel in dem Plugin-Namen enthalten ist und schließlich das EPG-Plugin 

durch Aufrufen der Methode enable() dessen ITVGuidePlugin-Interfaces 

aktiviert. Nur aktivierte Plugins können später auch gestartet werden. 

Die Schnittstelle zur Anwendung bildet das ITVGuide-Interface, welches von 

der Klasse TVGuide implementiert wird. Über dieses können sowohl Daten eingefügt 

und abgefragt (siehe Abschnitt 4.3) als auch die gewünschten EPG-Plugins 

konfiguriert werden. Zu diesem Zweck fordert die Anwendung das entsprechende 

Interface des Plugins von der TVGuide-Klasse an. Daraufhin werden die registrierten 

EPG-Plugins des TVGuidePluginManagers nach dem gewünschten 

Interface durchsucht und dieses schließlich an die Anwendung zurückgeliefert. Das 

Anfordern des Interfaces geschieht durch Aufrufen der Methode 

ITVGuidePlugin* ITVGuide:: 

getPluginInterface(const string &interfacename) 

Dabei muss der Name des Interface als Zeichenkette übergeben werden, da eine 

Definition von parameterisierten Methoden [Str98] durch die IDL von NMM nicht 

möglich ist. Das Plugin-Interface soll jedoch auch über das Netzwerk angefordert 

werden können, weshalb diese Art der Implementierung gewählt wurde. 

Alle zu startenden Plugins können initialisiert werden, sobald sie konfiguriert sind. 

Dazu stellt die TVGuide-Klasse die Methode init() bereit. Durch deren Aufruf 

wird jedes Plugin, das zum Sammeln der Daten verwendet werden soll, in den 

Zustand INITIALIZED versetzt. Sind alle Plugins initialisiert, können sie gestartet 

werden, indem auf dem TVGuide die Methode start() aufgerufen wird. 

Dadurch werden alle Plugins gestartet, die bei der Konfiguration aktiviert wurden. 

Dies erlaubt die Kontrolle der verwendeten EPG-Plugins durch einen einzigen 

Methoden-Aufruf anstatt diese bei jedem einzelnen Plugin gesondert aufzurufen. 

Nach dem Starten werden Informationen für Kanäle sowie Sendungen gesammelt 

und diese dem EPG zugeführt. Dazu müssen die EPG-Daten in ein einheitlichen 

Format gebracht werden, damit sie über eine einheitliche Schnittstelle dem EPG 

hinzugefügt werden können. Dies wird im Folgenden erklärt. 

49


50 

Abbildung 4.9: Die Klasse ChannelDescription speichert Informationen 

über Sender. 

4.2.2 Übertragung der Informationen 

Zum Datenaustausch der EPGs über das Netzwerk müssen die Daten serialisiert 

werden können [Rep03]. Dazu sind die Informationen in entsprechenden Datenstrukturen 

gespeichert. Dies ist auch notwendig, da nicht alle Quellen Informationen 

in einem einheitlichen Format liefern und die Daten über eine einheitliche 

Schnittstelle dem EPG hinzugefügt bzw. von ihm abgefragt werden können. Alle 

Daten zu einzelnen Kanälen werden in der Klasse ChannelDescription gespeichert, 

deren Klassendiagramm in Abbildung 4.9 zu sehen ist. Diese enthält die 

Kanal-ID zur eindeutigen Identifizierung eines Kanals sowie alle Kanalnamen, die 

der entsprechenden ID zugeordnet sind. Dabei handelt es sich entweder beim Sammeln 

von Informationen um die von dem Plugin verwendete ID oder bei Abfrage- 

Ergebnissen um die von dem EPG genutzte. Damit wird der teilweise unterschiedlichen 

Schreibweise der Sendernamen Rechnung getragen, die von verschiedenen 

Datenquellen verwendet wird. So kann z.B. die ARD bei einer Quelle ’ARD’ genannt 

bei der zweiten Quelle jedoch als ’Das Erste’ bezeichnet werden. 

ID : ard.de 

Name : ARD 

Name : Das Erste 

Ebenso werden auch die Programm-Informationen in einer eigenen Klasse, der 

ProgramDescription gespeichert (siehe Abbildung 4.10). Diese enthält die 

Start- und Endzeiten einer Sendung sowie die zu dem Sender gehörige Channel- 

Description. Sie kann zusätzliche Informationen enthalten wie z.B. den Titel 

der Sendung, eine ausführliche Beschreibung bzw. eine oder mehrere Kategorien, 

in welche die Sendung eingeordnet werden kann. 

Startzeit : 12.05.2005 20:15 

Endzeit : 12.05.2005 22:15 

Title : James Bond 

Beschreibung : Octopussy 

Kategorie : Spielfilm


Abbildung 4.10: Die Klasse ProgramDescription speichert Informationen 

zu einer Sendung. 

Bei einem über das Netzwerk erreichbaren EPG muss beachtet werden, dass sowohl 

Informationen als auch Anfragen nach EPG-Daten aus unterschiedlichen 

Zeitzonen stammen können. Eine Zeitzone ist ein Abschnitt der Erdoberfläche, auf 

dem eine gemeinsame Uhrzeit gilt. Sie bezeichnet auch die Differenz zur Koordinierten 

Weltzeit (Coordinate Universal Time – UTC)(Quelle: [Wikh]). Man nennt 

sie auch Greenwich Mean Time (GMT). Von dieser werden die Zeiten in den verschiedenen 

Zeitzonen abgeleitet [Wike]. Zur Lieferung korrekter Ergebnisse ist es 

deshalb erforderlich zu erkennen, aus welcher Zeitzone die Daten oder die Abfrage 

stammen. 

Repräsentation der Zeiten 

Zur Repräsentation der Zeiten muss es deshalb möglich sein die zu Grunde liegende 

Zeitzone feststellen zu können. Dies leistet die in NMM vorhandene Klasse 

LocalTime (siehe Abbildung 4.11). Die Klasse LocalTime dient als Wrapper 

für die Datenstruktur struct tm, welche von der C Standard-Bibliothek bereitgestellt 

wird. Sie ist für das Speichern der Komponenten einer Kalenderzeit vorgesehen, 

was z.B. den Tag, den Monat und das Jahr sowie Stunden und Minuten 

umfasst. Als weitere Informationen werden die der gespeicherten Zeit zu Grunde 

liegende Zeitzone zur Verfügung gestellt und die Angabe, ob der gespeicherten 

Zeit die Sommerzeit zu Grunde liegt. Unter Verwendung der Klasse LocalTime 

können diese Informationen in NMM serialisiert und über das Netzwerk übertra- 

51


52 

Abbildung 4.11: Die Klasse Localtime dient dem Speichern des Datums und 

der Uhrzeit. 

gen werden. Die Werte der in struct tm enthaltenen Variablen müssen daher 

zusätzlich in Integer-Variablen gespeichert werden. Nach dem Serialisieren wird 

die tm-Struktur wieder entsprechend gefüllt. 

Die Klasse LocalTime bot zu Beginn lediglich die Möglichkeit die Zeitinformationen 

abzulegen und abzufragen. Für diese Arbeit ist es jedoch notwendig Zeiten 

zu vergleichen und mit ihnen zu rechnen. Deshalb wurde die Klasse LocalTime 

um diese Funktionalitäten erweitert. Sie unterstützen das Addieren und Subtrahieren 

zweier LocalTime-Klassen, was als Ergebnis den Zeitunterschied in Sekunden 

liefert, sowie das Addieren und Subtrahieren ganzer Zahlen, was dem Vorgang 

entspricht, dass Sekunden zu der dargestellten Zeit addiert bzw. von ihr subtrahiert 

werden. Zur Implementierung der Rechenoperatoren wurde auf den Datentyp 

time_t zurückgegriffen, welcher ebenfalls von der C Standard-Bibliothek bereitgestellt 

wird. Diese speichert Zeiten als vergangene Sekunden seit dem 01.01.1970 

00:00 Uhr GMT, was der Zeitenbestimmung des Betriebssystems Unix entspricht. 

Zur Umwandlung von struct tm nach time_t stellt die C Standard-Bibliothek 

die Funktionen localtime(), gmtime und mktime bereit [man01]. Die Funktionen 

localtime() und gmtime liefern aus einer time_t-Repäsentation eine 

struct tm-Datenstruktur mit den entsprechenden Werten. gmtime rechnet 

dabei die Zeit in UTC um. mktime liest die Informationen aus einer struct 

tm-Struktur und liefert die Zeit als time_t-Typ zurück. Diese Funktionen wurden 

zur Implementierung der Arithmetik-Operatoren verwendet. 

Weiterhin wurde die Klasse LocalTime um die Funktion erweitert, die gespeicherte 

Zeit in UTC oder in die Lokale Zeitzone umrechnen zu können. Dazu wird 

auf die Informationen der struct tm-Datenstruktur zurückgegriffen, welche den 

zeitlichen Unterschied der gespeicherten Zeit zur UTC in Sekunden angibt. Zur 

Umrechnung einer Zeit nach UTC muss dieser Wert lediglich addiert werden. Zur


Umrechnung von UTC in die lokale Zeitzone muss zuerst die momenatne ermittelt 

werden, in der man sich momentan befindet. Dazu wird das aktuelle Datum festgestellt 

und aus der erhaltenen struct tm-Struktur die Zeitzonen-Informatinen 

ausgewertet. Das Resultat wird der umzurechnenden Zeit hinzuaddiert. Somit können 

alle benötigten Informationen zur Beschreibung der Start- und Endzeiten von 

Sendungen gespeichert sowie Zeiten verglichen werden. Sie können über die entsprechenden 

Methoden der ProgramDescription als LocalTime übergeben 

werden. 

Die Klasse ProgramDescription bietet weiterhin die Möglichkeit Zeiten als 

Zeichenkette zu übergeben. Dies ist notwendig um Zeitinformationen von EPG- 

Quellen, die Daten im XMLTV-Format [XML] liefern, sowie Zeiten von Abfrageergebnissen 

aus den loaklen EPG-Daten in der Klasse LocalTime zu speichern 

und diese Umrechnung nur einmal implementieren zu müssen. XMLTV beschreibt 

eine Repräsentation des Datums als Zeichenkette inklusive der Zeitzonen- 

Information, die dem Datum als Basis dient. Die Zeichenkette setzt sich wie folgt 

zusammen: 

YYYYMMDDhhmm TTTTT 

YYYY = Jahr, dargestellt mit 4 Ziffern 

MM = Monat, dargestellt mit 2 Ziffern 

DD = Tag, dargestellt mit 2 Ziffern 

hh = Stunde, dargestellt mit 2 Ziffern von 0-23 

MM = Minute 

TTTTT = Zeitzonen-Information, Differenz zur UTC 

Im Folgenden werden nun die realisierten EPG-Plugins vorgestellt, welche die beschriebenen 

Datenstrukturen verwenden um dem EPG Informationen zuzuführen. 

4.2.3 XMLTV-Plugin 

XMLTV [XML] ist eine Sammlung von Programmen, die TV-Informationen aus 

dem Internet abfragen und nach XML [Qui05] konvertieren. Diese beinhaltet in 

der Programmiersprache Perl [Per] implementierte Programme, die ihre Daten von 

festgelegten Quellen aus dem Internet beziehen. Die Informationen sind dabei auf 

ein Land und eine Datenquelle beschränkt. Aus diesem Grund existiert für unterstützte 

Länder mindestens ein Programm, das bei XMLTV Grabber genannt wird. 

Für Deutschland enthält das XMLTV-Paket den Grabber tv_grab_de_tvtoday, 

welcher die Webseite der Programmzeitschrift TVToday [TVTa] auswertet und 

nach XML konvertiert. Die Arbeitsweise dieser Grabber kann durch Kommandozeilen-Parameter 

beeinflusst werden. Weiterhin enthält das Paket Programme zur 

Bearbeitung von Dateien im XMLTV-Format. 

Das Format einer XML-Datei wird durch die Document Type Definiton (DTD) festgelegt. 

Das Dateiformat von XMLTV wird daher in der XMLTV-DTD beschrieben, 

welche auf der Homepage [XML] eingesehen werden kann. Es unterscheidet sich 

von anderen XML-basierten TV-Listings derart, dass es aus Benutzer-Sicht anstatt 

aus Provider-Sicht geschrieben wurde und alle Kanäle in einer einzelnen Datei 

53


54 

Abbildung 4.12: Die Klasse XMLTVPlugin erbt von TVGuidePlugin und 

implementiert zusätzlich das Interface IXMLTVPlugin. 

mischt. Jedes Programm enthält Details, wie z.B. Name der Sendung, Beschreibung 

etc. als Subelemente, während Broadcast-Details, wie beispielsweise Zeiten, 

als Attribute gespeichert werden. Die XML-Datei hat folgenden Aufbau: 

 

 

 

ARD 

 

... 

 

Tagesthemen 

Mit Sport 

Nachrichten 

 

 

Das Wort zum Sonntag 

es spricht Propst Ralf Meister 

 

... 

 

Zur Verwendung dieser Werkzeuge wurde das XMLTVPlugin entwickelt, dessen 

Klassendiagramm in Abbildung 4.12 zu sehen ist. Dieses implementiert das 

IXMLTVPlugin-Interface um einer Anwendung die Änderung von Einstellungen 

des Plugins bei Bedarf zu ermöglichen.


Bei Initialisierung Plugins wird zuerst festgestellt, welche XMLTV-Tools zur Verfügung 

stehen. Diese sind in dessen Konfigurations-Datei aufgelistet, die den Namen 

XMLTVPluginConf.xml trägt. Den Aufbau der Datei zeigt Anhang B. 

Die Grabber werden beim Initialisieren des Plugins mit der Option -h ausgeführt 

um festzustellen, welche davon installiert und ausführbar sind. Die Option -h gibt 

einen Hilfetext aus und beendet den Grabber, ohne dass EPG-Informationen gesammelt 

werden. Der Hilfetext wird hier jedoch verworfen da lediglich festgestellt 

werden soll, ob es möglich ist das Programm auszuführen. Die Auswahl 

eines Grabbers geschieht über das Setzen der Länderkennung entweder in der 

Konfigurations-Datei selbst oder über die Methode setLocale() des IXMLTV- 

Plugin-Interfaces. Die Zuordnung eines Grabbers zu einer Länderkennung wird 

in der Konfigurations-Datei vorgenommen. Dies legt fest, welcher Grabber bei 

Setzen einer bestimmten Länderkennung verwendet werden soll, da auch mehrere 

Grabber für ein Land existieren und das XMLTVPlugin nur die Ausführung eines 

einzelnen Grabbers zulässt. Weiterhin können auch solche Programme verwendet 

werden, die EPG-Informationen im XMLTV-Format ausgeben, jedoch nicht in 

den XMLTV-Werkzeugen enthalten sind und somit nicht deren Namenskonvention 

(siehe [XML]) entsprechen. Das Ausführen mehrerer Grabber parallel oder sequentiell 

wird in der vorliegenden Implementierung nicht unterstützt. Als mögliche 

Erweiterung könnte das Plugin dahingehend ergänzt werden. Weiterhin sind in der 

Datei XMLTVPluginConf.xml Default-Werte für das periodische Ausführen 

des gewählten Grabbers und die Priorität angegeben, die beim Laden des Plugins 

ausgelesen werden. Die Datei liegt zur besseren Lesbarkeit im XML-Format vor, 

sodass bei Bedarf die Einstellungen vom Benutzer geändert werden können. 

Damit Daten schnell zur Verfügung gestellt werden können, sollen bei der Ausführung 

des XMLTVPlugins Informationen für jeden Tag und jeden Kanal einzeln 

gesammelt werden. Diese Vorgehensweise wurde deshalb gewählt, weil das Sammeln 

aller Daten für alle Kanäle sehr lange dauert und damit nach einem Neustart 

der Applikation das Sammeln bei dem Tag und dem Sender fortgesetzt wird, für 

die das Plugin zuletzt Daten erhalten hat. Die Grabber rufen jedoch per Default 

alle Informationen für eine Woche ab, sodass für jeden Kanal Daten für die nächsten 

sieben Tage bereitgestellt werden. Mittels der Kommandozeilen-Parameter der 

XMLTV-Programme lässt sich das Sammeln allerdings nur auf einen Tag, nicht auf 

einen Kanal einschränken. 

Jeder Grabber besitzt eine eigene Konfigurations-Datei. Diese wird im Folgenden 

mit grabber.conf bezeichnet um Verwechslungen mit der Plugin-Konfigurations- 

Datei XMLTVPluginConf.xml zu vermeiden. Darin sind für den entsprechenden 

Grabber die Sender gespeichert, für die EPG-Daten gesammelt werden sollen 

und ist standardmäßig in $HOME/..conf abgelegt. Allerdings 

kann beim Aufruf des Grabbers eine alternative grabber.conf angegeben werden, 

was das Sammeln auf einen Kanal einschränken lässt. Dazu wird diese Datei zeilenweise 

ausgelesen und bei jedem Iterations-Schritt die Zeile in eine temporäre 

Datei geschrieben, welche dem Grabber als alternative grabber.conf angegeben 

wird. Die resultierenden XML-Daten werden in einer weiteren temporären Datei 

abgelegt, die nun geparst und deren Inhalt an den EPG übertragen wird. Nach erfolgreicher 

Abfrage werden der Kanal und der Tag der letzten Abfrage in der Datei 

55


56 

Abbildung 4.13: Die Klasse Fork. 

XMLTVPluginConf.xml gespeichert. Somit ist es möglich bei einem erneuten 

Starten der EPG-Anwendung festzustellen, bis zu welchem Tag und welchem 

Kanal schon Daten mittels XMLTV gesammelt wurden um an dieser Stelle fortzufahren. 

Fork in einer Multimedia-Umgebung 

Zum Starten der XMLTV-Programme, wurde die C-Funktion system(char*) 

verwendet. In dieser wird in einem, mittels fork(), neu erstellten Prozess das 

entsprechende Kommando ausgeführt [SM00]. Daraus resultieren jedoch in einer 

Multimedia-Umgebung Probleme, da fork() für den neuen Prozess alle offenen 

File-Descriptoren kopiert, so u.a. auch die der Soundkarte. Folglich könnte das Gerät 

während eines solchen Kommandos blockiert werden, sodass es nicht parallel 

nutzbar ist. Zur Lösung dieses Problems wurde die Fork-Klasse entwickelt (siehe 

Abbildung 4.13). Sie erstellt zu Beginn einer Anwendung einen Prozess, der bei 

Ausführung eines Kommandos kopiert werden kann. Somit läuft die Anwendung 

in zwei Prozessen. Der erste Prozess ist der Anwendungs-Prozess, der zweite Prozess 

wird bei Ausführung externer Programme geklont um diese darin auszuführen. 

Dazu ist es notwendig mit diesem Prozess zu kommunizieren und ihm mitzuteilen, 

welche Befehlszeile ausgeführt werden soll. 

Das Betriebssystem Unix stellt dafür zum einen den Mechanismus der Pipes und 

zum anderen den der Unix-Domain-Sockets bereit [Hal97]. Die Kommunikation 

über Pipes ist jedoch unidirektional, d.h. Nachrichten können nur in eine Richtung 

geschickt werden. Um eine Zurücklieferung des Kommando-Ergebnisss zu 

ermöglichen ist aber eine bidirektionale Kommunikation nötig. Dies wird durch die 

Unix-Domain-Sockets unterstützt. Sie dienen sowohl der Netzwerkkommunikation 

und als auch der lokalen Kommunikation zweier Prozesse, je nachdem, welcher 

Domain-Parameter bei ihrer Erstellung angegeben wird [SM00]. Lokale Sockets 

werden durch den Domain-Parameter AF_UNIX angelegt. Somit ist auch ein Ansprechen 

dieser aus dem Netzwerk nicht möglich. Dies soll aus Sicherheitsgründen 

vermieden werden, da sonst ein Angreifer beliebig Programme auf dem lokalen 

Rechner starten kann. Eine weitere Möglichkeit wäre die Realisierung der Prozesskommunikation 

über den Service-Mechanismus von NMM. Der Kind-Prozess registriert 

einen Dienst, mit dem sich eine Anwendung verbinden kann um ein Kommando 

auszuführen. Da diese jedoch über das Netzwerk ansprechbar sind, ist auf 

eine solche Art der Implementierung auf Grund der oben genannten Sicherheitsa-


spekte verzichtet worden. Außerdem ist für die gesteckten Ziele dieser Arbeit ein 

Zugriff auf den Kind-Prozess aus dem Netzwerk nicht nötig. Deshalb wurde zur 

Prozesskommunikation auf die lokalen Unix-Domain-Sockets zurückgegriffen. 

Die Fork-Klasse wurde als Singleton implementiert [GHJV95] [Rep03], damit innerhalb 

einer Anwendung ein Zugriff auf die gleiche Instanz der Klasse möglich 

ist. Um einen reibungslosen Ablauf zu garantieren muss diese Klasse zu Anfang 

eines Programms dann instantiiert werden, wenn noch keine File-Descriptoren geöffnet 

sind. Die Klasse wird wie folgt erstellt: 

int main(){ 

/ ∗ E r s t e l l e n der I n s t a n z der Fork−K l a s s e ∗ / 

SFork::getInstance(); 

} 

/ ∗ Der R e s t der Anwendung ∗ / 

[...] 

Die Folge ist die Erstellung eines Kind-Prozesses mit Hilfe von fork(), welcher 

solange wartet, bis ein Kommando ausgeführt werden soll. Zuvor werden die 

Sockets angelegt und verbunden. Dies wird wie folgt bewerkstelligt: 

/ ∗ 

Feld zum S p e i c h e r n des Socket −Paares 

∗ / 

int sv[s]; 

/ ∗ 

Anlegen und Verbinden der S o c k e t s . 

AF_UNIX l e g t f e s t , dass es s i c h b e i den e r s t e l l t e n S o c k e t s 

um s o l c h e f ü r d i e l o k a l e P r o z e s s k o m m u n i k a t i on h a n d e l t . 

Die D e s c r i p t o r e n zum Ansprechen der S o c k e t s werden i n 

dem Feld sv g e s p e i c h e r t . 

∗ / 

socketpair(AF_UNIX, SOCK_STREAM, 0, sv); 

Soll ein Kommando ausgeführt werden, muss man auf dem Objekt der Fork- 

Klasse die Methode executeCommand(...) mit der Befehlszeile als Parameter 

aufrufen: 

SFork::getInstance() 

.executeCommand(’’Auszuführendes Kommando’’); 

Die Methode schickt das Kommando an den Kind-Prozess und wartet solange, bis 

dieser das Programm ausgeführt und das Ergebnis des system(...)-Aufrufs 

übermittelt hat. Der Rückgabewert wird aus dem Socket ausgelesen und an die 

Anwendung zurückgegeben. 

int Fork::executeCommand(string command){ 

/ ∗ 

Die Methode s c h i c k t d i e B e f e h l s z e i l e z u r Ausführung an 

den Kind−P r o z e s s 

∗ / 

write(sv[0], command , sizeof(command)); 

... 

57


58 

/ ∗ 

AnschlieSSend w a r t e t s i e solange , b i s das Kommando 

a u s g e f ü h r t wurde . . . 

∗ / 

char recvBuffer[BUFFERSIZE]; 

int len = read(sv[0], recvBuffer, sizeof(recvBuffer)); 

/ ∗ 

. . . 

∗ / 

und g i b t das E r g e b n i s an d i e Anwendung z u r ü c k 

return atoi(recvBuffer); 

} 

Der Kind-Prozess wartet nach dessen Erstellung mittels des read(...)-Aufrufs, 

bis eine Nachricht über den Socket empfangen wurde. Anschließend führt er das 

erhaltene Kommando unter Verwendung von system(...) aus und übermittelt 

den Rückgabewert an die Methode: 

... 

/ ∗ 

Der Kind−P r o z e s s w a r t e t an dem S o c k e t sv [ 1 ] b i s e i n e 

N a c h r i c h t e i n t r i f f t 

∗ / 

char command[BUFFERSIZE] 

int len = read(sv[1], command,sizeof(command)); 

... 

/ ∗ 

Das ü b e r t r a g e n e Kommando wird m i t t e l s ’ s y s t e m ’ a u s g e f ü h r t 

∗ / 

int res = system(command); 

/ ∗ 

Der Rückabewert wird an d i e Methode z u r ü c k g e s c h i c k t 

∗ / 

char t[20]; 

sprintf(t, "%i",res); 

write(sv[1], t, sizeof(t)); 

... 

Da die Fork-Klasse in einer Multimedia-Umgebung verwendet wird, kann es bei 

zu hoher Beanspruchung der CPU durch Ausführen eines Kommandos mittels 

system (...) zu Störungen der Audio- und Video-Wiedergabe kommen. Um 

diese Störungen zu vermeiden ist es notwendig die Priorität des fork()-Prozesses 

zu verringern, so dass dieser die Systemressourcen weniger belastet. So läuft der 

Prozess zwar langsamer, dies ist jedoch bei der Ausführung von XMLTV nicht von 

belang. Die Priorität des Kind-Prozesses kann über die Methode int setChild- 

Priority(int prio) der Fork-Klasse verringert werden. Prioräten führen 

dazu, dass ein Kommando weniger CPU-Zeit nutzt. Der Bereich gültiger Prioritäten 

liegt zwischen -20 und +20. Dabei gilt: je höher der numerische Wert, desto 

geringer die Ausführungspriorität. Die Priorität eines Prozesses wird bei Aufruf 

von setChildPriority() durch die C-Funktion setpriority(...) gesetzt:


/ ∗ 

Durch den Parameter ’ p r i o ’ wird d i e zu s e t z e n d e P r i o r i t ä t 

übergeben 

∗ / 

int Fork::setChildPriority(int prio){ 

/ ∗ 

PRIO_PROCESS g i b t an , dass d i e P r i o r i t ä t e i n e s P r o z e s s e s 

g e s e t z t werden s o l l . In ’ c h i l d P i d ’ i s t d i e Prozess −ID 

des durch ’ f o r k ( ) ’ e r z e u g t e n Kind−P r o z e s s e s g e s p e i c h e r t . 

∗ / 

return setpriority(PRIO_PROCESS, prio, childPid); 

} 

Das XMLTVPlugin legt auf diese Weise die Priorität auf den niedrigsten Wert fest, 

sobald das Plugin gestartet wurde. 

Durch Beschränkungen des Betriebssystem kann die Priorität eines Prozesses von 

einem normalen Benutzer lediglich verringert, aber nicht erhöht werden. Dies gilt 

auch für die von einem Benutzer gesetzten Prioritäten: Eine einmal verringerte 

Prioriät kann nicht mehr erhöht werden [SM00]. Da jedoch die Fork-Klasse in 

dieser Arbeit ausschließlich von EPG-Plugins zur Ausführung externer Programme 

verwendet wird und diese immer mit niedrigster Priorität laufen sollen um die 

Wiedergabe von Multimedia-Daten nicht zu stören, ist diese Vorgehensweise ausreichend. 

Beispiel-Implementierung eins EPG-Plugins 

An dieser Stelle wird nun ein Beispiel für die Implementierung eines EPG-Plugins 

anhand von Auszügen aus der Realisierung des XMLTV-Plugins beschrieben. 

Als ersten Schritt definiert man das Interface, welches das XMLTVPlugin zusätzlich 

zu dem ITVGuidePlugin-Interface implementieren soll. Mit Hilfe des neuen 

Interfaces können Plugin-spezifische Parameter eingestellt werden. 

module NMM{ 

} 

interface IXMLTVPlugin { 

/ ∗ 

S e t z e n der Sprach−I n f o r m a t i o n e n und damit Auswahl des 

zu verwendenden XMLTV−T o o l s 

∗ / 

Result setLocale(in string loc); 

/ ∗ 

Abfrage der g e s e t z t e n Sprach−I n f o r m a t i o n e n 

∗ / 

string getLocale(); 

[...] 

}; 

59


60 

Nun kann das Plugin implementiert werden, wobei die Klasse XMLTVPlugin von 

TVGuidePlugin und von IXMLTVPluginImpl erbt. 

class XMLTVPlugin : public TVGuidePlugin, 

public IXMLTVPluginImpl 

{ 

/ ∗ D e k l a r a t i o n Plugin−s p e z i f i s c h e r V a r i a b l e n ∗ / 

[...] 

/ ∗ do−Mehtoden der TVGuidePlugin −O b e r k l a s s e ∗ / 

Result doStart(); 

Result doStop(); 

Result doInit(); 

Result doDeinit(); 

/ ∗ Methoden des IXMLTVPlugin−I n t e r f a c e s ∗ / 

Result setLocale(const string &loc); 

string getLocale(); 

[...] 

}; 

In der Folge muss die Implementierung der ’do-Methoden’ des ITVGuidePlugin- 

Interface, die den Arbeitsablauf des Plugins steuern, vorgenommen werden. Deshalb 

ist zu prüfen, welche dem Plugin bekannte XMLTV-Tools ausgeführt werden 

können. Dies wird in der Methode doInit() wie folgt realisiert. 

Result XMLTVPlugin::doInit(){ 

/ ∗ L i s t e der zu Verfügung s t e h e n d e n grabber ∗ / 

listsecond + " -h >/dev/null"; 

if(SFork::getInstance() 

.executeCommand(testCommand.c_str()) != 0){ 

i->second=""; 

} 

} 

return SUCCESS; 

} 

Nun kann der Start des Plugins erfolgen, wobei das Sammeln der Daten in der 

Methode doStart() implementiert wird. 

Result XMLTVPlugin::doStart() { 

/ ∗ 

Hier wird das XMLTV−Tool a u s g e f ü h r t . Es s p e i c h e r t 

s e i n e gesammelten Daten i n der D a t e i ’ f i l e n a m e ’ . 

Das a u s z u f ü h r e n d e Kommando i s t i n dem 

s t r i n g ’ grabberCommand ’ e n t h a l t e n 

∗ / 

int systemRes = SFork::getInstance() 

.executeCommand(grabberCommand);

} 


if(systemRes == 0){ 

/ ∗ 

I s t das Tool e r f o l g r e i c h a u s g e f ü h r t , werden d i e 

XML−Daten m i t t e l s der H i l f s −F u n k t i o n ’readXMLTV ( . . ) ’ 

aus der D a t e i ’ f i l e n a m e ’ a u s g e l e s e n und zu dem EPG 

g e s e n d e t , der s i e s p e i c h e r t 

∗ / 

systemRes = readXMLTV(filename); 

} 

return SUCCESS; 

4.2.4 nxtvepg-Plugin 

Das Programm nxtvepg [Zoe] ermöglicht die Nutzung von nexTView [ETS97b], 

einer kostenlosen elektronischen Programmzeitschrift, die zusammen mit dem Videotext 

[ETS97c] übertragen wird. Diese enthält die Programme aller überregionalen 

Sender in Deutschland, Österreich, der Schweiz und Frankreich. Die Informationen 

umfassen je nach Provider einen Zeitraum von bis zu einer Woche. Dieser 

Standard wurde vom European Telecommunication Standard Institute (ETSI) [Ins] 

entwickelt und ging erstmals 1997 auf Sendung. Die Absicht war in der Integration 

einer Programmzeitschrift in Fernsehgeräte begründet. Daher basiert die Übertragung 

auf einem kompakten Binärformat anstelle vorformatierter Videotext-Seiten. 

NexTView-Daten werden auf einer einzelnen Videotext-Seite übertragen, die meist 

sekündlich in den regulären Datenstrom eingefügt wird. Die Daten werden zyklisch 

gesendet, d.h. der Datensatz wiederholt sich im Zeitabstand von 20-25 Minuten. 

Dieser Zyklus ist wiederum in zwei Datenströme unterteilt, die miteinander verwoben 

sind. Der erste Strom enthält zeitnahe Programm-Informationen und kann 

im Gesamtzyklus mehrfach wiederholt werden, der zweite enthält die restlichen 

Daten und wird in einem Zyklus von 20-25 Minuten erneut gesendet. Durch diese 

Trennung ist ein Laden der zeitnahen Daten in kurzer Zeit möglich. 

NexTView-Daten werden in einem kompakten Binärformat, ausgenommen der 

Textdaten, übertragen. Diese kodierten Informationen enthalten Kontrolldaten, wie 

z.B. Startzeit, Senderkennung etc.. Sie sind mit einer “Hamming-8:4”-Vorwärtsfehlerkorrektur 

[Wikd] versehen, wodurch Fehler von bis zu zwei verdrehten Bits 

in einem Oktett erkannt und korrigiert werden können, was dem Schutz der Kontrolldaten 

vor Übertragungsfehlern dient. Tritt dennoch ein nicht zu korrigierender 

Fehler auf, wird der gesamte Datenblock verworfen. 

Das Programm nxtvepg bietet die Möglichkeit die gesammelten Informationen in 

eine XML-Datei zu exportieren. Auf diese Funktionalität greift das Nxtvepg- 

Plugin (siehe Abbildung 4.14) zurück und lässt die Daten dem EPG zukommen. 

Nach Auslesen der XML-Datei werden die darin enthaltenen Daten an den EPG 

übergeben. Das Programm bietet keine Möglichkeit diese Daten vorzufiltern. So 

ist ein Vorgehen wie bei dem XMLTVPlugin nicht möglich. Bei ersten Versuchen 

wurden die Informationen mittels tv_split aus der XMLTV-Sammlung in verschie- 

61


62 

Abbildung 4.14: Die Klasse NxtvepgPlugin erbt von TVGuidePlugin und 

implementiert zusätzlich das Interface INxtvepgPlugin. 

dene Dateien geschrieben, welche anschließend ausgelesen wurden. Dies dauerte 

jedoch länger als das Parsen der kompletten Datei, weshalb die Benutzung von 

tv_split nur optional und per default deaktiviert ist. Somit wird die gesamte XML- 

Datei eingelesen, geparst und die Daten an den EPG gesandt. 

Das NxtvepgPlugins besitzt ebenfalls eine Default-Konfiguration, welche in 

der Datei NxtvepgPluginConf.xml abgelegt ist und beim Erstellen des Plugins 

ausgelesen wird. Der Inhalt dieser Datei ist in Anhang B aufgeführt. 

4.2.5 DVB-EPG-Plugin 

Mit Einführung des digitalen Fernsehens wurde vom European Telecommunications 

Standards Institute (ETSI) [Ins] der Standard für Digital Video Broadcasting 

(DVB) verabschiedet. Dieser legt fest, wie Daten innerhalb des DVB-Stroms angelegt 

sind. Der DVB-Strom enthält u.a. Audio- und Video-Daten sowie eine Beschreibung 

der einzelnen Teilströme. Solche Informationen werden Service Information 

Tables [ETS04b] genannt. Die für diese Arbeit relevante Tabelle heißt Event 

Information Table (EIT). In ihr sind Informationen über TV-Programme gesammelt. 

Die EIT ist in Sektionen mit einer maximalen Länge von 4069 Bytes unterteilt. 

Der Service-Information-Bit-Strom sollte mindestens 2 Sektionen pro Service 

enthalten, die Informationen über das laufende und das folgende Programm beinhalten 

[ETS04a]. Für die Zuordnung zu einem Sender enthält jede Sektion Informationen 

über den Service, für den sie Daten bereitstellt, in denen mindestens die


Abbildung 4.15: Die Klasse DVBEPGPlugin erbt von TVGuidePlugin und 

implementiert zusätzlich das Interface IDVBEPGPlugin. 

Abbildung 4.16: Dieser Graph sammelt EPG-Informationen von DVB, die vom 

DVBReadNode direkt zum TVGuide gesendet werden. Der DevNullNode 

dient als Senke des Graphen und verwirft die eingehenden Audio- und Videodaten, 

da diese für die Zwecke des EPG irrelevant sind. 

Startzeit und die Länge eines Programms angegeben sind. Optional können weitere 

Informationen übertragen werden, wie z.B. eine Kurzbeschreibung, die meist den 

Titel enthält. 

Um die EPG-Daten aus dem DVB-Strom zu extrahieren, wurde das DVBEPGPlugin 

realisiert (siehe Abbilding 4.15), das den in NMM vorhandenen DVBReadNode 

aus [BCE + 02] verwendet. Dieser greift zum Ansteuern einer DVB-Karte auf Methoden 

des VDR [Sch] aus Abschnitt 2.3.2 zurück. Dazu zählt auch die Funktionalität 

zum Auslesen der EPG-Daten. Sie war zunächst deaktiviert, was für 

diese Arbeit wieder rückgängig gemacht wurde. Der Knoten wurde insofern erweitert, 

dass er die EPG-Daten in Objekten der ChannelDescription- und 

ProgramDescription-Klassen speichert und dem EPG hinzufügt. Da der VDR 

die ausgelesenen Daten im Hauptspeicher in eigenen Datenstrukturen verwaltet, 

bietet die Stelle vor dem Speichern den Ansatzpunkt die Informationen abzugreifen 

und an den EPG zu senden. Zum Sammeln der Daten wird ein Flussgraph erstellt, 

der aus dem DVBReadNode verbunden mit einem DevNullNode, besteht 

(siehe Abbildung 4.16). 

Das ITVGuide-Interface muss beim DVBReadNode registriert werden, wodurch 

63


64 

Abbildung 4.17: Die Klasse DVBReadNodeTVGuideManager verwaltet bei 

dem DVBReadNode registrierte EPGs. 

diesem mitgeteilt wird, wohin die EPG-Daten zu senden sind. Aus diesem Grund 

implementiert der DVBReadNode das ITVGuideProducer-Interface. Auf diese 

Weise können die aus den EPG-Informationen des DVB-Stroms erstellten Objekte 

der ChannelDescription- bzw. ProgramDescription-Klasse dem 

EPG hinzugefügt werden. Damit mehrere EPGs von der gleichen TV-Quelle Daten 

sammeln können und um sicher zu stellen, dass es innerhalb des DVBReadNode 

während eines Zugriffs auf das ITVGuide-Interface keine Speicherzugriffsfehler 

beim Freigeben des Knoten entstehen, weil das Interface zu früh gelöscht wird, 

werden die registrierten ITVGuide-Interfaces innerhalb der Klasse DVBRead- 

NodeTVGuideManger verwaltet, dessen Klassendiagramm in Abbildung 4.17 

zu sehen ist. Sie ist als Singleton realisiert um innerhalb des DVBReadNodes auf 

die gleiche Instanz zugreifen zu können. Der DVBReadNode übergibt ihr die aus 

den erhaltenen Programm-Informationen erstellten ProgramDescriptions, welche 

von dem DVBReadNodeTVGuideManager an die registrierten EPGs weitergeleitet 

wird. Zuvor wird von dem entsprechenden EPG die festgelegte Priorität 

für Informationen von DVB erfragt und in der ProgramDescription gesetzt, 

damit die Daten innerhalb des EPGs korrekt einsortiert werden können. Das Festlegen 

der Prioritäten wird in Abschnitt 4.3 behandelt. 

Damit auch Daten von allen verfügbaren Kanälen gesammelt werden, schaltet das 

Plugin automatisch per default im zeitlichen Abstand von 60 Sekunden die Kanäle 

weiter. Dazu wird die TVManager-Klasse verwendet, welche innerhalb des Plugins 

erstellt wird. Sie dient dem Berücksichtigen anderer Verwendungszwecke des 

Knotens und sucht ggf. eine neue TV-Karte als Quelle. Die Klasse TVManager 

wird in Abschnitt 5.3.6 im Detail vorgestellt. 

4.3 Verwaltung der EPG-Informationen 

Die von den Plugins gesammelten EPG-Informationen sollen nun auf der Festplatte 

abgespeichert werden. Zu Beginn war dabei die Frage nach der Art und Weise des 

Speicherns der Daten zu beantworten. Zur Auswahl standen eine ausgewachsene 

Datenbank und das Speichern in XML-Dateien. Letztendlich fiel die Entscheidung

4.3. VERWALTUNG DER EPG-INFORMATIONEN 

zugunsten des Speicherns in XML-Dateien, da das Installieren einer Datenbank 

wie MySQL [MyS] zusätzlich zu NMM sehr umständlich erschien. Die Struktur 

von XML reicht für diese Zwecke völlig aus. Zudem stellt NMM schon Klassen 

zum Parsen von XML-Dateien bereit, welche die Bibliothek libxml2 [lib] verwenden. 

Deshalb wurden erste Implementierungen der Datenverwaltung durch Verwendung 

der NMM-Klassen und damit der libxml2 realisiert. Sie wurde im Laufe dieser 

Arbeit jedoch durch die Xerces-c-Bibliothek [Apa] ersetzt, da diese eine bessere 

Performance bietet, was bei Messungen festgestellt wurde. 

Als Testsystem diente ein PC mit AMD Athlon 3.2GHz-CPU und 512MB DDR- 

SDRAM. Als Bibliotheken kamen libxml2 in Version 2.4.23 und Xerces-c in Version 

2.6 zum Einsatz. Der zu parsende XML-Baum hatte folgenden Aufbau: 

 

 

 

Titel 

Beschreibung 

Kategorie 

 

... 

 

Dabei sind die programme-Elemente für den ersten Durchlauf 100 mal, im zweiten 

500 mal und im dritten 1000 mal wiederholt worden. Der Benchmark umfasste 

das Auslesen des XML-Baumes aus einer Datei, dessen Parsen sowie das Schließen 

der Datei und das Freigeben der verwendeten Ressourcen.. Dies wurde pro 

Datei 100 mal wiederholt und aus den ermittelten Zeiten der Durchschnitt errechnet. 

Zum Ansprechen der libxml2 diente die in NMM vorhandene Wrapper-Klasse 

XMLTree, während die Xerces-c-Bibliothek direkt über ihre C++-API angesprochen 

wurde. Die ermittelten Ergebnisse sind in folgender Tabelle sowie in Abbildung 

4.18 dargestellt: 

libxml2 Xerces-c 

100 0.008 s 0.004 s 

500 0.043 s 0.022 s 

1000 0.086 s 0.045 s 

Daraus ist ein deutlicher Geschwindigkeitsvorteil auf Seiten der Xerces-c-Bibliothek 

zu sehen, weshalb diese schließlich bei der Implementierung der Datenhaltung des 

EPG zum Einsatz kam. 

Als Struktur für die XML-Datei dient das XMLTV-Format, das bereits in Abschnitt 

4.2 vorgestellt wurde. Zur Verwaltung der EPG-Informationen wurde die 

Klasse TVGuideDataManagement entwickelt, die neue Informationen in die 

Daten der XML-Dateien einsortiert und bei einer Anfrage aus diesen ausliest. Das 

65


66 

Abbildung 4.18: Performancevergleich zwischen den XML-Parsern der Bibliotheken 

libxml2 und Xerces-c. 

Klassendiagramm ist in Abbildung 4.19 zu sehen. Die XML-Dateien werden in 

einer Verzeichnis-Struktur gespeichert, welche in Abbildung 4.20 veranschaulicht 

wird. Das EPG-Verzeichnis enthält zwei Dateien mit Namen channels.xml, 

welche die bekannten Kanäle enthält, und categories.xml, in denen die bereits 

bekannten Kategorien gespeichert werden. Dies dient dem schnellen Zugriff 

auf diese Listen. So muss nicht der gesamte Datenbestand durchsucht werden um 

alle verfügbaren Kategorien und Kanäle zu ermitteln. Weiterhin ist für jeden Kanal 

ein Unterverzeichnis angelegt, in dem die Programm-Informationen abgelegt werden. 

Der Name des Unterverzeichnisses wird durch die entsprechende Kanal-ID 

festgelegt. Diese wird von dem EPG-Plugin bestimmt, das den Kanal dem EPG 

hinzugefügt hat. Dort wird für jeden Tag eine eigene Datei erstellt, in der die Informationen 

in einem XML-Baum chronologisch nach ihrer Startzeit gespeichert 

werden. Der Dateiname setzt sich aus dem Tagesdatum und dem Suffix .xml zusammen, 

wobei das Datum in der Form YYYYMMDD dargestellt wird. Durch diese 

Art der Datenhaltung ist bei einer Abfrage ein erneutes Sortieren der Daten nicht 

notwendig. Somit wird der Zeitaufwand reduziert, da eine Abfrage zeitkritischer 

ist als das Einsortieren der Daten. 

Eine wichtige Rolle beim Ablegen oder Erfragen von Daten spielt die angegebene 

Zeit oder der Zeitraum, für den Daten abgelegt oder erfragt werden sollen. Zu 

berücksichtigen ist die Zeitverschiebung zwischen dem Client, der die Daten abruft, 

und dem Server, der sie bereitstellt. Dies spielt im lokalen Fall keine Rolle, 

kann jedoch bei einem Zugriff über das Netzwerk zu falschen Informationen führen. 

Um die entsprechenden Umrechnungen zu vereinfachen und eine einheitliche 

Datenhaltung garantieren zu können, werden die Zeiten der Daten in Coordinated 

Universal Time (UTC) [Wike] gespeichert. Der Client muss dann zur Anzeige 

die Zeiten wieder in seine lokale Zeitzone konvertieren, wie in Abschnittt 4.2.2 

gezeigt.


Abbildung 4.19: Die Klasse TVGuideDataManagement verwaltet die EPG- 

Informationen. 

Abbildung 4.20: EPG-Daten werden in dem Verzeichnis epg gespeichert. Darin 

werden die Dateien channels.xml und categories.xml angelegt. Zusätzlich 

wird zu jedem Sender ein eigenes Unterverzeichnis erstellt, das die Daten für 

die einzelnen Tage auflistet und nach der vorhandenen Kanal-ID des Senders benannt 

ist. 

67


68 

Prioritäten von EPG-Quellen 

Ein Anspruch an den EPG ist die Möglichkeit des parallelen Sammelns von Informationen 

durch unterschiedliche Quellen. Es ist jedoch nicht gewährleistet, dass 

alle Quellen die exakt gleichen Informationen zu entsprechenden Sendungen liefern. 

So gibt z.B. DVB aktuellere und genauere Informationen bzgl. der Anfangszeiten 

als XMLTV. Diese Eigenschaft muss auch beim Einfügen bzw. Aktualisieren 

der Daten berücksichtigt werden. Da der EPG jedoch aus den vorhandenen Daten 

nicht schließen kann, welche Information die richtige ist, wird eine entsprechende 

Reihenfolge der Quellen festgelegt. Daten von höher priorisierten Quellen werden 

bevorzugt. 

Beispiel 

DVB hat eine höhere Priorität als XMLTV. Im EPG existiert nun folgende Information: 

ARD 20:15-22:15 James Bond Quelle: XMLTV 

Die Informationen, die von DVB kommen, besagen jedoch, dass der Spielfilm 3 

Minuten später beginnt: 

ARD 20:18-22:18 James Bond Quelle DVB 

Der EPG aktualisiert seinen Datenbestand und ändert intern die Anfangszeiten der 

Sendung. 

Die Festlegung der Prioritäten erfolgt über das ITVGuidePlugin-Interface eines 

EPG-Plugins. Diese wird vor der Übertragung eines Datensatzes an den EPG 

in der ProgramDescription abgelegt, sodass diese beim Einfügen der Daten 

in den Datenbestand berücksichtigt werden kann. Im Laufe dieser Arbeit wurde 

festgestellt, dass EPG-Informationen von DVB ausführlicher und aktueller sind als 

nxtvepg, welches wiederum mehr Beschreibung zu Sendungen liefert als XMLTV. 

Aus diesem Grund wurden per Default die Prioritäten wie folgt festgelegt: 

DVB Besitzt die höchste Priorität. Daten von XMLTV oder nxtvepg können durch 

Informationen von DVB ersetzt werden. Für DVB wurde per Default der 

Wert 10 festgelegt. 

nxtvepg Besitzt geringere Priorität als DVB, jedoch höhere Priorität als XMLTV. 

Für nxtvepg wurde per Default der Wert 9 festgelegt. 

XMLTV Besitzt die niedrigste Priorität. XMLTV-Daten werden von DVB- oder 

nxtvepg-Informationen überschrieben. Für XMLTV wurde per Default der 

Wert 5 festgelegt. 

Die von den EPG-Plugins gesammelten Daten werden schließlich dem EPG zugesandt, 

woraufhin dieser die Informationen in seiner Verzeichnisstruktur ablegt.

4.3.1 Einfügen der Daten 


Die EPG-Plugins liefern zwei Arten von Informationen, welche der EPG verwalten 

muss. Dies sind zum einen Daten über Sender und zum anderen Programm- 

Informationen. Die Daten sind dabei in ProgramDescriptions und Channel- 

Descriptions gespeichert, wobei jede ProgramDescription die notwendigen 

Kanal-Daten als ChannelDescription enthält. Somit kann der EPG 

feststellen, welchem Sender die Programm-Informationen zugeordnet sind und weiterhin, 

ob ihm der Sender schon bekannt ist oder dem Datenbestand hinzugrfügt 

werden muss. 

Beim Einfügen von Kanälen wird darauf geachtet, dass jeder einzelne nur einmal 

im EPG vorhanden ist um eine doppelte Datenhaltung zu vermeiden. Jedoch ist die 

Schreibweise von Sendernamen, wie in Abschnitt 4.1 beschrieben, bei verschiedenen 

Quellen meist unterschiedlich. Dabei reicht es nicht aus Teile des Namens 

zu vergleichen um auf diese Weise gleiche Sender zu ermitteln. Bei den Schreibweisen 

’Pro 7’ und ’pro sieben’ mag dies zum gewünschten Ergebnis führen, jedoch 

würde für die Sender ’RTL’, RTL 2’ sowie ’Super RTL’ ebenfalls festgestellt 

werden, dass diese den gleichen Sender beschreiben, was jedoch falsch ist. Um 

nunmehr festlegen zu können, dass mehrere Schreibweisen den gleichen Sender 

bezeichnen, werden die Namen als Aliase in der Datei channelAliases.xml 

angegeben, die im XML-Format vorliegt und zuerst bearbeitet werden muss. Diese 

Datei ist wie folgt aufgebaut: 

 

 

Pro7 

PRO-7 

pro sieben 

 

 

ARD 

Das Erste 

 

... 

 

Zum Einfügen eines Kanals in den EPG müssen eine Kanal-ID und ein Kanalname 

angegeben werden. Daraufhin wird getestet, ob dieser Kanal schon vorhanden ist. 

Als erster Test beim Einfügen eines Kanals prüft der EPG auf gleiche ID mit schon 

vorhandenen Kanal-Informationen. Ist dieser negativ, wird der angegebene Kanalname 

geprüft. Dabei müssen alle Namen des vorhandenen Kanals mit denen des 

neuen verglichen werden. Ist wiederum keine Übereinstimmung gefunden, wird 

durch Zugriff auf die Datei channelAliases.xml ermittelt, ob für den einzufügenden 

Kanal ein Alias bekannt ist, das einem schon vorhandenen entspricht. 

Dazu wird solange für jeden in der ChannelDescription angegebenen Kanal- 

Namen die Datei durchsucht, bis er innerhalb eines channel-Elements den Namen 

findet. Somit sind die bekannten Aliase bestimmt und der Name des neuen 

Kanals kann damit verglichen werden. Bei fehlender Übereinstimmung wird dieser 

hinzugefügt. 

69


70 

Auch die Programm-Informationen müssen beim Hinzufügen eine Reihe von Tests 

durchlaufen. Generell werden nur Informationen schon bekannter Kanäle gespeichert 

und dabei auf Überschneidung mit schon vorhandenen Daten getestet. Diese 

werden gegebenenfalls entsprechend der festgelegten Prioritäten angepasst. Um 

die Ordnung in der Datenbank zu wahren, werden alle eingehenden Informationen 

gemäß ihrer Startzeiten in die richtige Position im XML-Baum eingefügt. 

Zur Feststellung von Überschneidungen werden die Start- und Endzeiten der neuen 

Informationen mit vorhandenen verglichen. Dazu werden die gespeicherten Daten 

zu dem entsprechenden Tag ermittelt und sequentiell getestet. 

• Ist für eine bestehende und die neue Information die gleiche Startzeit hinterlegt, 

wird geprüft, ob es sich um die gleiche Sendung handelt. Dies erfolgt 

durch einen Vergleich der angegebenen Titel unter Verwendung von Regulären 

Ausdrücken [Fri03]. Der kürzere Titel dient dabei als Muster, mit dem 

getestet wird, ob dieses in dem längeren vorhanden ist. Sollte der Test negativ 

ausfallen, wird ermittelt, aus welcher Quelle die neue Information stammt. 

Ist dieser eine höhere Priorität zugewiesen, werden die vorhandenen Daten 

zu der Sendung ersetzt. Im positiven Fall werden die Informationen zusammengeführt. 

Dies bedeutet, dass die vorhandene, erweiterte Beschreibung 

überprüft wird. Sollte sie mehr Informationen enthalten, wird die Beschreibung 

ausgetauscht. Als Kriterium dient dafür die Länge der erweiterten Beschreibungen. 

• Sind die Startzeiten unterschiedlich, werden die Informationen hinsichtlich 

der Überschneidung einer Sendung überprüft. Dazu muss weiterhin getestet 

werden, in wieweit sich die Zeiten überdecken, damit die korrekten Informationen 

ersetzt oder zusammengeführt werden können. So ist es unwahrscheinlich, 

dass eine Sendung, die von 20:00 Uhr bis 21:00 Uhr läuft, die 

gleiche ist wie die von 20:58 Uhr bis 22:00 Uhr gezeigt wird. Zudem reicht 

ein einfacher Test bzgl. der Titel der Informationen nicht aus, da bei manchen 

Sendern mehrere Folgen einer Serie hintereinander ausgestrahlt werden, 

die zwar den gleichen Titel besitzen, sich jedoch im Inhalt und damit 

in der Beschreibung unterscheiden. Um möglichst sicher zu gehen, dass es 

sich um die selbe Sendung handelt, müssen sich die Zeitintervalle um mehr 

als 50% überschneiden. Eine 100%ige Überschneidung kann ausgeschlossen 

werden, da meist die Länge der Sendung gleich ist, die Anfangs- und Endzeiten 

jedoch um ein paar Minuten differieren. Beim Experimentieren hat 

sich herausgestellt, dass eine Feststellung von mehr als 70% Überschneidung 

die gewünschten Ergebnisse liefert. Bei kurzen Sendungen, die nur ein paar 

Minuten dauern, wird nur eine Verschiebung von wenigen Minuten berücksichtigt. 

Deshalb wird zu den Endzeiten der Sendungen bei der Berechnung 

der Überlappung ein Offset von 30 Minuten hinzuaddiert. Das garantiert die 

Berücksichtigung einer Verschiebung von mindestens neun Minuten. Sollte 

die Überschneidung kleiner als 70% betragen, folgt eine Überprüfung des 

nächsten Datensatzes. 

Bei einer mehr als 70%igen Überschneidung wird auch hier die Titelangabe 

der Informationen verglichen und die vorhandenen Daten ggf. zusammenge-


führt oder, abhängig von der zugewiesenen Priorität der Quelle, ersetzt. 

• Anschließend erfolgt die Überprüfung, ob die Sendung, zu der neue Informationen 

eintreffen, vor der momentan betrachteten endet. In diesem Fall wird 

die neue Information vor ihr eingefügt um die Sortierung der Daten zu beachten. 

Sollten unmittelbar vor der momentan untersuchten Sendung schon 

Informationen vorhanden sein, wären diese im vorherigen Iterationsschritt 

entdeckt worden. 

• Sollte die neue Information die bisherigen Tests erfolgreich abgeschlossen 

haben, liegt weder eine Überschneidung vor, noch beginnt eine Sendung an 

dem entsprechenden Tag nach ihr. Sie kann an die vorhandenen Daten angehängt 

werden. 

Während der Revision des Algorithmus ergaben sich Gesichtspunkte einer möglichen 

Verfeinerung. Es wurde festgestellt, dass vereinzelt schon vorhandene Informationen 

zu Sendungen nicht erkannt werden. Dies führt zu doppelten aber nicht 

zu fehlenden Daten im EPG. Für die Zukunft könnte der Algorithmus dahingehend 

verbessert werden, dass der Offset dynamisch bestimmt wird und ggf. zusätzliche 

Kriterien zur Feststellung gleicher Sendungen eingeführt werden. 

4.3.2 Abfragen und Durchsuchen der Daten 

Die TVGuide-Klasse bietet die Möglichkeit die Daten nach bestimmten Kriterien 

abzufragen. Zu diesem Zweck stellt es über das ITVGuide-Interface mehrere 

Methoden zur Verfügung, die den vorhandenen Datzensatz unter Berücksichtigung 

unterschiedlicher Kriterien durchsuchen und die gefundenen Ergebnisse zurückliefern. 

Dazu wird zuerst ermittelt, für welchen Kanal Informationen erfragt werden, 

was der Festlegung des Unterverzeichnisses dient. Anschließend wird zur Bestimmung 

der zu öffnenden Dateien der Zeitraum bzw. Zeitpunkt ausgewertet. Dies erfordert 

mindestens die Angabe eines solchen, für den Programm-Informationen gesucht 

werden sollen. Die Spezifizierung des Senders erfolgt durch Übergabe einer 

ChannelDescription, die eine Kanal-ID oder zusätzlich Sendernamen enthalten 

kann. Je nach Abfrage können eine oder mehrere ChannelDescriptions 

angegeben werden. Ein Abfrage-Szenario wird in Abbildung 4.21 dargestellt. Sie 

zeigt die Abfrage von Informationen eines Senders für einen Tag und stellt die 

beteiligten Klassen dar. 

Beispiel 

Es sollen Informationen für die Sendung auf ARD um 20:15 Uhr eines beliebigen 

Tages erfragt werden. Dazu wird zuerst das Verzeichnis bestimmt, in dem die 

Informationen für ARD abgelegt sind. 

Name = Ard => ID = ard.de => Unterverzeichnis ard.de 

71


72 

Abbildung 4.21: Bei der Anfrage nach EPG-Informationen für das Tagesprogramm 

eines Senders erstellt die TVGuide-Klasse einen ProgramFilter 

und übergibt diesen der search()-Methode der TVGuideDatamanagement- 

Klasse. Der TVGuidePeerConnector prüft das Ergebnis auf Vollständigkeit 

und verteilt ggf. die Anfrage im Netzwerk. 

Anschließend wird die Datei festgelegt, welche die Informationen des entsprechenden 

Tages beinhaltet, wobei der Dateiname dem Tages-Datum entspricht. In dieser 

Datei wird nach der Sendung gesucht, die entweder um 20:15 Uhr beginnt oder 

gerade abläuft. Diese Information wird zurückgeliefert. 

Im Folgenden werden nun die zur Verfügung stehenden Abfrage-Methoden für 

Programm-Informationen des ITVGuide-Interface sowie deren Vorgehensweisen 

vorgestellt. 

search(ProgramFilter) 

Diese Methode liefert Informationen zu allen Sendungen, die zu dem angegebenen 

ProgramFilter passen. 

Bei einer Suchanfrage müssen Informationen übergeben werden, die eine Suchmaske 

beschreiben. Für diesen Zweck werden diese in einer serialisierbaren Datenstruktur 

gespeichert, damit sie auch zu entfernten EPGs übertragen werden können, 

wozu die Klasse ProgramFilter (siehe Abbildung 4.22) bereitgestellt wird. 

Diese Klasse beschreibt eine Suchmaske zum Filtern der Daten des EPG. Jene unterstützt 

die Einschränkung der Suche unter Berücksichtigung folgender Kriterien: 

Kanäle Mit Hilfe der Methode addChannel(ChannelDescription) kann 

die Suche auf angegebene Sender eingeschränkt werden. Die Sender-Informationen 

werden in einer ChannelDescription gespeichert, welche 

dem ProgramFilter hinzugefügt wird. 

Zeitraum Unter Verwendung der Methoden setStartTime() und setEnd 

Time() kann ein Zeitraum angegeben werden, für den Informationen gesucht 

werden sollen. Fehlen diese Informationen, werden alle vorhandenen 

Daten durchsucht.


Abbildung 4.22: Die Klasse ProgramFilter speichert eine Suchmaske zum 

Durchsuchen der EPG-Daten. 

Schlagwort Durch die Methode setSearchPhrase() kann ein Schlagwort in 

Form eines Regulären Ausdrucks angegeben werden, der auf Titel und die 

erweiterte Beschreibung der Programm-Informationen angewendet wird. 

Kategorien Mit Hilfe der Methode addCategory() kann nach Sendungen gesucht 

werden, die in eine der angegebenen Kategorien passen. 

Die search(...)-Methode findet vorhandene Informationen, die vor dem Anfangszeitpunkt 

des Intervalls beginnen und innerhalb dessen oder nach dem Endzeitpunkt 

enden oder innerhalb des angegebenen Zeitintervalls beginnen. 

Bei einer Suchanfrage sind zuerst die in der ProgramFilter-Klasse angegeben 

Zeiten in UTC umzurechnen. Anschließend werden die angegebenen Kanäle ermittelt, 

welche die zu durchsuchenden Unterverzeichnisse festlegen. Anhand des 

angegebenen Zeitraums werden die Dateien in Erfahrung gebracht, aus denen die 

Informationen zu ermitteln sind. Bei fehlender Angabe des Zeitraums werden alle 

in einem Unterverzeichnis enthaltenen Dateien durchsucht. 

Für jede Datei werden anschließend, unter Berücksichtigung des Zeitraums, die 

enthaltenen XML-Daten ausgewertet. Dazu gehören Informationen zu Sendungen, 

deren Startzeit in den angegebenen Zeitraum fallen. Sie werden hinsichtlich der in 

der ProgramFilter-Klasse angegebenen Schlagwörter geprüft. Dies geschieht 

unter Verwendung von Regulären Ausdrücken, die auf Titel und Beschreibung der 

Sendungsinformationen angewendet werden. Zuletzt werden die angegebenen Kategorien 

auf Übereinstimmung mit einer zu der Sendung gespeicherten getestet. 

Die auf diese Weise gefundenen Informationen werden in ProgramDescriptions 

gespeichert und der Rückgabeliste hinzugefügt, welche nach dem Ende der 

Suche an den Anwender zurückgeliefert wird. Die Informationen sind nach Kanälen 

sortiert in der Reihenfolge, wie sie im ProgramFilter angegeben sind, da 

73


74 

die Verzeichnisse nach dieser Reihenfolge durchsucht werden. Die Daten zu Programmen 

eines Senders sind auf Grund der Sortierung nach Startzeiten innerhalb 

der XML-Dateien des EPG auch in der Rückgabeliste nach Startzeiten geordnet. 

Der EPG unterstützt zur einfachen Handhabung spezielle Abfrage-Methoden, die 

im Folgenden vorgestellt werden. 

getEventsOnDayOnChannel(day, channel) 

Diese Methode liefert Informationen zu allen Sendungen, die an einem bestimmten 

Tag auf dem angegebenen Kanal laufen. 

Die Abfrage wird mit Hilfe der Funktion search(ProgramFilter) durchgeführt, 

wobei sich der in Frage kommende Zeitraum von 05:00 Uhr bis 04:59 Uhr 

des Folgetages erstreckt. Er richtet sich nach der Konvention, dass in vielen Programmzeitschriften 

der Tag um 05:00 Uhr morgens beginnt und um 05:00 Uhr des 

Folgetages endet. Die Methode liefert alle Sendungen zurück, die innerhalb des 

gesuchten Tages beginnen. Deshalb wird das Resultat des search()-Methode 

dahingehend geprüft, ob die Startzeit der ersten Sendung außerhalb des Intervalls 

liegt. Ist dies der Fall, wird sie entfernt und die restlichen Informationen werden 

zurückgeliefert. Die Zeitinformationen werden durch die Klasse LocalTime 

übertragen. Von diesen werden lediglich die Daten zu dem angegebenen Tag, Monat 

und Jahr ausgewertet. Auf dieser Basis werden die Anfangs- und Endzeit für 

das Suchintervall festgelegt und in dem ProgramFilter gesetzt, welcher der 

search-Methode übergeben wird. 

getEvent(start, end, channel) 

Diese Methode liefert Informationen zu der Sendung, die in dem angegebenen Zeitraum 

auf dem entsprechenden Kanal als erste gefunden wird. 

Hierbei werden nur Informationen zu einer einzigen Sendung zurückgeliefert. Dazu 

legen start und end den Zeitraum, channel den Kanal fest, für den die 

Sendung gesucht werden soll. Zurückgegeben wird das erste Event, dessen Startzeit 

in diesem Intervall gefunden wurde oder das sich mit diesem deckt. 

Zur Ermittlung der gewünschten Information wird auf die search-Methode zurückgegriffen. 

Aus den Parametern der getEvent-Methode wird ein Program- 

Filter erstellt und der search-Methode übergeben. Von den enthaltenen Ergebnissen 

wird das erste Element der ProgramDescription-Liste zurückgeliefert.

getCurrent/FollowingEventOnChannel(channel) 

4.4. VERTEILUNG EINER ANFRAGE IM NETZWERK 

getCurrentEventOnChannel(channel)liefert Informationen zu der Sendung, 

die zur Zeit auf dem angegeben Kanal läuft, getFollowingEventOn- 

Channel(channel) liefert Informationen zu der nachfolgenden. 

Bei dieser Abfrage wird zuerst die aktuelle Uhrzeit bestimmt und die gespeicherten 

Daten nach der Sendung durchsucht, die zu diesem Zeitpunkt laufen oder beginnen 

soll. Bei der Suche nach der nachfolgenden Sendung wird der nächste Datensatz in 

der Datenbank zurückgeliefert. Dabei muss geprüft werden, ob dieser noch in der 

aktuell geöffneten Datei zu finden ist. Ist das nicht der Fall, wird der erste Datensatz 

aus der Datei des nächsten Tages zurückgeliefert. Da alle Informationen in einem 

XML-Baum nach Startzeiten geordnet sind, reicht diese Vorgehensweise aus. 

Die search()-Methode wird lediglich bei der Suche nach Informationen zur 

laufenden Sendung verwendet. Dabei wird die aktuelle Uhrzeit ermittelt und als 

Start- und Endzeit in dem ProgramFilter gesetzt. 

Bei der Suche von nachfolgenden Sendungen kann kein geeignetes Zeitintervall 

angegeben werden, da Sendungen unterschiedliche Startzeiten besitzen. Eine Möglichkeit 

wäre alle Sendungen von jetzt an mit der search()-Methode zu suchen 

um anschließend die Sendung nach der aktuellen zurückzugeben. Aus Effizienzgründen 

wurde jedoch auf diese Art der Implementierung verzichtet, sodass die 

Suche nach folgenden Sendungen in einer eigenen Methode realisiert wurde. Weiterhin 

muss auch auf den Vorgänger der folgenden Sendung geachtet werden, was 

bei der Entscheidung die Anfragen im Netzwerk zu verteilen, wie in Abschnitt 4.4 

beschrieben, berücksichtigt wird. Ist die Endzeit des Vorgängers gleich der ihr folgenden 

Sendung, muss die Anfrage nicht verteilt werden. Zur Vereinfachung der 

Anfrage des Search-Zustandes, der in Abschnitt 4.5.2 erläutert wird und zur einfachen 

Verteilung einer Anfrage im Netzwerk greift die search(...)-Methode 

auf getCurrentEventOnChannel(...) und getFollowingEventOn- 

Channel(...) zurück. So kann in der ProgramFilter-Klasse durch die 

Methoden setCurrentEvents(...)bzw. setFollowingEvents(...) 

festgelegt werden, dass nach Informationen zu momentan laufenden oder folgenden 

Sendungen gesucht werden soll. 

4.4 Verteilung einer Anfrage im Netzwerk 

Wie bereits erwähnt, kann es vorkommen, dass lokal verwendbare EPG-Quellen 

lediglich einen bestimmten Zeitraum bzw. bestimmte Sender abdecken. Als Konsequenz 

daraus existieren nicht zu allen empfangbaren Sendern Programm-Informationen. 

Diese können jedoch wiederum von anderen EPG-Quellen zur Verf ¨gung gestellt 

werden, die auf dem lokalen Rechner nicht verwendet werden können. Diese 

Daten müssen auf anderem Wege beschafft werden. Durch den möglichen Zugriff 

auf im Netzwerk verteilte EPGs können dort lokal fehlende Daten erfragt werden. 

Dies wird durch die in diesem Abschnitt vorgestellte Peer-to-Peer-Funktionalität 

75


76 

analoge 

TV-Karte 

Kanäle: 

ARD 

ZDF 

Applikation 


Netzwerk 

Netzwerk 

TVGuide 

digitale 

TV-Karte 

Kanäle: 

Sat. 1 

Pro 7 

TVGuide 

Internet 

EPG-Quelle 

Kanäle: 

RTL 

RTL2 


Zugriff auf andere EPGs 

Abbildung 4.23: Die lokale Anwendung sammelt selbst keine EPG-Daten, sondern 

erfragt ihre EPG-Daten über die Peer-to-Peer-Funktion des EPG. Die verwendeten 

Quellen der EPGs stellen Informationen für unterschiedliche Kanäle bereit. 

des EPGs realisiert. Dabei gilt es nach Möglichkeit nur bei Bedarf im Netzwerk 

nachzufragen um unnötige Übertragungen zu vermeiden. Dazu muss zuerst festgestellt 

werden, ob Daten fehlen. Abbildung 4.23 zeigt ein mögliches Szenario zur 

Verwendung der Peer-to-Peer-Funktion. Der EPG der lokalen Anwendung sammelt 

selbst keine EPG-Daten, sondern erfragt die Informationen bei Bedarf von 

anderen im Netzwerk verteilten EPGs. Die von ihnen verwendeten Quellen stellen 

alle unterschiedliche Kanäle bereit. 

Zunächst gilt es deshalb zu ermitteln, zu welchen Kanälen Informationen im Netzwerk 

bereitgestellt werden. Dazu wird bei der Abfrage der Kanalliste des EPGs 

diese Anfrage ins Netzwerk weitergeleitet. Diese Informationen sind jedoch statisch, 

d.h. sie ändern sich nicht mehr, wenn der EPG alle Kanäle kennt, für die 

er Daten bereitstellen kann. Daher muss die Anfrage lediglich einmal beim Starten 

des Programms vorgenommen werden. Dazu merkt sich der EPG, ob sie schon einmal 

im Netzwerk verteilt wurde und leitet zukünftige Anfragen nicht mehr weiter. 

Bei Programm-Informationen ist dies anders, weil immer wieder Daten für die 

nächsten Tage hinzukommen. Eine Möglichkeit wäre, die lokal gespeicherten Informationen 

in regelmässigen Abständen auf fehlende Daten zu überprüfen. Dies 

kann jedoch je nach Umfang der Daten eine gewisse Zeit dauern, bis die gewünsch-


Auszug aus dem lokalen Abfrageergebniss für ARD 

17:00 17:05 20:00 20:15 

Tagesschau fehlende Daten Tagesschau 

Anfrage an entfernten EPG: 

Startzeit: 17:05 Uhr 

Endzeit : 20:00Uhr 

Kanal : ARD 

Abbildung 4.24: Der lokale EPG stellt keine Daten für den Zeitraum von 17:05 Uhr 

bis 20:00 Uhr zur Verfügung. Für dieses Intervall wird eine Anfrage im Netzwerk 

gestellt. 

ten Daten verfügbar sind. Angenommen die Kanäle ARD, ZDF und RTL sind dem 

EPG bekannt. In dieser Reihenfolge werden nun die gespeicherten Informationen 

überprüft. Die Daten von ARD werden auf Lücken untersucht. Daraufhin werden 

Programm-Informationen für RTL abgefragt, die jedoch unvollständig sind. Der 

Benutzer muss nun solange warten, bis auch die Daten von ZDF auf Vollständigkeit 

geprüft wurden, bis Daten für RTL gesucht werden. 

Deshalb werden die Anfragen on demand verteilt, d.h., wenn bei einer Abfrage des 

lokalen EPGs das Fehlen von Daten erkannt wird, werden nur Anfragen für diese 

Daten gestellt. Bei einer Abfrage werden zuerst die lokalen Daten durchsucht 

und die Rückgabeliste auf Vollständigkeit geprüft. Zu diesem Zweck werden die 

Start- und Endzeiten der Programm-Informationen dahingehend verglichen, ob die 

Sendungen direkt aufeinanderfolgen. Sollte eine Lücke entdeckt werden, wird im 

Netzwerk für den ermittelten Zeitraum nachgefragt. Abbildung 4.24 stellt eine solche 

Lücke graphisch dar. Für die Zeit von 17:05 Uhr bis 20:00 Uhr fehlen dem 

lokalen EPG Programm-Informationen für den Sender ARD. Für diesen Zeitraum 

sollen nun Daten von entfernten EPGs erfragt werden. 

In manchen Fällen ist es jedoch nicht möglich einen Zeitraum festzulegen. Dies 

trifft für solche Abfragen zu, bei denen Informationen zu einer bestimmten Sendung 

erfragt werden, wie bei einer Abfrage über Informationen zur aktuellen Sendung 

durch die Methode getCurrentEventOnChannel(). Dann wird in Erfahrung 

gebracht, ob die Suche in den lokalen Daten ein Ergebnis lieferte wobei 

überprüft wird, ob die erhaltene ProgramDescription Informationen enthält. 

Andernfalls wird bei entfernten EPGs angefragt. Bei der Suche einer nachfolgenden 

Sendung mittels getFollowingEventOnChannel()wird bei der 

lokalen Suche getestet, ob sich die gefundene Sendung unmittelbar an die vorhergehende 

anschließt. Sollte dies der Fall sein, wird auf eine Anfrage im Netzwerk 

verzichtet, weil keine Lücke vorhanden ist. Zur verteilten Suche wird ein 

ProgramFilter verwendet, bei dem durch dessen Methoden getCurrent- 

Events() bzw. getFollowing Events() die entsprechenden Flags zur Su- 

77


78 

Durch diesen Zugriff 

würde eine Schleife 

entstehen, wodurch die 

Anfrage unendlich im 

Netzwerk zirkulieren 

würde. Das muss 

vermieden werden. 

analoge 

TV-Karte 

Applikation 


Netzwerk 

Netzwerk 

TVGuide 

digitale 

TV-Karte 

TVGuide 

Internet 

EPG-Quelle 


Zugriff auf andere EPGs 

Abbildung 4.25: Die lokale Anwendung sammelt selbst keine EPG-Daten, sondern 

erfragt ihre Informationen über die Peer-to-Peer-Funktion des EPG. Dabei 

muss jedoch verhindert werden, dass einer der EPGs die Anwendung wiederum 

nach Informationen befragt. Dadurch würde eine Anfrage unendlich im Netzwerk 

zirkulieren. 

che nach aktuellen bzw. folgenden Sendungen gesetzt werden. 

Ein Sonderfall stellt die Suche mittels der search()-Methode dar. Durch die Angabe 

von Schlagwörtern oder das Einschränken auf Kategorien kann nicht sicher 

überprüft werden, ob die Informationen vollständig sind. Die Suche wird deshalb 

generell im Netzwerk verteilt um für diese Abfrage ein möglichst umfassendes 

Ergebnis zu erhalten. 

Zu Beginn muss dem EPG mitgeteilt werden, welche Rechner bereitstehen, die bei 

Bedarf befragt werden können. Diese werden in den Konfigurations-Einstellungen 

der Anwendung festgelegt und von der TVGuideConfigurator-Klasse aus 

Abschnitt 4.2 ermittelt und gesetzt. Die entfernten EPGs wiederum können die 

Anfrage zu weiteren ihnen bekannten Rechnern weiterleiten, wobei jedoch eine 

Schleife vermieden werden muss, d.h. jede einzelne Anfrage darf in dem gesamten 

Peer-to-Peer-Netzwerk an jeden EPG genau nur einmal gestellt werden. Ein 

solches Szenario ist in Abbildung 4.25 gezeigt wo die Anfrage an den EPG der 

Anwendung gestellt wird, welche diese initiiert hat. Dadurch würde die Anfrage 

unendlich im Netzwerk zirkulieren und immer wieder Daten liefern, welche dem 

EPG schon bekannt sind. Aus diesem Grund wird bei einer Suche im Netzwerk zusätzlich 

eine Liste von Rechnernamen übertragen, die angibt, welche die Anfrage


Abbildung 4.26: Die Klasse TVGuidePeerConnector. 

schon einmal bearbeitet haben. Bei der Weiterleitung der Suche wird geprüft, ob 

der nächste Rechner in der Liste der schon befragten enthalten ist. Sollte dies nicht 

der Fall sein, wird die Anfrage an ihn gestellt. Dazu stellt der ProgramFilter 

die Methoden addPeerHost() und containsPeerHost(string) bereit, 

über die ermittelt werden kann, welche Rechner die Anfrage bereits passiert hat. 

Somit lässt sich auch später noch feststellen, welchen Weg die Anfrage durch das 

Netzwerk genommen hat. 

Zur Realisierung der Peer-to-Peer-Funktionalität wurde die Klasse TVGuide- 

PeerConnector entwickelt (siehe Abbildung 4.26). Sie dient der Erkennung 

unvollständiger Abfrage-Ergebnisse und erfragt bei entfernten EPGs fehlende Daten. 

Zur Erkennung von Lücken wird der Abfrage-Zeitraum berücksichtigt, für den 

Daten angefordert werden. In Abschnitt 4.3 wurde bereits beschrieben, dass bei einer 

Abfrage die Daten nach Startzeiten sortiert sind. Dadurch entfällt ein erneutes 

Sortieren vor der Lückenermittlung. War die lokale Abfrage ergebnislos, kann die 

volle Anfrage an die verteilten EPG’s gestellt werden. 

Zur Lückenermittlung der Abfrageergebnisse für einen Sender stellt der TVGuide- 

PeerConnector die verify()-Methode bereit. Neben der Ergebnisliste und 

der Kanal-Information erhält diese Methode einen Zeitraum, der durch eine Startund 

eine Endzeit festgelegt ist. Die Kanal-Informationen müssen übergeben werden 

um auch bei einer leeren Ergebnisliste festzustellen, für welchen Sender EPG- 

Daten erfragt werden sollen. Die Methode prüft nun, ob der Zeitraum von den Informationen 

in der Ergebnisliste komplett abgedeckt ist. Bei der Lückenermittlung 

werden die Startzeit einer Sendung mit der Endzeit der vorangegangenen verglichen. 

Ist die Endzeit kleiner als die Startzeit wird ein ProgramFilter erstellt, 

unter Verwendung dessen eine Anfrage im Netzwerk gestellt wird. Dieser enthält 

die Zeiten welche die Lücke beschreiben als zu durchsuchendes Zeitintervall sowie 

die Kanal-Informationen, die bei dem verify()-Aufruf übergeben wurden. 

Durch dieses Vorgehen werden bei einem entfernten EPG lediglich nach den benötigten 

Programm-Informationen gesucht, was den Vorgang beschleunigt. 

79


80 

Abbildung 4.27: Verteilung einer Anfrage am Beispiel der Suche mittels der 

search(...)-Methode. Nach der Suche in den lokalen EPG-Daten wird die 

Suche unter Verwendung der Klasse TVGuidePeerConnector im Netzwerk 

verteilt. Da dies im Hintergrund geschieht, kehrt die search()-Methode nach 

dem Initiieren der Anfrage zurück. Ist die Suche des entfernten TVGuide beendet, 

werden die Daten dem loaklen EPG zugeführt. 

Verteilung der Anfrage 

Bei der Verteilung einer Anfrage im Netzwerk wurde darauf geachtet, dass lokale 

Ergebnisse schnell zur Anwendung zurückgelangen. Dies erfordert eine nichtblockierende 

Abfrage entfernter Rechner, d.h. der lokale EPG kehrt nach der lokalen 

Suche aus der Methode zurück. Im Hintergrund wird nun die Anfrage an den 

entfernten EPG weitergeleitet, der das Ergebnis seiner lokalen Suche zurückliefert. 

Dieser stellt wiederum im Hintergrund eine Anfrage an den nächsten Host usw. 

(siehe Abbildung 4.27). Somit blockiert die Methode bei einer Suchanfrage nicht 

solange, bis das gesamte Netzwerk durchsucht wurde, sondern die lokal ermittelten 

Daten gelangen unmittelbar zur Anwendung zurück. Dadurch kann mit der anfragenden 

Anwendung weitergearbeitet werden, solange im Netzwerk gesucht wird. 

Damit die Funktionen bei der Suche und beim Einfügen der gesammelten Daten in 

die lokale Datenbank nicht blockieren, werden intern Handler-Klassen verwendet, 

welche ihre Aktionen in einem separaten Thread ausführen.


Abbildung 4.28: Die gezeigten Handler-Klassen werden innerhalb der Peer-to- 

Peer-Funktionalität zum Erfragen und Einfügen von Informationen verwendet. 

Diese Handler-Klassen werden in Abbildung 4.28 gezeigt und sind im einzelnen: 

• TVGuidePeerChannelRequestHandler Diese Klasse erfragt bereitgestellte 

Kanäle eines entfernten EPGs. 

• TVGuidePeerEventRequestHandler Diese Klasse stellt Anfragen 

nach Programm-Informationen an entfernte EPGs. 

• TVGuidePeerInsertChannelHandler Diese Klasse sortiert eingehende 

Kanal-Informationen in die lokalen Daten ein und benachrichtigt vorangegangene 

EPGs über die gefundenen Informationen. 

• TVGuidePeerInsertEventHandler Diese Klasse sortiert eingehende 

Programm-Informationen in die lokalen Daten ein und benachrichtigt vorangegangene 

EPGs über die gefundenen Informationen. 

Soll eine neue Suche gestartet oder Daten einsortiert werden, wird die Anfrage 

in eine Queue gestellt. Die Handler-Klassen können durch Aufruf entsprechender 

Methoden der TVGuidePeerConnector-Klasse Anfragen oder einzusortierende 

Informationen aus der entsprechenden Queue entnehmen und abarbeiten. 

Die Queue für Anfragen speichert Paare, die aus einem ProgramFilter bestehen, 

der die Anfrage enthält, und einer Liste von ITVGuidePeerObject- 

Interfaces, die den bisherigen Weg der Anfrage durch das Netzwerk beschreiben. 

Sie müssen bei einer Anfrage an den entfernten EPG weitergegeben werden. 

Zur Erstellung eines Handlers erfragt der TVGuidePeerConnector bei 

der TVGuidePeerHandlerFactory (siehe Abbildung 4.29) einen verfügbaren 

Handler und startet diesen. 

Die TVGuidePeerHandlerFactory wurde erstellt nach dem Entwurfsmuster 

Factory Method aus [GHJV95]. Dabei wird das Erstellen von Objekten an eine 

Klasse delegiert. Die benötigten Objekte werden durch Aufrufen entsprechender 

Methoden der Factory-Klasse erstellt und ein Zeiger darauf zurückgegeben. Das 

Entwurfsmuster wurde für die Zwecke der Handler-Erstellung angepasst, so dass 

Zeiger auf bereits erstellte und inaktive Handler zurückgeliefert werden, sofern diese 

verfügbar sind. Somit können bereits erstellte Handler für zukünftige Anfragen 

81


82 

Abbildung 4.29: Die Klasse TVGuidePeerHandlerFactory. 

wiederverwendet werden. (siehe Abbildung 4.30). Da Anfragen nach bereitgestellten 

Sendern nur einmal durchgeführt werden, müssen die Channel-Handler nur 

einmal erstellt werden und werden daher intern in einer Variable gespeichert. Die 

Event-Handler werden in einer map abgelegt, da mehrere von ihnen erstellt werden 

sollen um eine schnelle Abarbeitung der Anfragen vornehmen zu können. Dabei 

werden jedoch nur maximal fünf Event-Handler erstellt um die Ressourcen des Systems 

nicht zu sehr zu belasten und die Wiedergabe von Multimedia-Daten nicht zu 

beeinträchtigen. Bei der Anfrage nach einem Handler wird ermittelt, welcher inaktiv 

ist. Von dem ersten gefundenen Handler wird ein Zeiger darauf zurückgeliefert 

und dieser von dem TVGuidePeerConnector aktiviert. Der Handler entnimmt 

aus der Queue eine Anfrage und führt diese aus. 

Zur Unterstützung der Peer-to-Peer-Anfrage implementiert die TVGuide-Klasse 

das ITVGuidePeerSearch-Interface (siehe Abbildung 4.31). Über die Methoden 

dieses Interfaces wird eine Suchanfrage von einem entfernten EPG entgegengenommen. 

Dadurch ist die entfernte Suche von der lokalen getrennt, da bei 

der Peer-To-Peer-Suche auch eine Liste von ITVGuidePeerObject-Interfaces 

aller bisher besuchten EPGs übertragen werden muss. Zudem dient diese Methode 

nur der Peer-To-Peer-Funktionalität, wobei die Methoden des ITVGuide- 

Interfaces dem direkten Zugriff auf den EPG durch Applikationen dienen. Die Anfrage 

wird mittels eines TVGuidePeerEventRequestHandlers gestellt, der 

das ITVGuidePeerSearch-Interface des entfernten EPG anfordert und auf diesem 

die Methode peerSearch(...) aufruft. 

Nach dem Einsortieren der erhaltenen Programm-Informationen des entfernten 

EPGs wird festgestellt, welche EPGs weiterhin über das Ergebnis informiert werden 

sollen. Dazu implementiert die Klasse TVGuidePeerConnectordas ITV- 

GuidePeerObject-Interface (siehe Abbildung 4.31), durch dessen Methoden 

Programm-Informationen an die bisher besuchten EPGs weitergeleitet werden können. 

Diese sortieren die Daten wiederum in ihre lokalen ein. So werden die Informationen 

bis zu dem EPG weitergereicht, der die Anfrage initiiert hat. Bei einer 

Suchanfrage wird daher gleichzeitig eine Liste dieser Interfaces übertragen. Sie ist 

sortiert nach den Rechnern, welche die Anfrage auf dem Weg durch das Netzwerk 

passiert hat. 

Das Sequenzdiagramm einer Anfrage wird in Abbildung 4.32 gezeigt. Eine Anwendung 

stellt mittels der search(...)-Methode eine Anfrage an den EPG. 

Dieser durchsucht seine lokalen Daten und liefert das Ergebnis zurück. Die in


Abbildung 4.30: Anfragen eines Event-Request-Handlers bei der Factory. Diese 

ermittelt unter den bisher erstellten Handlern einen inaktiven und liefert einen Zeiger 

auf diesen zurück. Konnte kein inaktiver Handler gefunden werden, wird ein 

neuer erstellt und ein Zeiger auf diesen zurückgegeben. 

Abbildung 4.31: Die Interfaces ITVGuidePeerSearch und ITVGuide- 

PeerObject dienen der Unterstützung der Peer-to-Peer-Funktionalität. 

83


84 

Abbildung 4.32: Zur Verteilung einer Anfrage erfragt die TVGuidePeer- 

Connector-Klasse einen TVGuidePeerEventRequestHandler, der die 

Anfrage an den entfernten EPG durchführt. Die erhaltenen Ergebnisse werden 

durch einen TVGuidePeerInsertEventHandler im Hintergrund in die lokalen 

Daten einsortiert. 

dem ProgramFilter spezifizierte Anfrage wird mittels des TVGuidePeer- 

Connectors an einen entfernten EPG weitergeleitet. Die Kanal-Informationen 

werden als Parameter der verify()-Methode übergeben und in dem Program- 

Filter mitübertragen. So kann der entfernte EPG daraus die gewünschten Kanäle 

bestimmen. Die Auswertung geschieht in der Klasse TVGuideDatamanagement, 

wie in Abschnitt 4.3 beschrieben. Die von dem entfernten EPG gelieferten 

Ergebnisse werden dem lokalen EPG hinzugefügt. 

Über Ergebnisse der Suche wird der TVGuide durch sein ITVGuidePeerObject-Interface 

benachrichtigt, welche durch Erstellen eines TVGuidePeerInsertEventHandler 

den lokalen Daten hinzugefügt werden. Weiterhin wird 

anhand der übertragenen Interface-Liste ermittelt, welcher EPG über die Suchergebnisse 

als nächstes informiert werden soll. Dessen Interface wird aus der Liste 

entfernt und die erhaltenen Ergebnisse an ihn weitergeleitet. Dies beschleunigt das 

Propagieren der Ergebnisse im Netzwerk bis zu der Anwendung, welche die Anfrage 

initiiert hat.

4.4.1 Der EPG als eigenständige Anwendung 

4.5. INTEGRATION IN DIE MULTIMEDIA-BOX 

Um den EPG als eigenständigen Prozess zu realisieren wurde die Anwendung 

tvgserver entwickelt. Diese dient dazu einen EPG auf lokalen oder entfernten 

Rechnern zur Verfügung zu stellen, mit dem sich eine Applikation verbinden kann 

um Informationen zu erfragen. Zu diesem Zweck ist der EPG als Service unter dem 

Namen ’TVGuide’ angeboten, den man unter Verwendung der ServiceProxy- 

Klasse ansprechen kann (vergleiche Abschnitt 3.2.1). Beim Starten der Anwendung 

können über Kommandozeilen-Parameter die einzelnen EPG-Plugins aktiviert 

werden. Die Konfiguration derer kann durch Bearbeiten der entsprechenden 

Konfigurations-Dateien im Verzeichnis /resources/tvguidevorgenommen 

werden (Siehe Anhang B). 

4.5 Integration in die Multimedia-Box 

Zur Anzeige der EPG-Daten in der Multimedia-Box wurde diese um zwei Zustände 

erweitert, mit denen EPG-Informationen angezeigt oder durchsucht werden 

können. Der TVGuide-Zustand dient dem reinen Anzeigen der EPG-Daten, der 

Search-Zustand dem Durchsuchen der Daten mit einer zuvor spezifizierten Suchmaske. 

Weiterhin wird im Folgenden der LiveTV-Zustand um die Anzeige von 

EPG-Informationen zu momentan laufenden und folgenden Sendungen ausgebaut. 

4.5.1 Der TVGuide-Zustand 

Zur Darstellung der gesammelten EPG-Informationen wurde die Multimedia-Box 

um den TVGuide-Zustand erweitert. Die Daten werden geordnet nach Tagen und 

Sendern angezeigt, was das Blättern in den Daten, vergleichbar mit dem in einer 

Programmzeitschrift, ermöglicht und unterstüzt folgende Funktionen: 

• Anzeige der gespeicherten Informationen zu Sendungen 

• Auswahl einer Sendung zur Programmierung einer Aufnahme 

• Markieren einer Sendung, für die eine Aufnahme programmiert ist 

Damit der Benutzer sich leicht zurechtfindet, wird an die graphische Benutzerschnittstelle 

(Graphical User Interface (GUI)) die Anforderung gestellt, alle Informationen 

übersichtlich darzustellen und nicht erst durch zusätzlichen Knopfdruck 

zugängig zu machen. Weiterhin zeigen Untersuchungen über das Benutzerverhalten 

bzgl. EPGs [Bon03], dass Anwender, die den EPG nutzen, folgende Informationen 

wünschen: 

• Was läuft jetzt/anschließend auf allen Sendern? 

• Was läuft zu einer bestimmten Uhrzeit auf allen Sendern? 

85


86 

Abbildung 4.33: Diese Abbildung zeigt den TVGuide-Zustand, während im Hintergrund 

der LiveTV-Zustand aktiv ist. Die Benutzeroberfläche ist in vier Widgets 

aufgeteilt. Links oben wird die Auswahl des Wochentages vorgenommen, darunter 

erfolgt die Auswahl des Senders, für den Informationen angezeigt werden sollen. 

Die rechte Seite zeigt das Tagesprogramm des gewählten Senders an dem gewählten 

Wochentag (unten), Darüberhinaus werden erweiterte Informationen zu 

der markierten Sendung angezeigt. 

• Was läuft an einem bestimmten Tag auf einem Sender? 

Bei der Entwicklung und Gestaltung des Zustandes wurde dieser Aspekt berücksichtigt. 

Die meisten Home Entertainment Systeme zeigen die TV-Informationen in einer 

Tabelle an. Dabei markieren die einzelnen Zeilen die Sender, die Spalten die Uhrzeiten. 

Diese Anordnung der Informationen ließ sich durch die von der Multimedia- 

Box vorgegebene Steuerung der Zustände nicht realisieren. Diese sieht vor, dass 

Widgets (siehe Abschnitt 3.3) durch Drücken der Tasten ’Rechts’ bzw. ’Links’ auf 

der Fernbedienung gewechselt werden. Die Navigation innerhalb des Widgets wird 

mit den Tasten ’Hoch’ bzw. ’Runter’ vorgenommen. Zur Steuerung in der Tabellenansicht 

würden die Tasten ’Rechts’ bzw. ’Links’ innerhalb eines Widgets ebenfalls 

dazu verwendet werden, was im Widerspruch zur Bedienung der restlichen 

Zustände stünde. 

Bei der Positionierung und Festlegung der Größe der Widgets soll der vorhandene 

Platz optimal ausgenutzt werden. Aus diesem Grund wurde die Anzeige des 

TVGuide-Zustandes in vier Widgets aufgeteilt, wie in Abbildung 4.33 zu sehen 

ist: 

• Im linken Teil der Anzeige befindet sich oben das Tages-Widget zur Auswahl 

des Tages und darunter das Sender-Widget zur Auswahl des Senders, 

für die Informationen angezeigt werden sollen. Sie stellen die Filterkriterien 

dar. Die Größe des Tages-Widgets orientiert sich an der Anzahl der Wochentage 

und dem längsten Wochentagnamen. Dies legt sowohl die Breite des


Abbildung 4.34: Einprogrammierte Aufnahmen werden mit einem ’R’ gekennzeichnet. 

Weitere Informationen sind in dem Widget zur erweiterten Beschreibung 

enthalten. 

Sender-Widgets, als auch dessen Höhe fest, welche den verbliebenen Platz 

einnimmt. Dies lässt die Anzeige klar strukturierter wirken. 

• Auf der rechten Seite werden die Programminformationen dargestellt. Das 

untere Widget, das Programm-Widget, zeigt die sortierte Liste der Sendungen 

des gewählten Tages und Senders, wobei die aktuell laufende Sendung 

beim Aktivieren des Zustandes vorselektiert wird. Es ist jeweils die Anfangszeit 

der Sendung sowie deren Titel angezeigt. Wurde zudem eine Aufnahme 

für diese Sendung programmiert, wird dies mit dem Buchstaben ’R’ hinter 

dem Titel gekennzeichnet (’R’ steht für ’Recording’, was im deutschen 

’Aufnahme’ bedeutet). Dies ist in Abbildung 4.34 zu sehen 

Im oberen Widget, dem Informations-Widget, werden erweiterte Informationen 

zu der momentan gewählten Sendung angezeigt. Hier werden deren genauen 

Anfangs- und Endzeiten sowie eine vorhandene erweiterte Beschreibung 

und zugehörige Kategorien dargestellt. Ist zu der Sendung eine Aufnahme 

programmiert, werden hier zusätzliche Informationen angezeigt. 

Die Positionierung und Größe dieser Widgets orientiert sich an den zuvor 

besprochenen Widgets zur Anzeige der Wochentage und Kanäle. Zur klareren 

Strukturierung der Anzeige sind die Höhen angepasst, die Breiten des 

Programm- und des Informations-Widgest sind durch den verbliebenen Platz 

festgelegt. Durch diese Aufteilung ist das Programm-Widget das größte, 

weshalb dieses zur Anzeige des Tagesablaufes verwendet wird um möglichst 

viele Informationen sichtbar zu machen. 

Diese Art der Anzeige vermittelt dem Benutzer einen Überblick über das Tagesprogramm 

eines bestimmten Senders. Zusätzlich besteht die Möglichkeit festzustellen, 

was auf anderen Sendern zu einer entsprechenden Uhrzeit gezeigt wird, indem er 

zu der gewünschten Uhrzeit ein Programm markiert und durch die Senderliste blättert. 

87


88 

Bedienung 

Abbildung 4.35: Die Klasse TableUnit. 

Die Bedienung ist den restlichen Multimedia-Box-Zuständen angepasst. Das Wechseln 

der Widgets geschieht mit den Tasten ’Rechts’ bzw ’Links’, mit Hilfe der 

Tasten ’Hoch’ und ’Runter’ können in den Widgets Einträge selektiert werden. 

Durch Drücken des roten Farbknopfes wird für die gewählte Sendung eine Aufnahme 

programmiert, woraufhin die Anwendung in den TVTimer-Zustand wechselt, 

der in Abschnitt 5.4.1 vorgestellt wird. Sollte die Programmierung auf Grund eines 

Konfliktes fehlschlagen, wird eine entsprechende Fehlermeldung eingeblendet und 

die Anwendung verbleibt im TVGuide-Zustand. 

Man kann auch direkt zu den entsprechenden Sendern durch Drücken des blauen 

Farbknopfes umschalten. Dabei wird in den LiveTV-Zustand gewechselt, der in 

Abschnitt 5.4.2 beschrieben wird. 

TableUnit 

Zur übersichtlicheren Darstellung des Tagesablaufes im TVGuide-Zustand wurde 

der OSDManager der Multimedia-Box um eine zusätzliche Widgetunit, die 

TableUnit, erweitert. 

Die TableUnit zeichnet sich dadurch aus, dass der Inhalt in mehreren Spalten 

anzeigbar ist, wodurch sich die Anzeige leichter strukturieren und die Übersicht 

verbessern lässt. In einer ersten Implementierung zur Anzeige des Tagesablaufes


wurde die ListUnit [Kle03] verwendet, die lediglich eine Spalte zur Anzeige 

von Textzeilen bereitstellt. Eine Trennung von Uhrzeit und Titel war damit nur 

durch Angabe von Leerzeichen möglich. Da jedoch Buchstaben und Ziffern keine 

einheitliche Breite aufweisen, war eine rechtsbündige Ausrichtung der Titel nicht 

möglich. Für eine korrekte Formatierung können nun die Startzeiten sowie die Titel 

unter Verwendung der TableUnit in eine eigene Spalte geschrieben werden. 

Die TableUnit verwaltet dazu eine Liste von TextViews, die in Abschnitt 3.3 

vorgestellt wurden. Somit ist es möglich jeder Zelle der Tabelle ein Text zur Anzeige 

zuzuweisen. 

Im Folgenden werden ausgewählte Methoden der TableUnit erklärt. Alle Methoden 

sind aus dem Klassendiagramm in Abbildung 4.35 ersichtlich: 

void setColumnWidth( unsigned int c, unsigned int w ) setzt die Breite der Spalte 

c auf w Prozent der Gesamtbreite des Widgets 

void addColumn(unsigned int w) fügt eine Spalte der Breite w hinzu, wobei w 

die Breite in Prozent der Gesamtbreite des Widgets angibt. 

unsigned int getSelectedLine() gibt die Nummer der selektierten Zeile zurück. 

string getLineURL(const unsigned int i) liefert die Zeilen-URL der i-ten Zeile. 

In einer Zeilen-URL kann ein spezieller Text gespeichert werden, der 

dazu verwendet werden kann den Inhalt einer Zeile genauer zu beschreiben 

[Kle03]. 

void selectLine(const unsigned int& i) selektiert die i-te Zeile. 

void selectLine2(const unsigned int& i) selektiert die i-te Zeile in einer anderen 

Farbe als selectLine().Die Farbe wird mit dem Methode setColors() 

festgelegt. 

string getLineContent(const unsigned int c, const unsigned int i) liefert den Inhalt 

der c-ten Spalte der i-ten Zeile zurück. 

list getLineContent(const unsigned int i) liefert den Inhalt aller Spalten 

der i-ten Zeile zurück. 

void setLineContent(const unsigned int c, const unsigned int i, string s) setzt den 

Inhalt der c-ten Spalte in der i-ten Zeile. 

void deleteAllLines() löscht die Zeilen des Widgets. Die Einstellungen zur Anzahl 

der Spalten bleibt erhalten. 

unsigned int addLine(list c, string url) fügt eine Zeile hinzu. Die Spalten 

erhalten den Inhalt der Liste c und die Zeile die Zeilen-URL 

unsigned int addLine(list c) fügt eine Zeile hinzu. Die Spalten erhalten 

den Inhalt der Liste c. 

void deSelectLine() deselektiert eine Zeile. 

89


90 

Result selectUp() setzt die Markierung eine Zeile nach oben. 

Result selectDown() setzt die Markierung eine Zeile nach unten. 

void setScrollbarEnabled(bool enabled) blendet die Scrollbar ein oder aus. 

bool getScrollbarEnabled() liefert den Status, ob die Scrollbar angezeigt wird. 

int getNumLines() liefert die Anzahl der Zeilen des Widgets zurück. 

Implementierung 

Der TVGuide-Zustand initialisiert und konfiguriert ein Objekt der TVGuide-Klasse, 

wenn er sich nicht über das Netzwerk zu einem anderen EPG verbinden soll. Dazu 

werden die entsprechenden Variablen aus der in Abschnitt 3.3 vorgestellten Konfigurationsdatei 

der Multimedia-Box gelesen. Hier werden alle zu verwendenden 

EPG-Quellen angegeben und die entsprechenden Plugins geladen. Durch Pluginspezifische 

Variablen lassen sich diese weiter konfigurieren. Eine Übersicht der 

Variablen befindet sich in Anhang A. Das TVGuide-Objekt wird nun als Service 

in der Multimedia-Box registriert, sodass sich andere Anwendungen mit diesem 

Service zur gemeinsamen Datennutzung verbinden können. 

Die verfügbaren Kanäle des EPG werden zur Anzeige ausgelesen und vor dem 

Füllen des entsprechenden Widgets sortiert. Als Vorgabe der Reihenfolge dient 

dabei die Kanalliste des LiveTV-Zustandes (siehe Abschnitt 5.4.2). 

Das Abfragen der Informationen bei dem TVGuide-Objekt geschieht über die 

Methode 

list ITVGuide:: 

getEventsOnDayOnChannel(day, channel); 

Dazu werden die Einstellungen in den Widgets für den Tag bzw. den Kanal ausgewertet 

und die ermittelten Werte der Funktion übergeben. Da die Ergebnisliste 

schon sortiert ist, entfällt ein erneutes Ordnen. Mit den in der Liste enthaltenen 

Informationen werden die entsprechenden Widgets zur Anzeige des Tagesprogramms 

und der erweiterten Informationen gefüllt. 

Um über neu eintreffende EPG-Daten informiert zu werden, registriert die Anwendung 

EventListener bei dem TVGuide für Methoden dessen ITVGuide- 

Events-Interface, was eine automatische Aktualisierung der Anzeige ermöglicht. 

4.5.2 Der Search-Zustand 

Der Search-Zustand wurde zum Durchsuchen der EPG-Informationen nach selbst 

angegebenen Kriterien entwickelt. Der Zustand erlaubt die Vorgabe eines zu analysierenden 

Zeitraumes, die Einschränkung auf bestimmte Kanäle, die Angabe von 

Schlagworten und die Auswahl von Kategorien zur Verfeinerung der Suche. Eine


Abbildung 4.36: Diese Abbildung zeigt die Eingabemaske des Search-Zustandes. 

Links oben kann eine Auswahl vordefinierter oder vom Benutzer erstellter Bookmarks 

vorgenommen werden, darunter wird das Widget zur Eingrenzung der Suche 

auf bestimmte Kanäle angezeigt. Im rechten Teil der Anzeige kann die Suche durch 

Festlegen eines Zeitraums, die Angabe eines Schlagwortes oder die Auswahl von 

Kategorien eingeschränkt werden. 

mögliche Suchanfrage kann z.B. lauten: 

Welche Sendungen laufen ab dem 10.10.2005 um 10:23 Uhr in den Programmen 

von ZDF, SAT.1, VOX und KiKa, deren Titel oder erweiterte Beschreibung das 

Schlagwort ’bernd’ enthalten? 

Die Einstellungen für diese Anfrage sind in Abbildung 4.36 ersichtlich. Weiterhin 

können die eingebenen Kriterien für eine spätere Suche als Bookmarks gespeichert 

werden. Als Bookmark wird in diesem Fall ein Lesezeichen verstanden, mit dessen 

Hilfe schnell auf gespeicherte Suchkriterien zugegriffen werden kann. 

Graphische Benutzeroberfäche 

Beim Aktivieren des Zustandes wird die Suchmaske eingeblendet, in der die Suchkriterien 

festgelegt werden können. 

• In der linken oberen Ecke befindet sich das Bookmark-Widget, das eine Auswahl 

von vorgefertigten und selbst erstellten Suchmustern enthält. Hier besteht 

die Möglichkeit der Auswahl zwischen der Angabe eines neuen Suchmusters 

und der Suche nach aktuell laufenden bzw. folgenden Sendungen. 

Diese lässt sich durch Angabe weiterer Kriterien einschränken. Die Senderauswahl 

kann in dem Kanalauswahl-Widget vorgenommen werden, das sich 

unter dem Bookmark-Widget befindet. Es unterstützt sowohl die Auswahl 

eines einzelnen Senders als auch eine Mehrfachauswahl. 

• Im rechten Teil der GUI kann der Suchfilter verfeinert werden. Zu diesem 

Zweck kann ein Zeitraum angegeben werden, welcher jedoch bei der Suche 

nach aktuellen oder folgenden Sendungen fest vorgegeben ist. Deshalb sind 

91


92 

Abbildung 4.37: Die Anzeige der Suchergebnisse zeigt im oberen Widget eine 

chronologisch geordnete Liste der gefundenen Informationen. Hier kann eine Sendung 

ausgewählt werden, deren Informationen im unteren Widget erscheinen. 

bei Auswahl dieser Suchfilter die entsprechenden Widgets nicht sichtbar. Darunter 

befindet sich ein Eingabe-Widget zur Spezifizierung von Schlagworten, 

die entweder im Titel einer Sendung oder in der Beschreibung vorkommen 

sollen. Die beiden unteren Widgets dienen zur Auswahl einer Kategorie. 

Zur Unterstützung kann durch Eingabe der Anfangsbuchstaben eine Kategorie 

in der Liste gesucht werden. Angenommen, die Kategorie Spielfilm ist die 

einzige, die mit dem Buchstaben ’S’ beginnt. Durch Eingabe dieses Buchstabens 

in das Widget über der Kategorienliste springt die Markierung auf die 

Kategorie ’Spielfilm’. Sind alle Einstellungen erfolgt, kann dieser Suchfilter 

zur späteren Wiederverwendung gespeichert werden. Dazu wird ein Dialog 

eingeblendet, worin man einen Namen für den Suchfilter festlegen kann. 

Nun kann die Suche gestartet werden. Sie führt zu einer Ergebnisübersicht, die 

aus zwei Fenstern besteht. Das Suchergebnis des oben angegeben Beispiels zeigt 

Abbildung 4.37. 

• Im oberen Widget wird eine Liste mit gefundenen Informationen angezeigt, 

wobei zur besseren Übersicht nur die Anfangszeit und der Titel einer Sendung 

ersichtlich sind. 

• Im unteren Widget werden alle verfügbaren Informationen zu einer ausgewählten 

Sendung gezeigt. Auch hier ist es wieder möglich eine Aufnahme 

für eine ausgewählte Sendung zu programmieren oder in den LiveTV- 

Zustand auf den entsprechenden Kanal zu wechseln. 

Bedienung 

Auch bei dieser Vorgehensweise wurde nicht von den Vorgaben des Multimedia- 

Box-Frameworks abgewichen. Das Wechseln zwischen den Widgets geschieht mit

Abbildung 4.38: Die Klasse TextInput. 


den Tasten ’Rechts’ und ’Links’. Innerhalb einer Liste kann mit ’Hoch’ und ’Runter’ 

entsprechend navigiert werden. Die Mehrfach-Auswahl bei Sendern und Kategorien 

erfolgt über die Funktionstasten ’Rot’ und ’Grün’. Hiermit lassen sich mehrere 

Zeilen markieren bzw. die Markierung einer Zeile wieder rückgängig machen. 

Mit Funktionstaste ’Gelb’ kann der aktuelle Filter als Bookmark gespeichert werden, 

woraufhin ein Widget zur Festlegung eines Bookmarknamens eingeblendet 

wird. Die Suche wird mit der Funktionstaste ’Blau’ gestartet. Die Datum-Eingabe 

(Anfangs- und Endzeit) erfolgt über den Zahlenblock der Fernbedienung, ebenso 

wie die Text-Eingabe, die später beschrieben wird. 

Auch in der Ergebnisanzeige können mehrere Sendungen mittels des grünen Farbknopfes 

ausgewählt werden. Für diese lässt sich mittels des roten Farbknopfes 

durch Zugriff auf den TVTimer-Zustand, in Abschnitt 5.4.1 beschrieben, eine Aufnahme 

programmieren. Ist nur eine Sendung markiert, kann durch Drücken des 

blauen Knopfes in den LiveTV-Zustand (Abschnitt 5.4.2) gewechselt werden, wobei 

der Kanal der gewählten Sendung eingestellt wird. 

TextInput-Unit 

Zur Eingabe von Text in Multimedia-Box-Zuständen wurde der OSDManager (siehe 

Abschnitt 3.3) um die TextInput-Widgetunit erweitert. Die Eingabe erfolgt 

über den Zahlenblock der Fernbedienung. Dabei wird das gleiche Verfahren angewandt 

wie bei der Eingabe einer SMS auf dem Handy. Den Zahlentasten einer 

Fernbedienung sind mehrere Buchstaben zugeordnet, welche heutzutage meist auf 

den Fernbedienungen aufgedruckt sind. So sind z.B über die Zahlentaste ’2’ die 

Buchstaben ’a’, ’b’ und ’c’ verfügbar. Durch einmaliges Drücken wird der Buchstabe 

’a’ ausgewählt. Zur Auswahl des nächsten Buchstabens muss innerhalb von 

zwei Sekunden die gleiche Taste erneut gedrückt werden. Bezogen auf Taste ’2’ 

wäre dies ’b’. Der nächste Buchstabe des zu schreibenden Wortes kann auf die 

gleiche Weise festgelegt werden. 

93


94 

Um den Namen ’bernd’ zu schreiben wird die Tastenkombination zweimal 2, zweimal 

3, dreimal 7, zweimal 6 und einmal 3 gedrückt. Die Widgetunit bietet nicht 

nur die Möglichkeit die standardmäßige Belegung zu verwenden, sondern auch eine 

eigene festzulegen. Sie besteht aus einem einzigen TextView-Widget und es 

ist lediglich eine Zeile zur Anzeige ansprechbar, weshalb sowohl eine Selektion 

dieser als auch das Navigieren mittels der ’Hoch’- bzw. ’Runter’-Tasten der Fernbedienung 

entfällt. 

Im Folgenden werden ausgewählte Methoden des TextInput-Widgets erklärt. 

Alle Methoden sind aus dem Klassendiagramm in Abbildung 4.38 ersichtlich: 

void addString(string s) Setzt den Inhalts des Widgets. 

void clear() Löscht den Inhalt des Widgets. 

void erase() Löscht das letzte Zeichen des Inhalts. 

void setMode(mode_e m) Setzt den Eingabe-Modus des Widgets. Eingabe-Modi 

sind ALPHA zur Eingabe von Buchstaben und NUMERIC zur Eingabe von 

Zahlen. 

void setLineURL(string s) Setzt die Zeilen-URL. 

string getLineURL() Fragt die Zeilen-URL ab. 

Result keyPressed(int k) Teilt dem Widget mit, dass der k-te Knopf des Zahlenblocks 

gedrückt wurde . 

void setNewKeyCharMapping(vector v) Setzt ein neues Mapping, welchem 

Buchstaben einer Taste zugeordnet sind. Das Mapping besteht aus 

strings, welche die Buchstaben-Belegung einer einzelnen Taste angeben, 

die bei mehrfachem Drücken durchgeschaltet werden. Diese sind in einem 

vector gespeichert, wobei die Position des strings innerhalb des Vektors 

die zu drückende Taste festlegt. 

vector getKeyCharMapping() Liefert das gesetzte Mapping zurück. 


Vor der Suchanfrage an den EPG werden die eingestellten Informationen aus den 

GUI-Elementen ausgelesen und in einem ProgramFiltergespeichert. Anschließend 

wird in den Zustand SearchResult gewechselt, welcher die Suche anstößt, die 

Ergebnisse aufbereitet und anzeigt. Das erstellte Objekt der ProgramFilter- 

Klasse wird dazu an die Methode search(...) des ITVGuide-Interfaces des 

EPG übergeben, wodurch dieser die entsprechenden Daten sucht und an den Search- 

Zustand zurückliefert. 

Zur Unterstützung der Peer-to-Peer-Funktion des EPG implementiert der Search- 

Result-Zustand das ITVGuidePeerObject-Interface, welches ebenfalls bei der


Abbildung 4.39: Der LiveTV-Zustand mit EPG-Informationen. Am unteren Rand 

werden die Startzeiten sowie die Titel der momentan laufenden und nachfolgenden 

Sendung angezeigt, in der linken oberen Ecke Informationen über den Kanal und 

die verwendete TV-Quelle eingeblendet (links). Bei Bedarf können durch Drücken 

des grünen Farbknopfes erweiterte Informationen zur aktuellen Sendung eingeblendet 

werden (rechts). 

Suchanfrage übertragen wird. Dadurch kann er über Resultate der Suche im Netzwerk 

informiert werden und diese Ergebnisse der Anzeige hinzufügen. Auf Knopfdruck 

werden die angezeigten Informationen erneut sortiert. Dadurch wird eine 

automatische Veränderung der GUI verhindert, während der Benutzer die Informationen 

betrachtet. 

4.5.3 EPG-Informationen im LiveTV-Zustand 

Der LiveTV-Zustand der Multimedia-Box wurde erstmals in [BCE + 02] realisiert 

und im Rahmen dieser Arbeit zuerst um die Anzeige von EPG-Informationen erweitert. 

Der Status des Zustandes zu Beginn dieser Arbeit wurde bereits in Kapitel 

3.3 beschrieben. Zusätzliche Erweiterungen dazu werden in Abschnitt 5.4.2 

vorgestellt. 

Benutzeroberfäche 

Für die Anzeige der EPG-Informationen wurde die GUI um ein Fenster erweitert, 

in dem vorhandene Informationen über die gerade laufende und folgende Sendung 

des eingestellten Kanals eingeblendet werden. Zur aktuellen Sendung können 

bei Bedarf erweiterte Informationen angezeigt werden (siehe Abbildung 4.39). 

Zudem wurde der LiveTV-Zustand um die Anzeige der Kanalliste ausgebaut. Sie 

bietet einen Überblick bzgl. der konfigurierten Kanäle, zu denen vorhandene EPG- 

Informationen – je nach Wunsch – für die laufende oder folgende Sendung angezeigt 

werden (siehe Abbildung 4.40). 

Sie teilt sich in zwei Widgets, wobei das obere eine Liste der verfügbaren Kanäle 

anzeigt sowie die Startzeit und den Titel der aktuellen oder folgenden Sendung auf 

95


96 

Abbildung 4.40: Die Kanalliste zeigt zu jedem Sender Informationen der aktuell 

laufenden Sendung an. Sie bietet weiterhin das Einstellen des gewählten Senders 

durch dessen Auswahl und anschließendes Drücken des grünen Farbknopfes. 

dem entsprechenden Kanal. Das untere Widget zeigt zusätzliche Informationen zu 

der gewählten Sendung. 

Bedienung 

Die Beschreibung der Bedienung wird im Folgenden auf das Einblenden von Widgets 

mit EPG-Informationen eingeschränkt. Die Bedienung der TV-Funktionalitäten 

wird in Abschnitt 5.4.2 erklärt. 

Details zur aktuellen Sendung können mit dem grünen Farbknopf ein- bzw. wieder 

ausgeblendet werden. Die Kanalliste mit Informationen zu aktuellen Sendungen 

wird mit dem gelben, Informationen zu folgenden Sendungen mit dem blauen 

Farbknopf eingeblendet. 

Innerhalb der Anzeige der Kanalliste kann mit den Tasten ’Hoch’ und ’Runter’ ein 

Sender ausgewählt und mit Hilfe des blauen Farbknopfes auf diesen gewechselt 

werden. 


Zur Abfrage der Informationen bei dem EPG werden diese durch die Methoden 

getCurrentEventOnChannel(..), für Daten zur aktuellen Sendung bzw. 

getFollowingEventOnChannel(..) für Daten zur folgenden Sendung abgefragt. 

Zur Anzeige wurde die in Abschnitt 4.5.1 entwickelte TableUnit verwendet 

um die Informationen strukturiert anzeigen zu können. Durch das Registrieren 

eines EventListeners beim EPG wird der Zustand über neu eintreffende 

Daten benachrichtigt. Sollten diese Beschreibungen zu laufenden oder folgenden 

Sendungen enthalten, werden sie der Anzeige hinzugefügt. Dies dient der Unterstützung 

der Peer-to-Peer-Funktionalität des EPG.



In diesem Kapitel wurde die Realisierung der elektronischen Programmzeitschrift 

(EPG) für die Multimedia-Box erläutert. Zuerst wurde die verwendete Plugin- 

Struktur erklärt, mit deren Hilfe der EPG Daten von verschiedenen Quellen sammelt. 

Darauf folgte die Beschreibung der realisierten EPG-Plugins, welche die 

EPG-Informationen von externen Quellen beschaffen. Hinzu kam die Betrachtung, 

wie die gesammelten Informationen abgespeichert und abgerufen werden. 

Zu diesem Zweck ist eine Verzeichnis-Struktur erarbeitet worden, in der die Daten, 

nach Kanälen und Tagen sortiert, in XML-Dateien gespeichert werden. Weiterhin 

wurden sowohl Probleme und deren Lösungen aufgezeigt, die beim Einfügen der 

EPG-Daten von unterschiedlichen Quellen auftreten, als auch die verschiedenen 

Abfrage-Möglichkeiten der Daten nach bestimmten Kriterien erklärt. 

Der nächste Abschnitt beschrieb die Peer-to-Peer-Funktionalität des EPG, welche 

es ermöglicht einen verteilten EPG zu realisieren. Dazu werden bei einer Abfrage 

lokale Daten auf Vollständigkeit geprüft und fehlende Informationen von im Netzwerk 

verfügbaren EPGs erfragt um so den eigenen Datenbestand zu ergänzen oder 

zu aktualisieren. 

Den Abschluss des Kapitels bildet die Beschreibung des TVGuide- und des Search- 

Zustandes der Multimedia-Box, die zur Abfrage und Anzeige der Daten entwickelt 

wurden. Im Zuge dessen wurde der OSDManager um zwei Widgets erweitert, eines 

zur strukturierteren Anzeige von Zeilen im TVGuide-Zustand, sowie ein anderes 

zur Eingabe von Text über eine Fernbedienung. Darüberhinaus wurde die Erweiterung 

des LiveTV-Zustandes zur Anzeige von EPG-Informationen erläutert. 

97


98

Kapitel 5 

Realisierung von Szenarien des 

Mehrbenutzer-TV 

Bei der Vorstellung des EPG wurde bereits erwähnt, dass u.a. auch der digitale TV- 

Strom als EPG-Quelle dienen kann. Zu weiteren Anwendungsmöglichkeiten einer 

TV-Karte zählen der Videorekorder zum Aufzeichnen von Fernsehsendungen und 

vor allem Live TV. Zudem existieren in heutigen Haushalten meist mehrere Computer, 

in denen eine Vielzahl an TV-Karten installiert sein können. Da NMM den 

netzwerktransparenten Zugriff auf solche Ressourcen ermöglicht, können diese für 

die verschiedenen TV-Anwendungen genutzt werden. Die Zuteilung der verfügbaren 

TV-Karten soll für die einzelnen Szenarien dynamisch erfolgen, d.h. die Anwendung 

ermittelt selbständig, welche Quelle sie für ihre Zwecke verwenden kann 

oder darf. Solche Anwendungsfälle und die entsprechenden Verfahrensweisen werden 

in diesem Kapitel besprochen. 

In Abschnitt 5.1 wird zuerst der einfache Fall betrachtet, in welchem eine Anwendung 

auf eine TV-Karte zugreift. In Abschnitt 5.2 wird die Erweiterung der Szenarien 

um mehrere TV-Quellen beschrieben. In diesem Zusammenhang wird zusätzlich 

der realisierte Videorekorder im Detail erklärt (Abschnitt 5.2.2). Anschließend 

werden in Abschnitt 5.3 Szenarien beschrieben, in denen die Anwendung für Live 

TV, der Videorekorder sowie der EPG auf eine Vielzahl von TV-Karten zugreifen 

und dabei auftretende Probleme gelöst werden. Nach der Vorstellung der Szenarien 

und den entsprechenden Implementierungen wird in Abschnitt 5.4 deren Integration 

in die Multimedia-Box behandelt. In Abschnitt 5.4.1 wird der TVTimer-Zustand 

vorgestellt, der zur Bedienung des Videorekorders entwickelt wurde. Darauf folgt 

in Abschnitt 5.4.2 die Erläuterung des LiveTV-Zustandes, der das Fernsehen durch 

Zugriff auf mehrere TV-Karten unterstützt. 

Ein mögliches Anwendungsszenario für das Mehrbenutzer-TV wird in Abbildung 

5.1 gezeigt. Hier stehen im Netzwerk unterschiedliche TV-Karten zur Verfügung, 

die von Live TV, dem Videorekorder und vom EPG verwendet werden. Der Begriff 

Mehrbenutzer-TV bezeichnet Anwendungsfälle, in denen Benutzer unter Verwendung 

verschiedener Anwendungen auf TV-Karten zugreifen. Dies erfolgt entweder 

ohne direkte Benutzereinwirkung wie im Falle des EPG und des Videorekorders, 

99

KAPITEL 5. Realisierung von Szenarien des Mehrbenutzer-TV 

100 

analoge 

TV-Karte 

Live TV 

Netzwerk 

Netzwerk 

Live TV 

Videorekorder 

Netzwerk 

EPG 

digitale 

TV-Karte 

Abbildung 5.1: Diese Abbildung zeigt ein Szenario des Mehrbenutzer-TV in dem 

die Anwendungen EPG, Live TV und Videorekorder auf mehrere im Netzwerk 

verteilte TV-Karten zugreifen. 

welche selbständig zu von einem Benutzer vorgegebenen Zeitpunkt Kanäle wechseln, 

oder mit direkter Einwirkung bei einer Live TV-Anwendung, welche erst 

durch Eingaben des Benutzers einen Kanal wechselt. Deshalb wird in diesem Kapitel 

nicht von Benutzern, sondern lediglich von Anwendungen gesprochen. 

Wie schon in Abschnitt 1.1 erwähnt, können die TV-Karten ein unterschiedliches 

Kanalangebot bereitstellen. Dies erfordert die Ermittlung der bereitgestellten 

Kanäle für jede TV-Karte, sodass eine Anwendung weiß, welche ihr überhaupt zur 

Verfügung stehen und von welchen TV-Quellen sie diese empfangen kann. Weiterhin 

wurde angemerkt, dass verschiedene TV-Quellen Audio- und Video-Daten in 

unterschiedlicher Qualität liefern. Um dies zu berücksichtigen muss eine Reihenfolge 

festgelegt werden, in der die TV-Karten angesprochen werden sollen. Zum 

Speichern dieser Informationen wird die globale Kanalliste beschrieben, die Informationen 

über verfügbare Kanäle auf den vorhandenen TV-Karten zusammenfasst 

(siehe Abschnitt 5.2.1). 

Ein weiteres Problem tritt bei einer gemeinsamen Verwendung einer TV-Quelle 

durch mehrere Anwendungen auf. Teilen sich Live TV und der Videorekorder eine 

TV-Karte, stellt sich die Frage, wer zum Wechseln des Kanals berechtigt ist. Eine 

Aufnahme durch den Videorekorder soll nicht unterbrochen werden, was bei einem 

Kanalwechsel durch Live TV geschehen würde. Selbst wenn der Videorekorder 

eine neue verwendbare TV-Quelle finden würde, wäre die Aufnahme kurzzeitig 

unterbrochen, was nicht akzeptabel ist. Aus diesem und weiteren in Abschnitt 5.3 

genannten Gründen muss eine Hierarchie der Anwendungen festgelegt werden, 

auf deren Basis bestimmt wird, welche kontrollierend auf eine TV-Karte zugreifen 

darf um den Kanal zu wechseln. Weiterhin soll die Feststellung ermöglicht werden, 

durch welche Anwendung eine TV-Quelle aktuell genutzt wird. Unter den 

oben genannten Gesichtspunkten ist nicht ausreichend zu erkennen, dass eine TV- 

Quelle verwendet wird, sondern es muss auch bekannt sein, zu welchem Zweck. 

Angenommen, es gälte die Regelung, dass bei einem gemeinsamen Zugriff auf eine 

TV-Karte durch den Videorekorder und Live TV lediglich der Videorekorder 

den Kanal wechseln darf, dann bedeutet das: Wird eine TV-Karte momentan von

5.1. VERWENDUNG EINER QUELLE DURCH EINE ANWENDUNG 

Live TV genutzt, die der Videorekorder aber zeitgleich für eine Aufnahme verwenden 

möchte, so ist dies und zusätzlich das Einstellen des von ihm benötigten 

Fernsehkanals erlaubt. Möchte der Benutzer der Live TV-Anwendung den Kanal 

wechseln, muss die Anwendung wissen, wer die TV-Karte mitverwendet und – in 

Abhängigkeit davon – den Kanalwechsel zulassen oder verweigern. Die Regeln bei 

einem gemeinsamen Zugriff mehrerer Anwendungen auf eine TV-Quelle werden 

in Abschnitt 5.3 vorgestellt. 

In [LRS05] wird ein Algorithmus beschrieben, der in einem Mehrbenutzer-Szenario 

verwendbare TV-Quellen bestimmt. Er dient als Vorlage der in diesem Kapitel beschriebenen 

Konzepte und Implementierungen. 

5.1 Verwendung einer Quelle durch eine Anwendung 

Im einfachsten Fall, der bei einem Zugriff auf TV-Ressourcen eintreten kann, wird 

eine TV-Karte von einer einzigen Anwendung entweder zum Sammeln von EPG- 

Informationen, zum Aufnehmen einer Sendung oder für LiveTV verwendet. 

Diese Funktionaliät wird von NMM sowohl für lokale als auch im Netzwerk verteilte 

TV-Karten bereitgestellt. Die Analyse der Wechselwirkungen der einzelnen 

Anwendungsfälle ist nicht relevant, da nur einer von ihnen eintritt. 

5.2 Zugriff einer Anwendung auf mehrere Quellen 

Im zweiten Szenario stehen einer Anwendung mehrere TV-Karten zur Verfügung, 

auf die zugegriffen werden kann, unter der Prämisse, dass die entsprechenden TV- 

Karten für nur einen Anwendungsfall verwendet werden. 

Dies erfordert die Kenntnis darüber, welche Kanäle die einzelnen TV-Quellen bereitstellen. 

Wenn angenommen wird, dass die Live TV-Anwendung aktuell eine 

TV-Karte verwendet und nun den Kanal wechseln möchte, muss festgestellt werden, 

ob dieser von der momentan genutzten Karte zur Verfügung gestellt wird. 

Andernfalls ist der Anwendung eine TV-Quelle zuzuweisen, die den gewünschten 

Kanal anbietet. Das Vorgehen ist in Abbildung 5.2 graphisch dargestellt. 

Wird ein Kanal von mehreren TV-Quellen bereitgestellt, muss für den Zugriff eine 

Ordnung der TV-Karten festgelegt werden. Dadurch ist es möglich die in Abschnitt 

1.1 angesprochenen Unterschiede der Übertragungstechniken zu berücksichtigen. 

Da in dem betrachteten Fall lediglich eine Anwendung auf TV-Karten 

zugreift, wird dieser immer die erste TV-Karte aus der Liste zugeordnet. Wechselwirkungen 

mit anderen Anwendungen treten nicht auf. Dennoch ist das Feststellen 

verfügbarer Kanäle sowie das Speichern der zugehörigen TV-Quellen erforderlich. 

101


102 

TV-Karte aus Liste erhalten 

Setze Kanal A 

Kanal A gesetzt 

Kanal A soll 

gesetzt werden 

Erfrage TV-Karten von 

globaler Kanalliste 

Liste mit TV-Karten erhalten, 

die Kanal A bereitstellen 

Nimm TV-Karte aus Liste 

XOR 

Keine TV-Karte in Liste 

vorhanden 

Fehlerbehandlung: 

Kanal A kann nicht 

eingestellt werden 

Abbildung 5.2: Vorgehensweise bei einem Zugriff einer Anwendung auf mehrere 

TV-Karten. 

5.2.1 Die globale Kanalliste 

Die globale Kanalliste enthält Informationen darüber, von welchen TV-Quellen 

ein entsprechender Kanal empfangen werden kann. Zu diesem Zweck speichert sie 

den Sendernamen, die Kanalnummer auf der entspechenden TV-Karte sowie deren 

Beschreibung als GraphURL. Die Kanalnummer bezeichnet eine vom Anwender 

festgelegte Zuteilung einer Nummer zu einem Kanal. Eine Kanalnummer ist dabei 

genau einem Kanal zugeordnet, während ein solcher durch mehrere Kanalnummern 

angesprochen werden kann. Die GraphURL [RL04] gibt die Art der Quelle 

an, sodass beim Erstellen eines NMM-Graphen der entsprechende Quellknoten 

verwendet wird. Weiterhin enthält sie bei Bedarf quellenspezifische Parameter sowie 

den Rechnernamen, wenn auf die TV-Karte über das Netzwerk zugegriffen 

werden soll . Die allgemeine Form einer solchen URL lautet wie folgt: 

://?=&... 

In dieser Diplomarbeit wurden als TV-Quellen die in Abschnitt 3.1 vorgestellten 

Knoten DVBReadNode und IVTVReadNode verwendet. Die entsprechenden 

GraphURLs haben die folgende Form: 

dvbtv:///?=&... 

ivtv:///?=&... 

Die globale Kanalliste speichert zu jedem Kanal eine Liste von GraphURLs, da ein 

Sender von mehreren TV-Karten empfangen werden kann. Diese Liste repäsentiert

5.2. ZUGRIFF EINER ANWENDUNG AUF MEHRERE QUELLEN 

Abbildung 5.3: Die Klasse TVChannel speichert Informationen zu Kanälen. Diese 

werden in der Klasse TVChannelList verwaltet. 

die Hierarchie der Karten und ist absteigend nach deren Präferenz geordnet. Die 

Quelle mit der höchsten Präferenz legt den Kanalnamen fest, der zu dem Sender 

gespeichert wird. Ebenso sind die Kanal-Informationen selbst in einer Liste verwaltet. 

Die Position der Kanäle innerhalb dieser Liste gibt zugleich die Kanalnummer 

des Senders innerhalb der globalen Kanalliste an. Die initiale Ordnung der 

Kanäle wird von der Reihenfolge bestimmt, mit der die TV-Quellen nach verfügbaren 

Kanälen befragt werden. Zu jeder neuen Kanal-Information wird geprüft, ob 

der Sender in der globalen Kanalliste schon enthalten ist und diesem lediglich die 

GraphURL der Quelle hinzugefügt. Bisher unbekannte Sender werden der globalen 

Kanalliste angehängt. 

5.2.1.1 Datenstruktur der globalen Kanalliste 

Die Kanaldaten der TV-Quellen für die globale Kanalliste sind in der serialisierbaren 

Datenstruktur TVChannelList gespeichert. Dies ist notwendig, da sie auch 

bei der Erstellung der globalen Kanalliste verwendet wird um Informationen über 

verfügbare Kanäle von entfernten TV-Karten zu erhalten (siehe Abschnitt 5.2.1.2). 

Sie verwaltet intern die Kanal-Informationen in einer Liste von Objekten der TV- 

Channel-Klasse. Die Klassendiagramme sind in Abbildung 5.3 zu sehen. Diese 

Klassen enthalten als Informationen über einen einzelnen Kanal sowohl den Na- 

103


104 

men des Senders als auch eine Liste von TV-Karten, repräsentiert durch eine GraphURL, 

über die der Sender empfangen werden kann. Zu den einzelnen TV-Karten 

wird zum schnellen Zugriff auf den Kanal die Nummer des Senders in der Kanalliste 

der entsprechenden TV-Karte abgelegt. Weiterhin können Aliase zu dem 

Kanalnamen angegeben werden, da, wie schon in Abschnitt 4.2 beschrieben, unterschiedliche 

Namen für Sender existieren können. 

Die gespeicherten Daten der TVChannelList-Klasse können in eine XML-Datei 

geschrieben bzw. von dort gelesen werden. Die Kanal-Informationen aus der XML- 

Datei sind Bestandteile der tvchannel-Elemente, welche als Attribut name den 

Kanalnamen enthalten. Dieser wird von der TV-Quelle festgelegt, welche die höchste 

Benutzerpräferenz besitzt. Als Kinder enthalten die tvchannel-Elemente die 

dem in name angegebenen Kanal zugeordneten Informationen. Diese sind zum 

einen in card-Elementen abgelegt, die Daten zu jeweils einer TV-Karte enthalten, 

über die der Sender empfangen werden kann. Als Attribut number ist die Kanalnummer 

des entsprechenden Kanals auf der genannten TV-Karte angegeben und 

als Daten die GraphURL der TV-Quelle. Zum anderen können die tvchannel- 

Elemente alias-Elemente enthalten, die alternative Schreibweisen für Sender 

aufweisen. Eine entfernte TV-Quelle kann in ihrer channelAlias.xml Aliase 

definieren, welche in der lokalen fehlen. Da die Datei channelAliases.xml 

bei einer Installation von NMM schreibgeschützt sein kann, werden diese Aliase 

in der XML-Datei der globalen Kanalliste abgelegt. Zudem werden die lokalen 

Aliase beim Hinfzufügen eines neuen Kanals zwecks eines schnellen Zugriffs ermittelt 

und ebenfalls in der globalen Kanalliste gespeichert. So muss die Datei 

channelAliases.xml nicht bei jeder Abfrage nach einem Kanalnamen geöffnet 

und durchsucht werden, was sich bei der Implementierung als nicht performant 

erwiesen hat. 

Der folgende Auszug aus der XML-Datei der globalen Kanaliste zeigt die gespeicherten 

Informationen der Sender ARD, ZDF und RTL. ARD und ZDF werden 

sowohl von der lokal vorhandenen DVB-Karte als auch von der entfernten analogen 

TV-Quelle in Rechner ’host’ zur Verfügung gestellt. RTL ist ausschließlich 

über die lokale DVB-Karte zu empfangen. Um nun z.B. ARD zu empfangen, muss 

entweder auf der lokalen DVB-Karte Kanal 1 oder auf der analogen Karte Kanal 

0 eingestellt werden, was durch die number-Attribute der card-Elemente angezeigt 

wird. Weiterhin ist für den Sender ARD ein Alias festgelegt, da dieser auch 

als ’Das Erste’ bezeichnet werden kann. 

 

 

 

dvbtv://localhost 

ivtv://host?freqtable=pal-europe 

Das Erste 

 

 


ivtv://host?freqtable=pal-europe 

 

 

dvbtv://localhost

... 

 


Zum Zugriff auf die TVChannel-Objekte stellt die Klasse TVChannelList die 

folgenden Methoden bereit: 

getChannelByNumber(unsigned int number) dient der Abfrage des 

Kanals über dessen Kanalnummer in der globalen Kanalliste. Die TVChannel-Objekte 

sind in einer Liste gespeichert, sodass die Kanalnummer die 

Position des Kanals in dieser Liste angibt. 

getChannelByName(string name) dient der Abfrage eines Kanals unter 

Verwendung eines Sendernamens. Hierbei werden der gespeicherte Name eines 

Senders sowie dazu bekannte Aliase mit dem Parameter verglichen und 

bei Übereinstimmung das entsprechende Objekt der TVChannel-Klasse 

zurückgeliefert. 

5.2.1.2 Auslesen der Kanäle einer TV-Quelle 

Zum Erstellen der globalen Kanalliste muss zuerst festgelegt werden, welche TV- 

Quellen zur Verfügung stehen. Dies geschieht durch entsprechende Einträge in der 

Konfigurations-Datei der Multimedia-Box (siehe Anhang A), wodurch Art und Ort 

der TV-Quelle durch Angabe der entsprechenden GraphURL spezifiziert werden. 

Wie bereits erwähnt, ist die Qualiät der Übertragung unterschiedlich. Es ist jedoch 

nicht möglich dynamisch festzustellen, welche Bild- und Ton-Qualität die entsprechende 

Quelle bereitstellt. Aus diesem Grund wird die Reihenfolge bei der Angabe 

der TV-Quellen beachtet, die vom Benutzer mit absteigender Präferenz anzugeben 

sind. Ein möglicher Konfigurationseintrag für die Multimedia-Box zur Verwendung 

einer digitalen und analogen TV-Karte könnte wie folgt aussehen, unter der 

Voraussetzung, dass der DVB-Karte gegenüber der analogen eine höhere Präferenz 

zukommt: 

# Angabe der i n s g e s a m t v e r w e n d e t e n TV−Karten 

tvhosts_number=2 

## DVB−Karte i n dem l o k a l e n Rechner 

tvhost_0=dvbtv://localhost 

## IVTV−Karte i n dem e n t f e r n t e n Rechner ’ host ’ 

tvhost_1=ivtv://host?freqtable=pal-europe 

Anschließend ist die Ermittlung der empfangbaren Kanäle der angegebenen TV- 

Karten notwendig. Diese Informationen werden bei den verwendeten TV-Quellen 

erfragt, wozu die entsprechenden NMM-Knoten um die Implementierung des IChannelInfo-Interfaces 

(siehe Abbildung 5.4) erweitert wurden. Bei einer Abfrage 

ermittelt der Knoten die Kanäle, die er bereiststellen kann. Dazu wertet er seine 

105


106 

Abbildung 5.4: Die in dieser Arbeit verwendeten TV-Quellknoten wurden zum Erfragen 

von verfügbaren Kanälen um die Implementierung des IChannelInfo- 

Interfaces erweitert. 

eigene Konfigurations-Datei aus, in der angegeben ist, welche Kanäle von der TV- 

Quelle empfangen werden können und analysiert zusätzliche Informationen über 

technische Parameter. Diese sind jedoch ausschließlich für das exakte Einstellen 

der TV-Karte zum Empfang des entsprechenden Kanals relevant und spielen somit 

in der globalen Kanalliste keine Rolle. Für diese ist lediglich die Bezeichnung des 

Kanals sowie dessen Nummer in der Kanalliste der TV-Karte wichtig. Diese Informationen 

werden schließlich mittels der Klasse TVChannelList übertragen. 

Eine Beschreibung der Konfiguration der verwendeten TV-Karten kann in [Wel05] 

nachgelesen werden. 

Zum Auslesen der Daten und Erstellen der globalen Kanalliste wurde das Kommandozeilen-Programm 

channelReader implementiert. Dieses wertet die Angaben 

über TV-Karten in der Konfigurations-Datei der Multimedia-Box aus und 

erfragt reihum die Kanallisten der TV-Quellen. Die erhaltenen Listen fasst er in 

einem Objekt der TVChannelList zusammen, wobei er erkennt, ob ein Kanal 

von einer vorher befragten TV-Quelle schon zur Verfügung gestellt wird. In 

diesem Fall fügt er dem entsprechenden TVChannel-Eintrag die GraphURL der 

TV-Karte hinzu. Zum Abschluss schreibt der channelReader die gesammelten 

Informationen in die XML-Datei der globalen Kanalliste. Diese wird standardmäßig 

in dem $HOME-Verzeichnis des jeweiligen Benutzers im Unterverzeichnis 

.nmm unter dem Namen tv_channels.xml abgelegt. Sie kann anschließend 

vom Benutzer bei Bedarf bearbeitet werden um u.a. die Kanalreihenfolge festzulegen. 

5.2.2 Ein Videorekorder auf Basis von NMM 

Ein Anwendungsfall für den Zugriff auf TV-Karten stellt die Aufnahme von Sendungen 

des Fernsehprogramms dar. Um möglichst viele Sendungen aufzeichnen zu 

können, sind die einprogrammierten Aufnahmen auf verfügbare TV-Karten aufzuteilen. 

Dazu wurde der Videorekorder entwickelt, der überlappende Aufnahmen 

erkennen und auf verfügbare TV-Quellen verteilen kann und schließlich die gewünschte 

Sendung aufzeichnet. Darüberhinaus wird der Videorekorder an einen


Netzwerk 

Videorekorder 

mit lokaler 

TV-Karte 

Netzwerk Netzwerk 

Zugriff auf Dienst 

Zugriff auf TV-Karte 

TV-Karte TV-Karte 

Abbildung 5.5: Der Videorekorder steht im Netzwerk als zentraler Server zur Verfügung, 

zu dem sich Anwendungen bei Bedarf verbinden. Er selbst hat wiederum 

Zugriff auf eine lokale und zwei im Netzwerk verteilte TV-Karten. 

EPG angebunden, sodass Informationen zu einzelnen Aufnahmen abgefragt und 

auf Grund dieser Daten automatische Wiederholungen programmiert werden können. 

Vor der Realisierung stellte sich die Frage, inwieweit eine Verteilung des Videorekorders 

im Netzwerk vorgenommen werden soll. Eine Variante bestand darin 

den Videorekorder als zentralen Server zu installieren und lediglich von entfernten 

Rechnern Knoten zur Aufnahme von Sendungen anzufordern oder mehrere Videorekorder 

im Netzwerk verfügbar zu machen. Eine weitere, mögliche Realisierung 

wird in [Har02] vorgeschlagen, wo mehrere im Netzwerk verteilte Videorekorder 

ansprechbar sind. Die Quelle beinhaltet lediglich eine Projektbeschreibung, was bis 

zum Zeitpunkt dieser Arbeit noch nicht realisiert wurde. Dort ist auf jedem Rechner, 

der eine TV-Karte zur Verfügung stellt, ein Videorekorder aktiv, der selbst 

jedoch nur auf die lokale TV-Karte zugreifen kann. Zum Einprogrammieren einer 

Aufnahme werden die verfügbaren Videorekorder reihum gefragt, ob dies möglich 

ist. Dies erfordert eine Kommunikation der Videorekorder untereinander, wenn eine 

automatische Wiederholung auf Grund von Konflikten in einer Instanz nicht 

vorgenommen werden kann. Zur Lösung dieses Problems und zur einfachen Verwaltung 

der Aufnahmen wurde der Videorekorder schließlich als zentraler Server 

realisiert, mit dem sich die Anwendung eines Benutzers zur Programmierung von 

Aufnahmen verbinden muss. Der Zugriff auf im Netzwerk verteilte TV-Karten wird 

durch NMM realisiert. Abbildung 5.5 zeigt ein mögliches Szenario. Mehrere Anwendungen 

verbinden sich mit dem zentralen Videorekorder, der eine lokale und 

zwei im Netzwerk verteilte TV-Karten verwendet. 

107


108 

Abbildung 5.6: Dieses Diagramm zeigt die Klassen des Videorekorders. 

5.2.2.1 Realisierung des Videorekorders 

Der Videorekorder wurde zur Realisierung in verschiedene Klassen aufgeteilt (siehe 

Abbildung 5.6), welche die einzelnen Funktionalitäten implementieren. Die 

Klasse TVTimerControl erstellt die Objekte dieser Klassen und gibt die zu 

programmierenden Aufnahmen zur Bearbeitung an sie weiter. Für den Zugriff von 

Anwendungen auf den Videorekorder implementiert diese Klasse das ITVTimer- 

Interface (siehe Abbildung 5.7). Um Anwendungen über Statusänderungen von 

Aufnahmen zu informieren, implementiert die TVTimerControl-Klasse zusätzlich 

das ITVTimerEvents-Interface. Für seine Methoden kann eine Anwendung 

einen EventListener (siehe Abschnitt 3.1) registrieren und so über Statusänderungen 

benachrichtigt werden. 

Der TVTimerScheduler sorgt für die Zuordnung einer geeigneten freien TV- 

Karte zu einer Aufnahme. Dazu verwendet er die Klasse TVTimerConflict- 

Checker, welche Überlappungen einer neuen Aufzeichnung mit schon einprogrammierten 

erkennt. Die Klasse TVRecorderManager übernimmt deren Starten 

und Beenden und erstellt zur Aufnahme einer Sendung zum entsprechenden 

Zeitpunkt lokal einen TVRecorder. Dieser wiederum baut, je nach verwendeter 

Quelle, den lokalen oder verteilten Flussgraphen zur Aufzeichnung auf. 

Alle Informationen bzgl. einer Aufnahme werden in der Klasse TVTimerEntry 

(siehe Abbildung 5.8) gespeichert, wozu vor allem die Start- und Stopp-Zeit sowie 

der entsprechende Kanal zählen. Weiterhin werden sowohl die GraphURL der 

TV-Karte, die von der Aufzeichnung als Quelle verwendet werden soll, als auch 

die Nummer des einzustellenden Kanals auf dieser TV-Karte gespeichert, die in 

der globalen Kanalliste zu der GraphURL abgelegt ist. Der Zugriff auf den EPG 

ermöglicht die Abfrage einer Programmbeschreibung der Aufnahme, welche ebenfalls 

der TVTimerEntry-Klasse hinzugefügt werden kann. Zusätzlich erhält jeder 

TVTimerEntry eine ID um z.B. im Konfliktfall eine Aufnahme eindeutig 

zu identifizieren, was in Abschnitt 5.2.2.3 erklärt wird. Zur Festlegung des Status 

einer Aufzeichnung wurde ein Zustandsmodell entwickelt. Abbildung 5.9 zeigt 

die Zustände sowie die Zustandsübergänge. Der Status einer Aufnahme in einem


Abbildung 5.7: Dieses Diagramm zeigt die Klasse TVTimerControl und das 

Interface ITVTimer, über das Anwendungen mit dem Videorekorder kommunizieren. 

bestimmten Zustand wird im Folgenden beschrieben: 

SLEEPING Die Aufnahme wurde erfolgreich programmiert und wird zu dem 

angegeben Zeitpunkt gestartet. Solche, die automatisch wiederholt werden 

sollen, haben auch den Status SLEEPING, da sie noch zur Aufzeichnung 

ausstehen. Derartige Aufnahmen werden durch den entsprechend gesetzten 

Modus identifiziert, was in diesem Abschnitt noch beschrieben wird. 

CONFLICT Die Aufnahme konnte nicht programmiert werden, weil zum angegebenen 

Zeitpunkt alle TV-Karten, die den entsprechenden Kanal anbieten, 

schon programmierte Aufzeichnungen zugeteilt sind. 

RECORDING Zeigt eine momentan laufende Aufnahme an. 

RECORDED Die Aufnahme wurde erfolgreich ausgeführt. 

RECORDED_WITH_ERROR Während der Aufnahme ist ein Fehler aufgetreten, 

weshalb sie nicht ordnungsgemäß beendet werden konnte. Eine weitere 

Ursache für diesen Zustand liegt darin, dass zum Start-Zeitpunkt die vorher 

festgelegte TV-Karte nicht mehr verfügbar ist und alle weiteren Quellen mit 

Aufnahmen belegt sind. 

109


110 

Abbildung 5.8: Die Klasse TVTimerEntry dient der Speicherung der Informationen 

zu einer Aufnahme.


Abbildung 5.9: Zustände und Zustandsübergänge einer Aufnahme. 

Eine weitere zu einer Aufnahme gespeicherte Information ist der Benutzername 

des Anwenders, der sie programmiert hat. Durch die Abfrage dieses Namens wird 

geprüft, ob der Anwender zum Bearbeiten oder Löschen einer Aufzeichnung berechtigt 

ist. Dazu muss der Methode zum Löschen bzw. Ändern einer Aufnahme 

der Benutzername mit angegeben werden um die Berechtigungsprüfung vornehmen 

zu können. 

Tritt während der Programmierung von Aufnahmen ein Konflikt auf, werden zusätzliche 

Informationen in dem TVTimerEntry abgelegt. Zum Setzen des entsprechenden 

Status werden zusätzlich die IDs der in Konflikt stehenden Aufzeichnungen 

gespeichert. Dadurch lassen sie sich leicht ermitteln und können in einer 

Anwendung angezeigt werden. Der Grund, warum IDs und keine Referenzen 

oder Zeiger [Str98] auf Objekte der TVTimerEntry-Klasse von in Konflikt stehenden 

Aufnahmen gespeichert werden, besteht darin, dass die Referenzen auf 

lokale Speicheradressen zeigen und diese Adressen bei einer Anforderung eines 

TVTimerEntrys von einem im Netzwerk verfügbaren Videorekorder in der lokalen 

Anwendung nicht gültig sind. Dadurch kann nicht mehr festgestellt werden, 

welche Aufzeichnungen zu der angefragten in Konflikt stehen. 

Der Videorekorder bietet die Möglichkeit Aufnahmen in einem bestimmten Zeitrhythmus 

zu wiederholen. Informationen über die entsprechende Periode werden 

ebenfalls in dem TVTimerEntry gespeichert. Der Videorekorder unterstützt dabei 

folgende Modi zur zeitlichen Wiederholung von Aufnahmen: 

ONCE Die Aufnahme wird einmalig aufgezeichnet. Es findet keine automatische 

Wiederholung statt. 

DAILY Die Aufnahme wird täglich zu der angegebenen Zeit auf dem entsprechenden 

Kanal gestartet. 

WEEKLY Die Aufnahme wird wöchentlich zu der angegebenen Zeit auf dem 

entsprechenden Kanal gestartet. 

111


112 

MONTHLY Die Aufnahme wird monatlich zu der angegebenen Zeit auf dem entsprechenden 

Kanal gestartet, d.h immer am gleichen Tag im Monat (z.B. 

immer am 12. eines Monats). 

WEEKDAYS Die Aufnahme wird immer montags bis freitags zu der angegebenen 

Zeit auf dem entsprechenden Kanal gestartet. 

WEEKENDS Die Aufnahme wird immer samstags und sonntags zu der angegebenen 

Zeit auf dem entsprechenden Kanal gestartet. 

Bei Anbindung an einen EPG werden weitere Perioden unterstützt. Als Grundlage 

dienen vorhandene EPG-Informationen zu einer Aufnahme. Für die Suche 

entsprechender Informationen wird als Schlagwort der Titel der dazu gespeicherten 

EPG-Daten verwendet, wobei je nach gewünschter Periode die Ergebnisse zusätzlich 

nach Kanal oder Uhrzeit gefiltert sind. Die Perioden, basierend auf EPG- 

Informationen, sind im Einzelnen: 

RANDOM Die EPG-Daten werden nach dem vorhandenen Titel der Aufnahme- 

Informationen durchsucht. Alle Resultate dienen als Grundlage zur automatischen 

Reprogrammierung. 

RANDOM_ONLY_CHANNEL Beim Durchsuchen der EPG-Daten wird neben 

dem Titel auch der Kanal berücksichtigt, für den die Aufnahme erstellt wurde. 

RANDOM_ONLY_CHANNEL_AND_TIME Zusätzlich zum vorhandenen Titel 

und dem angegeben Kanal werden die Daten nach der Uhrzeit der programmierten 

Aufnahme gefiltert. Nur Ergebnisse, die in diesen Zeitraum fallen, 

dienen als Grundlage zur automatischen Wiederholung. 

Alle verwendbaren Ergebnisse der EPG-Suche werden in dem TVTimerEntry 

gespeichert um Anfragen an den EPG zu minimieren. 

Die Objekte der TVTimerEntry-Klasse werden zur Verwaltung in der TVTimer- 

List abgelegt (siehe Abbildung 5.10). Diese Klasse wurde als Singleton [GHJV95] 

realisiert, sodass innerhalb des Videorekorders jederzeit darauf zugegriffen werden 

kann und auch sichergestellt ist, dass immer die gleiche Instanz der TVTimer- 

List angesprochen wird. Von dieser Klasse können bei Bedarf entsprechende 

TVTimerEntrys angefordert werden, wobei folgende Abfragen möglich sind: 

getTimer(unsigned int id) Abfrage einer einzelnen Aufnahme mit der 

angegebenen ID. Wurde keine Aufnahme mit der entsprechenden ID gefunden, 

wird eine NoTimerFoundException geworfen. 

getTimers() Liefert eine Liste mit allen vorhandenen Aufnahmen. 

getTimers(string day, string channel) Liefert eine Liste von Aufnahmen, 

die für den angegebenen Tag und Kanal verfügbar sind.


Abbildung 5.10: In der Klasse TVTimerList werden die TVTimerEntry- 

Objekte verwaltet. 

getTimers(string tvcardUrl) Liefert eine Liste von Aufnahmen, denen 

die angegebene TV-Karte zugeordnet ist. 

getSleepingTimers() Liefert alle erfolgreich programmierten Aufnahmen, 

deren Aufzeichnung noch aussteht. 

getRecordingTimers() Liefert eine Liste aller gegenwärtig laufenden Aufnahmen. 

getRecordedTimers() Liefert eine Liste aller Aufnahmen, die erfolgreich 

oder mit Fehlern aufgezeichnet worden sind. Periodische Aufnahmen sind 

davon ausgeschlossen. Diese können über die Methode getSleeping- 

Timers() ermittelt werden. 

getConflictTimers() Liefert eine Liste aller Aufnahmen, deren Programmierung 

auf Grund von Konflikten fehlgeschlagen ist. 

getConflictsWithTimer(const TVTimerEntry &entry) Liefert eine 

Liste aller Aufzeichnungen, die mit der angegebenen Aufnahme in Konflikt 

stehen. 

5.2.2.2 Einprogrammieren von Aufnahmen 

Zum Programmieren einer Aufnahme muss zunächst ein Objekt der TVTimer- 

Entry-Klasse kreiert werden, wobei die wichtigsten Informationen zu deren Spezifizierung 

wie folgt anzugeben sind: 

die Start-Zeit Wann soll die Aufnahme starten? 

113


114 

Abbildung 5.11: Zum Programmieren wird eine Aufnahme von verschiedenen 

Klassen geprüft. 

Abbildung 5.12: Die Klasse TVTimerScheduler teilt Aufnahmen eine zu verwendende 

TV-Karte zu. 

die Stopp-Zeit Wann endet die Aufnahme? 

der Kanalname Von welchem Kanal soll aufgezeichnet werden? 

Alle weiteren Informationen, wie z.B. die verwendete TV-Quelle, werden von dem 

Videorekorder automatisch ermittelt und hinzugefügt. 

Die Programmierung erfolgt durch Aufrufen der Methode programTimer(const 

TVTimerEntry &entry) des ITVTimer-Interfaces. Das Sequenzdiagramm 

des Programmierens im Videorekorder ist in Abbildung 5.11 dargestellt. 

Der Videorekorder stellt zuerst fest, ob die Zeiten korrekt angegeben sind. Ist die 

Stopp-Zeit kleiner als die Start-Zeit, d.h. die Aufnahme endet, bevor sie begonnen 

hat, wird das Datum der Stopp-Zeit um einen Tag erhöht, sodass die Aufnahme erst 

am nächsten Tag endet. Dies geschieht durch Aufrufen der Methode verify() 

der TVTimerEntry-Klasse. 

Anschließend wird nach EPG-Informationen bzgl. der angegebenen Zeit und nach 

zukünftigen Sendungen bei entsprechend eingestellter Periode gesucht. Unabhängig 

vom Ergebnis der EPG-Suche wird das Objekt dem TVTimerScheduler 

übergeben (siehe Abbildung 5.12). Dieser ermittelt durch Abfrage der globalen 

Kanalliste alle bekannten TV-Karten für den angegebenen Kanal und stellt für jede


Abbildung 5.13: Dieses Diagramm zeigt die Klasse TVTimerConflict- 

Checker, welche eine neue Aufnahme mit einprogrammierte Aufnahmen auf 

konflikte vergleicht. 

erhaltene Karte fest, ob die neue Aufnahme mit schon programmierten in Konflikt 

steht. Dazu wird bei der TVTimerList eine Anfrage nach allen einprogrammierten 

Aufzeichnungen gestellt, denen die gerade betrachtete TV-Karte zugeordnet ist. 

Da die TV-Karten in der globalen Kanalliste nach Benutzerpräferenz geordnet sind, 

wird bei der Zuteilung einer TV-Karte zu einer Aufnahme die Reihenfolge durch 

das sequentielle Abarbeiten der erfragten Kanalliste berücksichtigt. Die erhaltene 

Liste und die neue Aufzeichnung werden dem TVTimerConflictChecker 

zur Prüfung übergeben. Bei einem negativen d.h. konfliktfreien Ergebnis, wird 

die in der globalen Kanalliste angegebene GraphURL der TV-Karte in dem TV- 

TimerEntry gespeichert, bei einem positiven mit der nächsten TV-Karte auf die 

gleiche Weise verfahren. 

5.2.2.3 Erkennen und Auflösen von Konflikten 

Ein Konflikt entsteht dadurch, dass sich zwei Aufnahmen auf der gleichen TV- 

Karte zeitlich überschneiden und von unterschiedlichen Kanälen aufgezeichnet 

werden sollen. Der TVTimerConflictChecker (siehe Abbildung 5.13) vergleicht 

in einem Testverfahren alle in einer Liste enthaltenen Aufzeichnungen, die 

schon für eine bestimmte TV-Karte vorgesehen sind, mit der zu programmierenden. 

Hierbei sind auch die Perioden der bereits programmierten Aufnahmen zu 

berücksichtigen. Abbildung 5.14 zeigt sich überschneidende und deren Verteilung 

auf TV-Karten, welche beide Kanal A und B bereitstellen. Aufnahme 1 wurde zuerst 

programmiert, weshalb ihr TV-Karte1 zugeteilt wurde. Die Programmierung 

von Nummer 2 bis 5 erfolgte in zeitlichem Abstand. Weil alle Aufzeichnungen 

mit Aufnahme 1 in Konflikt stehen, wurde ihnen TV-Karte2 zugewiesen. Sie überschneiden 

sich zwar auch untereinander, da sie aber für den gleichen Kanal erstellt 

wurden, können sie eine gemeinsame TV-Karte verwenden. 

Um nun einen Konflikt zwischen zwei Aufnahmen festzustellen, werden deren 

Start- und End-Zeiten verglichen. Überschneiden sich diese, wird überprüft, ob sie 

auf dem gleichen Kanal vorgenommen werden sollen. Ist dies der Fall, liegt kein 

Konflikt vor, da durch das Session-Sharing in NMM die gleiche TV-Karte verwendet 

werden kann. Dadurch ist es möglich, viele Aufzeichnungen einer TV-Karte zuzuordnen, 

sodass die restlichen für andere frei bleiben können. Bei Überdeckung 

der neuen Aufnahme durch eine programmierte wird angezeigt, dass für diesen 

Zeitraum schon eine solche vorgesehen ist. Um Speicherplatz zu sparen wird die 

neue Aufnahme verworfen, was der Anwendung durch eine TimerAlready- 

ProgramedException angezeigt wird. In Abbildung 5.14 wird Aufnahme 3 

115


116 

5 

4 

3 

2 

1 

Aufnahme Nr. 

Kanal B 

Kanal B 

Kanal B 

Kanal A 

Kanal B 

Zeit 

TV-Karte2 

TV-Karte1 

Abbildung 5.14: Beide TV-Karten stellen sowohl Kanal A als auch Kanal B zur 

Verfügung. Aufnahme 1 wurde zuerst erstellt, weshalb ihr TV-Karte1 zugewiesen 

wurde. Die Programmierung der Aufnahmen 2 bis 5 erfolgte zu einem späteren 

Zeitpunkt. Da sie von dem gleichen Kanal aufnehmen sollen, wurde allen TV- 

Karte2 zugewiesen. 

von Nummer 5 überdeckt. Würde diese vor Aufzeichnung 3 programmiert werden, 

würde sie abgelehnt werden. 

Ist dieser Test erfolgreich absolviert, wird die Periode der einprogrammierten Aufnahme 

überprüft. Soll diese täglich gestartet werden, kontrolliert die Methode die 

Uhrzeiten der beiden Aufzeichnungen auf Überschneidung. Bei einer wöchentlichen 

Aufnahme wird zusätzlich getestet, ob die neue für den gleichen Wochentag 

programmiert wurde. Liegt eine monatliche vor, werden die Uhrzeiten und 

die Monatstage verglichen. Analog dazu laufen die Tests für eine Werktag- bzw 

Wochenend-Periode ab. Zur Erkennung eines Konflikts mit einer auf EPG-Informationen 

basierenden Periode werden die in dem TVTimerEntry gespeicherten 

EPG-Daten zukünftiger Sendungen abgefragt und auf Überschneidung getestet, 

weil sie zukünftige Aufnahmen repäsentieren. In allen Fällen werden bei festgestellter 

Überschneidung immer die angegebenen Kanäle ermittelt sowie bei Überdeckung 

die neue Aufzeichnung verworfen. Sind diese verschieden, liegt ein Konflikt 

vor. 

Bei Erkennung eines Konflikts bzgl. einer TV-Karte werden entsprechende Informationen 

in den TVTimerEntry-Objekten gespeichert. Zu der einprogrammierten 

Aufnahme wird die ID der neuen hinzugefügt und die ID der einprogrammierten 

in der neuen gespeichert. Somit kann schnell festgestellt werden, welche Aufzeichnungen 

miteinander in Konflikt stehen. 

Einen Sonderfall stellen Aufnahmen dar, deren Stopp-Zeit null ist. Dies kennzeichnet 

endlose Aufnahmen, die zwar von dem Videorekorder gestartet jedoch nicht zu 

einem vorgegebenen Zeitpunkt beendet werden. Dies erfordert ihre Berücksichtigung 

bei der Konflikterkennung und dem Starten von Aufzeichnungen. Es wurde 

die Konvention getroffen, dass endlose Aufnahmen bei der Prüfung auf Konflikte


Abbildung 5.15: Die Klasse TVRecorderManager, startet zu einem festgelegten 

Zeitpunkt eine Aufnahme und beendet sie wieder. 

unberüchsichtigt bleiben. Sollte einer solchen mit Start- und Stopp-Zeit die TV- 

Karte zugeteilt worden sein, welche die endlose Aufnahme verwendet, führt dies 

zur Beendigung dieser durch den Videorekorder. Endlose Aufzeichnungen können 

in dieser Arbeit nur aus dem LiveTV-Zustand der Multimedia-Box heraus erstellt 

werden, was in Abschnitt 5.4.2 erklärt wird. 

Das Resultat der Untersuchung wird an den TVTimerScheduler zurückgegeben. 

Liegt kein Konflikt vor, wird die gerade getestete TV-Karte der Aufnahme 

zugeordnet, andernfalls wird die nächste TV-Karte überprüft. 

Sollte für alle verfügbaren TV-Karten ein Konflikt vorliegen, wird der Status der 

Aufzeichnung auf CONFLICT gesetzt und dies dem TVTimerControl durch 

den Rückgabewert der aufgerufenen Methode mitgeteilt. 

5.2.2.4 Starten und Beenden von Aufnahmen 

Im Falle einer konfliktfreien Aufnahme wird der korrespondierende TVTimer- 

Entry dem TVRecorderManager (siehe Abbildung 5.15) übergeben, der die 

zeitgesteuerte Aufzeichnung einrichtet. 

Dazu wird der von NMM bereitgestellte TimerProducer verwendet. Dieser 

schickt zu einem festgelegten Zeitpunkt ein zuvor definiertes Event, auf das entsprechend 

reagiert werden kann. 

Diesem Event können Parameter mitgegeben werden, was in diesem Fall die zugehörige 

ID der Aufnahme ist. Dadurch wird beim Auslösen des Events festgestellt, 

welche gestartet werden soll (siehe Abbildung 5.16). Mit Hilfe dieser ID erfragt der 

TVRecorderManager bei der TVTimerList die entsprechenden Aufnahmeinformationen. 

Sind diese vorhanden, wird ein Objekt der TVRecorder-Klasse 

(siehe Abbildung 5.17) inklusive Übergabe des erhaltenen TVTimerEntry erstellt. 

Der Rekorder wird zur Verwaltung in einer map gespeichert und nach dem 

Beenden der Aufnahme wieder gelöscht. Durch diesen Mechanismus können meh- 

117


118 

Abbildung 5.16: Der TVRecorderManager erstellt zum Aufnahmezeitpunkt 

den TVRecorder und löscht diesen nach dem Beenden der Aufnahme. 

Abbildung 5.17: Die Klasse TVRecorder erstellt den zur Aufzeichnung verwendeten 

Flussgraphen.


Abbildung 5.18: Zur Aufnahme einer Sendung von einer digitalen TV-Karte 

wird der DVBReadNode mit dem GenericWriteNode verbunden. Der 

GenericWriteNode wird von NMM zum Schreiben von Multimedia-Daten in 

eine Datei bereitgestellt. 

rere Rekorder gleichzeitig tätig sein. In der Folge erstellt der entsprechende TV- 

Recorder einen NMM-Flussgraphen anhand der gespeicherten GraphURL (siehe 

Abbildung 5.18) und zeichnet die Sendung von dem entsprechenden Kanal 

auf. Die GraphURL legt den zu verwendenden Quellknoten fest, welcher mit einem 

GenericWriteNode verbunden wird, der die Audio-Video-Daten in eine 

Datei schreibt. Als Anforderungs-Richtlinie für das Session-Sharing (siehe Abschnitt 

3.2.2) wird bei der Quelle SHARED_OR_EXCLUSIVE_THEN_SHARED 

verwendet. Dies ermöglicht das Anfordern des Quellknotens auch dann, wenn dieser 

bereits von einer anderen Anwendung verwendet wird. Zuvor muss ein Dateiname 

festgelegt werden, unter dem die Aufzeichnung auf der Festplatte gespeichert 

wird. Vorhandene Dateien dürfen nicht überschrieben werden. Deshalb ist es 

notwendig einen eindeutigen Dateinamen zu wählen. Dieser setzt sich aus dem Kanalnamen, 

von dem die Sendung aufgezeichnet wurde, und der Start-Zeit inklusive 

Datum zusammen. Zusätzlich wird bei vorhandenen EPG-Informationen dem Dateinamen 

der Titel der aufgenommenen Sendung vorangestellt, damit der Benutzer 

den Inhalt einer Datei leichter identifizieren kann. 

Beispiel 

Das folgende Beispiel zeigt mögliche Dateinamen für eine Aufnahme der ’Tagesschau’ 

der ARD am 14. September 2005. Sind keine EPG-Informationen vorhanden, 

wird die Aufzeichnung unter dem Namen 

ARD_2005-09-14_20:00.mpeg 

gespeichert. Andernfalls beginnt der Dateiname mit dem Titel der Sendung. 

Tagesschau_ARD_2005-09-14_20:00.mpeg 

Beim TimerProducer wird nach dem Starten des Graphen ein Event zur Festlegung 

des Aufnahmeendes registriert. Dieses Event wird wiederum von dem TV- 

RecorderManager gefangen, der den Rekorder stoppt und das TVRecorder- 

Objekt löscht. 

Kann der Flussgraph nicht aufgebaut werden, da die zugewiesene TV-Karte mittlerweile 

auf Grund evtl. technischer Probleme nicht mehr ansprechbar ist, wird dies 

der TVTimerControl-Klasse mitgeteilt, indem auf deren ITVTimerEvents- 

Interface die Methode tvcardUnavailable() aufgerufen wird. Die Klasse 

119


120 

Abbildung 5.19: Kann eine Aufnahme nicht erfolgen, weil die vorgesehene TV- 

Karte nicht mehr verfügbar ist, wird versucht eine neue TV-Karte zu finden um sie 

dann dafür zu nutzen. 

versucht daraufhin die Aufnahme neu zu programmieren (siehe Abbildung 5.19). 

Mit Hilfe der Methode reschedule() des TVTimerScheduler wird eine 

neue TV-Karte gesucht. Im TVTimerEntry zuvor gespeicherte TV-Karten werden 

dabei ausgeschlossen. Konnte keine neue TV-Karte gefunden werden, wird der 

Status der Aufnahme auf RECORDED_WITH_ERROR gesetzt. Sollte diese für eine 

periodische Aufzeichnung vorgesehen sein, wird der nächste Aufnahmezeitpunkt 

ermittelt und die Aufnahme programmiert. 

Bei erfolgreicher Aufzeichnung wird ihr Status auf RECORDED gesetzt und zusätzlich 

eine entsprechende GraphURL gespeichert, die den direkten Zugriff auf die 

Datei der getätigten Aufnahme ermöglicht. Diese GraphURL enthält außer dem 

Verzeichnispfad und dem Dateinamen auch den Rechnernamen, auf dem die betreffende 

Datei gespeichert wurde. Somit kann diese mit Hilfe der Netzwerkunterstützung 

von NMM abgespielt werden, wenn ein anderweitiger Zugriff, z.B. 

über das Networking Filesystem (NFS) [Lev], nicht möglich ist. Dies erfolgt dadurch, 

dass der entsprechende Quellknoten zum Auslesen der Datei über die Geräteverwaltung 

von NMM von dem entfernten Rechner angefordert wird und die 

Multimedia-Daten lokal abgespielt werden. 

5.2.2.5 Automatisches Wiederholen von Aufnahmen 

Wurde eine Aufnahme (mit oder ohne Fehler) beendet, wird überprüft, ob eine 

Periode festgelegt wurde. Ist dies der Fall, wird abhängig von der eingestellten 

Wiederholung, die neue Aufnahme nach Berechnung deren Start- und Stopp-Zeit 

programmiert. 

Besondere Beachtung muss diesbezüglich der Periode RANDOM geschenkt werden. 

Es ist möglich, dass gefundene Sendungen zur gleichen Zeit auf verschiedenen 

Kanälen gesendet werden. So wird z.B. die ’Tagesschau’ um 20:00 Uhr sowohl 

von der ARD als auch den dritten Programmen ausgestrahlt. Für die Lösung


dieses Problems wird die Sendung, die auf dem ursprünglich eingestellten Kanal 

läuft, mit der entsprechenden Periode neu einprogrammiert. Sofern genügend TV- 

Karten zur Verfügung stehen, wird versucht für die restlichen Sendungen einzelne 

Aufnahmen zu programmieren, sodass nach Möglichkeit alle parallel laufenden 

Sendungen aufgezeichnet werden. 

Beispiel 

Die Tagesschau soll mittels der Periode RANDOM aufgenommen werden. Der 

EPG liefert u.a. die folgenden Daten für diese Sendung: 

• Tagesschau auf ARD um 20:00 Uhr 

• Tagesschau auf WDR um 20:00 Uhr 

Um dennoch beide Sendungen aufnehmen zu können, wird für die Sendung auf 

WDR eine zusätzliche Aufnahme programmiert, sofern genügend TV-Karten vorhanden 

sind. 

5.2.2.6 Ändern und Löschen von Aufnahmen 

Zum Ändern einer einprogrammierten Aufnahme wird in der Anwendung der entsprechende 

TVTimerEntry angefordert und die gewünschten Informationen editiert. 

Das bearbeitete Objekt wird dem Videorekorder mittels der Methode change- 

Timer() übergeben, der versucht die neue Aufzeichnung zu programmieren. Dabei 

wird die bisherige bei der Konflikt-Erkennung nicht berücksichtigt. Sie lässt 

sich über die ID des TVTimerEntry ermitteln. Nach einer erfolgreichen Programmierung 

der neuen Aufnahme wird der alte Eintrag entfernt. Andernfalls bleibt 

dieser gültig und die Anwendung erhält die Information, dass die Aufzeichnung 

nicht, wie gewünscht, geändert werden kann. 

Das Löschen einer Aufnahme wird durch Aufrufen der Methode deleteTimer() 

bewerkstelligt (wie in Abbildung 5.20 dargestellt), wodurch lediglich der entsprechende 

TVTimerEntry aus der TVTimerList entfernt wird. Da der TVRecorderManager 

vor dem Starten den Eintrag von der TVTimerList erfragt, 

werden für nicht vorhandene Einträge keine Aufzeichnungen gestartet. 

Es ist durchaus möglich, dass Aufnahmen mit der geänderten bzw. gelöschten in 

Konflikt standen, was durch die erfolgte Änderung aufgehoben ist. Dazu wird festgestellt, 

mit welchen Einträgen die entfernte Aufnahme in Konflikt stand und diese 

neu programmiert. Mit Hilfe der Methode deleteTimersForConflict() ist 

es möglich die ID eines in Konflikt stehenden TVTimerEntry anzugeben, sodass 

dieser zuerst programmiert wird. Erst anschließend wird versucht, die restlichen in 

Konflikt stehen Aufnahmen erneut zu programmieren. 

121


122 

Abbildung 5.20: Beim Löschen einer einprogrammierten Aufnahme wird diese aus 

der TVTimerList entfernt. Anschließend wird versucht alle mit ihr in Konflikt 

stehenden Aufnahmen neu zu programmieren. 

Ein weiterer Übergabeparameter der Methoden zum Löschen und Ändern von Aufzeichnungen 

ist der Benutzername, welcher von der Anwendung bestimmt werden 

muss. Damit soll verhindert werden, dass mehrere Benutzer bei Verwendung 

des Videorekorders Aufnahmen eines anderen unerlaubt entfernen oder bearbeiten. 

Dies geschieht durch einen Vergleich des Namens mit dem in dem entsprechenden 

TVTimerEntry gespeicherten. 

5.2.2.7 Der Videorekorder als separate Anwendung 

Mit Hilfe des Programms vcrserver wird der Videorekorder als eingenständiger 

Prozess gestartet. Es bietet den Zugriff auf den Videorekorder durch die Service- 

Funktionalität von NMM (siehe Abschnitt 3.2.1), wodurch Anwendungen über das 

Netzwerk mit dem Videorekorder kommunizieren können. Der Service ist unter 

dem Namen ’TVTimer’, in Anlehnung an den TVTimer-Zustand der Multimedia- 

Box, ansprechbar. Der vcrserver enthält einen EPG, der ebenfalls als Service 

unter dem Namen ’TVGuide’ zur Verfügung gestellt wird, damit entfernte Anwendungen 

darauf zugreifen können. Beim Starten der Anwendung kann diese per 

Kommandozeilen-Optionen konfiguriert werden. 

5.3 Zugriff mehrerer Anwendungen auf mehrere Quellen 

In diesem Abschnitt wird der Fall erläutert, dass mehrere Anwendungen auf mehrere 

TV-Karten zugreifen wollen. Dafür werden nun die vorangegangenen Verwendungsarten, 

nämlich das Sammeln von EPG-Informationen von einer TV-Karte, 

das Aufzeichnen von Sendungen sowie Live TV zusammengeführt. Um diesen An-

5.3. ZUGRIFF MEHRERER ANWENDUNGEN AUF MEHRERE QUELLEN 

wendungen eine TV-Karte dynamisch zuteilen zu können, müssen Kriterien festgelegt 

werden um die Verwendbarkeit einer TV-Quelle bestimmen zu können. 

Beispiele 

• Erich benutzt eine TV-Karte für Live TV. Nun startet der Videorekorder eine 

Aufnahme und möchte die gleiche Karte verwenden. Kann ihm diese Karte 

zugeteilt werden und darf der Videorekorder ggf. den Kanal wechseln? 

• Erich und Helga greifen mit ihren Live TV-Anwendungen gemeinsam auf 

die gleiche TV-Karte zu. Wer darf den Kanal wechseln? 

• Der EPG sammelt Informationen von einer TV-Karte. Dieser schaltet minütlich 

einen Kanal weiter. Kann diese Karte für andere Anwendungen verwendet 

werden? 

Zur Lösung dieser Probleme muss zuerst eine Hierarchie der Anwendungen festgelegt 

werden. Dies verbietet nicht den Zugriff der Anwendungen auf TV-Karten, da 

durch das Session-Sharing in NMM [LRS03] die gemeinsame Nutzung von Ressourcen 

möglich ist. Vielmehr soll damit bestimmt werden, welche Anwendung 

kontrollierend auf die Karte zugreifen darf um den Kanal zu wechseln. Aus diesem 

Grund werden den einzelnen Verwendungsarten Prioritäten zugeteilt. Die Anwendung 

mit der höchsten Priorität hat dabei die Kontrolle über die Karte, sie ist der 

Master, die Anwendungen mit geringerer Priorität werden als Slave bezeichnet. 

Für diese Arbeit wurde folgende Hierarchie der Prioritäten festgelegt: 

EPG Der EPG besitzt die niedrigste Prioriät. Die einzige Aufgabe des EPG ist das 

Sammeln von Daten. Dies kann auch von einer TV-Karte, die gerade von 

einer höher priorisierten Anwendung benutzt wird, bewerkstelligt werden. 

Live TV Live TV hat mittlere Priorität. In dieser Arbeit wurde die Konvention 

getroffen, dass LiveTV eine niedrigere Stellung als der Videorekorder besitzt. 

Als Entscheidungshilfe diente dabei die Vorgehensweise handelsüblicher 

Kassetten-Videorekorder, die den Kanal wechseln, sobald eine einprogrammierte 

Aufnahme startet. 

Videorekorder Der Videorekorder besitzt die höchste Priorität. 

Weiterhin ist notwendigerweise eine Strategie für die Zuteilung von TV-Karten 

zu Anwendungen festzulegen. Bei einem Kartenwechsel muss für jede getestete 

TV-Karte ermittelt werden, ob diese verwendbar ist. Zur Minimierung dieser Abfragen 

wird zuerst versucht der anfragenden Anwendung eine TV-Karte zuzuteilen, 

auf der sie Master ist. Dadurch kann diese beliebig zwischen den bereitgestellten 

Kanälen wechseln ohne sich eine neue Karte anfordern zu müssen. Steht keine 

solche TV-Quelle zur Verfügung, wird eine gesucht, die als Slave genutzt werden 

kann. Dies kann nur erfolgen, wenn der auf der TV-Karte eingestellte Kanal gleich 

dem gewünschten ist. Generell gilt als Zuteilungskriterium die Unterstützung des 

123


124 

gewünschten Kanals durch die TV-Karte. TV-Karten, die zur Verteilung in Frage 

kommen, sind in der globalen Kanalliste festgelegt. 

Wird eine TV-Karte von mehreren Anwendungen gemeinsam verwendet, gibt es 

immer genau einen Master. Sollte dieser die TV-Karte wieder freigeben, muss ein 

Slave in den Stand des Masters ”erhoben” werden. Die Wahl fällt dabei auf die 

Anwendung, der die TV-Karte an zweiter Stelle nach dem Master zugeteilt wurde. 

Die restlichen Anwendungen behalten den Status des Slave. 

Nachfolgend werden nun einzelne Szenarien durchgespielt, die in dieser Konstellation 

auftreten können. Es wird zudem erklärt, wie in den jeweiligen Situationen 

gemäß der genannten Konventionen verfahren wird. 

5.3.1 Zusammenspiel EPG - LiveTV/Videorekorder 

Die Live TV-Anwendung greift auf eine Karte zu, die vom EPG genutzt wird. In 

diesem Fall tritt der EPG die Kontrolle der Karte an die Live TV-Anwendung ab 

und wird zum Slave. Die Live TV-Anwendung übernimmt die Kontrolle, sie wird 

zum Master. Dabei ist es unerheblich, ob noch weitere TV-Karten zur Verfügung 

stehen. Dieses Verhalten trägt den unterschiedlichen Qualitäts-Aspekten der TV- 

Karten Rechnung, da bei Live TV die Audio/Video-Qualität mehr als bei Verwendung 

durch den EPG zum Tragen kommt, der nur Text-Daten aus dem Fernseh- 

Strom liest. 

Die gleiche Vorgehensweise wird angewendet, wenn der Videorekorder anstatt der 

Live TV-Anwendung auf die Quelle zugreifen möchte. Dieser wird auf Grund seiner 

höheren Prioriät zum Master, der EPG zum Slave. 

Nach dem Beenden der Live TV-Anwendung oder der Aufnahme des Videorekorders 

erhält der EPG den Master-Status zurück und kann die Kanäle wieder entsprechend 

setzen. 

Beispiel 

In einem Szenario, in dem nur eine TV-Karte zur Verfügung steht, verwendet der 

EPG diese im Moment zum Sammeln von Informationen des Kanal A (siehe Abbildung 

5.21). Die TV-Karte stellt die Kanäle A und B bereit. Erich möchte nun 

eine Sendung auf Kanal B sehen. Wegen der Festlegung, dass Live TV eine höhere 

Priorität als der EPG besitzt, hat Erich die Kontrolle über diese TV-Karte. Deshalb 

wird sie ihm zugeteilt und der Sender auf Kanal B gewechselt. Der EPG sammelt 

nun seine Daten von Kanal B. 

Nun möchte der EPG einen Kanal weiterschalten um von ihm Daten zu sammeln. 

Erich verwendet seine Karte jedoch weiterhin für Live TV. Der EPG muss sich nun 

eine neue TV-Karte zur Beschaffung seiner Daten anfordern. Da jedoch nur eine 

TV-Karte zur Verfügung steht, kann der EPG weiterhin nur Daten von Kanal B


a) b) 

Live TV-Anwendung 

von Erich EPG 

möchte Kanal B 

einstelen 

hat Kanal A 

eingestellt 

TV-Karte stellt 

Kanäle A und B 

bereit 


von Erich 

hat Kanal B 

eingestellt 

Anfrage nach TV-Karte 

Master-Zugriff auf TV-Karte 

Slave-Zugriff auf TV-Karte 

EPG 



bereit 

Abbildung 5.21: In Teil a) sammelt der EPG Daten von Kanal A. Erich möchte 

nun Kanal B einstellen. Da Live TV die höhere Priorität besitzt, darf Erich den 

Kanal wechseln (siehe Teil b)). 

sammeln. 

Erich beendet nun seine Live TV-Anwendung und gibt die Karte wieder frei, woraufhin 

der EPG erneut zum Master wird und die Kanäle wechseln kann. 

5.3.2 Zusammenspiel Live TV - Live TV 

Wollen zwei Live TV-Anwendungen auf die gleiche TV-Karte zugreifen, wird nach 

dem First-Come-First-Serve-Prinzip 1 verfahren. Derjenige, der zuerst die Karte für 

sich beansprucht hat, ist Master, der sich danach auf sie aufschaltet, ist Slave. Ihm 

wird jedoch die Karte nur zugeteilt, wenn der Master den gleichen Kanal eingestellt 

hat, den auch der Slave wünscht und der von keiner weiteren TV-Karte bereitgestellt 

wird. 

Weiterhin soll auch im laufenden Betrieb die erneute Zuteilung einer TV-Karte vorgenommen 

werden. Dieser Fall tritt dann ein, wenn einer Anwendung eine Karte 

als Slave zugeteilt wurde und der Master den Kanal wechselt. Der Slave muss sich 

daraufhin eine neue TV-Quelle anfordern um den bisher eingestellten Kanal weiterhin 

zu empfangen. 

Beispiele 

In dem folgenden Szenario stehen Helga und Erich zwei TV-Karten zur Verfügung. 

Die erste TV-Karte, Karte 1, stellt die Kanäle A und B bereit, die zweite die Kanäle 

B und C. 

Helga möchte sich eine Sendung auf Kanal A ansehen. Da nur Karte 1 diesen Kanal 

bereitstellt und frei ist, wird ihr diese Karte zugeordnet. 

1 Im Deutschen gibt es dafür das Sprichwort: Wer zuerst kommt, mahlt zuerst 

125


126 

a) 


von Erich 


KanÃ¤le A und B 

bereit 


von Helga 

hat Kanal A 

eingestellt 


KanÃ¤le B und C 

bereit 

b) 


von Erich 

hat Kanal A 

eingestellt 


KanÃ¤le A und B 

bereit 





von Helga 

hat Kanal B 

eingestellt 


KanÃ¤le B und C 

bereit 

Abbildung 5.22: In Teil a) empfangen die Benutzer Helga und Erich Kanal A über 

die erste TV-Karte. Erich möchte Kanal B einstellen, hat aber nicht die Kontrolle 

über die TV-Karte. Da die zweite TV-Karte Kanal B ebenfalls zur Verfügung stellt, 

wird Erich diese zugewiesen, was in Teil b) dargestellt ist. 

Erich möchte nun auch die Sendung auf Kanal A verfolgen. Nur Karte 1 stellt 

diesen Kanal bereit, wird jedoch momentan verwendet. Da auf Karte 1 Kanal A 

aktuell eingestellt ist, wird ihm diese Karte als Slave zugeteilt, d.h. er darf auf 

Karte 1 den Kanal nicht wechseln. 

Erich möchte nun aber auf Kanal B umschalten (siehe Abbildung 5.22). Karte 1, 

die er gerade nutzt, stellt diesen Kanal bereit. Er ist jedoch Slave auf seiner Karte. 

Da Kanal B auch über Karte 2 empfangen werden kann, wird ihm Karte 2 zugeteilt. 

Diese TV-Karte wird bisher von niemandem verwendet, sodass Erich als Master 

auf dieser Karte gilt. 

Helga’s Sendung auf Kanal A ist nun zu Ende. Sie möchte auf Kanal C umschalten. 

Dieser Kanal wird jedoch nur von Karte 2 bereitgestellt, welche gerade von Erich 

verwendet wird. Da Erich Kanal B eingestellt hat, kann Helga diese Karte nicht 

nutzen, d.h. sie kann nicht auf Kanal C wechseln. 

Da Kanal B auch von Karte1 bereitgestellt wird, die nun zur Verfügung steht, könnte 

Erich Karte 2 entzogen und Karte 1 zugeteilt werden. Um aber den Audio/Video- 

Strom von Erich nicht zu unterbrechen, behält er die Karte 2. Weiterhin würde dies 

bedeuten, dass auch dem Videorekorder während einer Aufnahme eine neue TV- 

Karte zugeteilt werden müsste. Da, wie Eingangs erwähnt, die Aufzeichnung nach 

Möglichkeit nicht unterbrochen werden soll, ist dieses Vorgehen nicht realisiert. 

5.3.3 Zusammenspiel LiveTV - Videorekorder 

Bei einer gemeinsamen Verwendung einer TV-Quelle durch den Videorekorder und 

Live TV kann dieser, der Konvention entsprechend, immer die Kontrolle über eine 

TV-Karte übernehmen, da ihm die höhere Priorität zugewiesen wurde. Die Live


a) b) 


von Erich Videorekorder 

hat Kanal A 

eingestellt 

möchte Kanal B 

einstellen 



bereit 


von Erich 




Videorekorder 

hat Kanal B 

eingestellt 



bereit 

Abbildung 5.23: In Teil a) verwendet der Benutzer Erich die TV-Karte für Live 

TV. Er hat Kanal A eingestellt. Der Videorekorder möchte auf die gleiche Karte 

zugreifen und Kanal B einstellen. Auf Grund der höheren Priorität schaltet der 

Videorekorder auf Kanal B (siehe Teil b)). 

TV-Anwendung wird dabei über den Status-Wechsel auf der TV-Karte informiert. 

Diese beginnt daraufhin mit der Suche nach einer neuen TV-Karte, die den bisher 

eingeschalteten Kanal unterstützt und somit verwendet werden kann. Ein solcher 

Vorgang ist allerdings nur notwendig, wenn der einzustellende Kanal des Videorekorders 

und der von Live TV genutzte unterschiedlich sind. Andernfalls kann 

die Live TV-Anwendung die TV-Karte weiterhin einsetzen, muss jedoch bei einem 

Kanalwechsel eine neue TV-Karte zugeteilt bekommen. 

Beispiel 

In diesem Beispiel wird zur einfachen Veranschaulichung ein Szenario beschrieben, 

in dem nur eine TV-Karte zur Verfügung steht, welche die Kanäle A und 

B bereitstellt (siehe Abbildung 5.23). Erich schaut Kanal A. Der Videorekorder 

startet eine Aufnahme auf Kanal A. Erichs Status ändert sich zwar von Master auf 

Slave. Da jedoch der gleiche Kanal aufgenommen wird, muss keine neue TV-Karte 

gesucht werden. 

Die Aufnahme von Kanal A wurde beendet und eine weitere startet, dieses Mal 

von Kanal B. Da der Videorekorder die höhere Priorität besitzt, übernimmt er die 

Kontrolle von Karte 1 und ändert den Kanal. Da der Versuch Erich eine neue TV- 

Karte zuzuteilen, nicht möglich ist, kann er Kanal A nicht länger verfolgen. 

5.3.4 Zusammenspiel EPG - Live TV - Videorekorder 

Nun werden alle beschriebenen Konzepte in einem Algorithmus zusammengefasst, 

der alle getroffenen Konventionen zum Festlegen einer verwendbaren TV-Karte berücksichtigt. 

Dieser wird im Laufe dieses Abschnitts im Pseudo-Code beschrieben. 

Der Ablauf ist in Abbildung 5.24 graphisch dargestellt. 

127


128 

TV-Karte wird 

nicht verwendet 

Setze Kanal A 


TV-Karte aus Liste erhalten 

Prüfe, ob TV-Karte schon 

von anderer Anwendung 

verwendet wird 

XOR 

Anwendung hat 

geringere Priorität 

Benachrichtige Anwendung 

über Statuswechsel 

Anwendung benachrichtigt 

Setze Kanal A 


Kanal A soll 

gesetzt werden 

Erfrage TV-Karten von 

globaler Kanalliste 

Liste mit TV-Karten erhalten, 

die Kanal A bereitstellen 


TV-Karte wird 

bereits verwendet 

Prüfe Priorität der 

verwendendenen 

Anwendung 

XOR 

XOR 

Kanal A ist 

eingestellt 

Merke TV-Karte zu 

eventuellen späteren 

Verwendung 

TV-Karte gemerkt 

Anwendung hat gleiche 

oder höhere Priorität 

Kanal A noch 

eingestellt 

Verwende TV-Karte 

gemeinsam mit 

anderer Anwendung 

Prüfe, ob Kanal A 

eingestellt ist 

XOR 

Kanal A ist 

nicht eingestellt 

TV-Karte erhalten 

Prüfe, ob Kanal A 

immer noch eingestellt ist 

XOR 

Kanal A nicht mehr 

eingestellt 

Keine TV-Karte in Liste 

vorhanden 


der gemerkten TV-Karten 

XOR 

Keine TV-Karte erhalten 

Fehlerbehandlung: 

Kanal A kann nicht 

eingestellt werden 

Abbildung 5.24: In einem MehrbenutzerSzenario wird bei einem Zugriff einer 

Anwendung auf eine TV-Karte nach dem dargestellten Ablauf vorgegangen.


Bei einer TV-Anwendung ist das Setzen eines Kanals immer die erste Handlung: 

Der Videorekorder schaltet nach dem Zugriff auf eine TV-Quelle auf den Sender, 

von dem er eine Sendung aufzeichnen soll. Bei Live TV wird nach dem Starten 

der initiale Kanal eingestellt. Der EPG schaltet auf den ersten Kanal, von dem er 

Daten sammeln soll. 

Als Ausgangspunkt dient deshalb das Setzen des Kanals A, wofür zuerst bestimmt 

wird, ob eine TV-Karte bereits verwendet wird. Ist dies der Fall, wird überprüft, ob 

die bereits verwendete TV-Karte Kanal A unterstützt. Zu diesem Zweck wird auf 

die globale Kanalliste zugegriffen, welche diese Informationen enthält und überprüft, 

ob die momentan verwendete TV-Karte in der erfragten Kartenliste enthalten 

ist. Trifft dies zu, muss weiterhin kontrolliert werden, ob die Anwendung Master 

auf dieser Karte ist und damit den Kanal wechseln darf. 

Diese Vorgehensweise berücksichtigt die Konvention, dass ein Master auf der TV- 

Karte bei einem Kanalwechsel keine neue suchen muss, wenn seine aktuell verwendete 

den Kanal bereitstellt. Der erste Teil des Algorithmus ist im Pseudocode 

wie folgt beschrieben: 

if( Eine Karte wird benutzt ){ 

Erfrage Kartenliste für Kanal A von globaler Kanalliste; 

if( Die benutzte Karte ist in Kartenliste ){ 

if( Benutzer ist Master auf der Karte ){ 

verwende TV-Karte; 

Setze Kanal A; 

return; 

} 

} 

} 

Sollte einer der Tests fehlschlagen, muss eine neue TV-Karte gesucht werden. Dazu 

sind alle zuvor ermittelten Karten in der Kartenliste auf Verwendbarkeit zu untersuchen. 

Es wird zuerst ermittelt, ob die zu prüfende TV-Karte verfügbar ist, was bei 

einem Zugriff über das Netzwerk auf Grund technischer Probleme nicht möglich 

sein kann. Ist die TV-Karte erreichbar, muss getestet werden, ob sie bereits von anderen 

Anwendungen genutzt wird. Im negativen Fall kann diese TV-Karte verwendet 

und Kanal A eingestellt werden. Im positiven Fall wird überprüft, ob die Quelle 

von einer geringer priorisierten Anwendung gebraucht wird. Dadurch wird der Benutzer 

zum Master und kann den Kanal A setzen. Die geringer priorisierte Anwendung 

wird dadurch zum Slave und über den Statuswechsel benachrichtigt. Im negativen 

Fall wird ermittelt, welcher Kanal auf der TV-Karte eingestellt ist. Ist dies 

Kanal A, so kann auf diese Quelle später von der Anwendung als Slave zugegriffen 

werden. Zu diesem Zweck wird die Karte in der Liste verwendbareTVKarten 

für einen evtl. späteren Zugriff gespeichert. 

Dies berücksichtigt die Konventionen, dass höher priorisierte Anwendungen den 

Kanal wechseln dürfen und zuerst versucht wird eine TV-Karte zu finden, auf der 

die Anwendung Master-Status besitzt. Der Teil des Algorithmus zur Suche nach 

einer Master-TV-Karte lautet wie folgt: 

129


130 

foreach( Karte in Kartenliste ){ 

if( Karte ist verfügbar ){ 

if( Karte wird von einer anderen Anwendung verwendet ){ 

if( Karte wird von geringer priorisierten 

Anwendung verwendet ){ 


Setze Kanal A und benachrichtige 

die andere Anwendung über Statuswechsel; 

return; 

}else{ 

if( Kanal A ist auf TV-Karte eingestellt ){ 

speichere TV-Karte in Liste verwendbareTVKarten; 

} 

continue; 

}else{ 


Setze Kanal A; 

return; 

} 

}else{ 

continue; 

} 

} 

Nach diesem Ablauf wurde entweder eine TV-Karte gefunden, auf welcher der 

Benutzer Master ist oder es sind solche bekannt, die als Slave verwendet werden 

können, da auf diesen der gewünschte Kanal A eingestellt ist. Zur Sicherheit wird 

vor Verwendung der Karten noch einmal auf den eingestellten Kanal getestet, da 

während der oben besprochenen Tests der TV-Karten die Anwendung, welche die 

TV-Quelle nutzt, zwischenzeitlich den Kanal gewechselt haben kann, sodass Kanal 

A nicht mehr eingestellt ist. 

foreach( Karte in verwendbareTVKarten ){ 

if( Kanal A ist auf Karte eingestellt ){ 


return; 

} 

} 

Fehler: Es konnte keine geeignete TV-Karte gefunden werden. 

Sollte auch keine TV-Karte zur Verwendung als Slave zur Verfügung stehen, kann 

Kanal A nicht empfangen werden. Der Algorithmus liefert einen Fehler zurück, 

auf den die Anwendung entsprechend reagieren kann. 

5.3.5 Festlegung des Verwendungszwecks einer Quelle 

Zum Festlegen des Verwendungszwecks eines NMM-Knotens reicht es nicht aus, 

lediglich die momentane Nutzung des Masters z.b. für Live TV, zu speichern. Wird 

diese Information von einem Videorekorder überschrieben, kann der alte Wert nicht 

mehr hergestellt werden, wenn der Videorekorder den Knoten wieder freigibt.


Abbildung 5.25: Die Usage-Klasse dient dem Speichern des Verwendungszwecks 

eines Knotens. Das Interface IUsageNotify wird von allen Objekten 

implementiert, die eine Verwendung setzen wollen. 

Um festzustellen, welcher Benutzer auf welche Weise den angeforderten NMM- 

Knoten nutzt, wurde die Usage-Klasse entwickelt (siehe Abbildung 5.25). Sie 

speichert alle notwendigen Informationen und legt fest, welcher Benutzer der Master 

eines Knotens ist. 

Zum Setzen einer Verwendungsart muss die Anwendung das IUsageNotify- 

Interface implementieren. Dies dient der Identifizierung des Benutzers und dessen 

Benachrichtigung bei einem Statuswechsel. 

Damit bei jedem Knoten die Verwendung angegeben werden kann, wurde die 

Usage-Klasse als Oberklasse von GenericNode in NMM integriert. Diese wiederum 

dient als Oberklasse für jeden in NMM verfügbaren Knoten. Intern speichert 

die Usage-Klasse die Benutzer-Daten zu jedem Verwendungszweck zu dessen 

Identifizierung in einer map. 

Dabei werden Schlüssel vom Typ int gebraucht, welche zur Angabe des Verwendungszwecks 

dienen. Diese sind von der Anwendung festgelegt und spezifizieren 

gleichzeitig die Priorität des Verwendungszwecks. 

Zu jedem Schlüssel der map wird eine Liste von Paaren gespeichert, die sich aus 

einem Pointer auf das IUsageNotify-Interface der jeweiligen Anwendung und 

einem int zusammensetzen. Der Integer gibt an, wie oft die Applikation den Knoten 

mit der durch den Schlüssel bestimmten Verwendung angefordert hat. Durch 

131


132 

diesen Rang wird sichergestellt, dass eine Anwendung den Knoten für den gleichen 

Zweck mehrfach anfordern kann ohne ggf. den Master-Status zu verlieren, sobald 

sie den Knoten von einer Verwendung wieder freigibt. Aus diesem Grund muss bei 

der isMaster-Abfrage auch der Rang berücksichtigt werden. 

Die Methode Result Usage::isMaster() dient zur Abfrage, ob eine Anwendung 

auf dem Knoten Master ist. Der beabsichtigte Verwendungszweck einer 

solchen wird dabei als Parameter übergeben. Die Methode ermittelt zuerst die 

momentane Verwendung des Knotens. Hat diese eine höhere Priorität, wäre die 

Anwendung bei einem Zugriff Slave, was durch den Rückgabewert FAILURE angezeigt 

wird. Im Falle des Masters lautet der Rückgabewert SUCCESS. Besitzt der 

Verwendungszweck die gleiche Priorität, wird ermittelt, wer sich dafür schon registriert 

hat. Ist der Benutzer, der sich als erstes dafür registriert hat, gleich dem 

anfragenden, so ist dieser der Master, andernfalls Salve. 

Die Abfrage nach der Kontrollmöglichkeit eines Benutzers über einen Knoten ist 

auf Anwendungsebene realisiert. In NMM ist es nicht möglich, das Versenden von 

Events bei einem Methoden-Aufruf über ein Interface (vergleiche Abschnitt 3.1) 

zu blockieren. Aus diesem Grund ist es notwendig, dass jede Anwendung, die in 

den vorgestellten Szenarien partizipiert, z.B. vor einem Kanalwechsel prüft, ob sie 

dazu berechtigt ist. 

Dies bedeutet, dass die Anwendung der Usage-Klasse des Knotens bei dessen 

Verwendung ihre Verwendungsart sowie das implementierte IUsageNotify- 

Interface mitteilen muss. Dadurch wird sie identifiziert und bei Status-Wechsel 

benachrichtigt, was wie folgt durchgeführt wird: 

/ ∗ V a r i a b l e n d e k l a r a t i o n e n ∗ / 

/ ∗ Das ITVCard−I n t e r f a c e der TV−Q u e l l e ∗ / 

ITVCard* tvsource; 

/ ∗ 

P r i o r i t ä t der Verwendungsart , 

z . B . L i v e TV h a t P r i o r i t ä t 5 

∗ / 

int prority = 5; 

... 

/ ∗ 

A n f o r d e r n des IUsage−I n t e r f a c e der v e r w e n d e t e n Q u e l l e 

∗ / 

IUsage *usage = tvsource->getParentObject() 


/ ∗ 

S e t z e n des Verwendungszwecks f ü r L i v e TV 

∗ / 

usage->setUsage(priority, 

this->getInterface()); 

Des Weiteren muss vor einem Kanalwechsel bei dem Knoten die Berechtigung der 

Anwendung erfragt werden. Nur bei positiver Rückmeldung ist der kontrollierende 

Zugriff auf den Knoten gestattet:


/ ∗ 


∗ / 



/ ∗ 

Vor dem S e t z e n e i n e s Kanals muss e r m i t t e l t werden , 

ob d i e B e r e c h t i g u n g d a f ü r b e s t e h t 

∗ / 

if( usage->isMaster(priority, 

this->getInterface()) ){ 

/ ∗ 

E r s t dann d a r f der Kanal g e s e t z t werden 

∗ / 

tvsource->setChannel(1); 

} 

Die Anwendung muss dem Knoten vor dessen Freigabe mitteilen, dass sie ihn nicht 

mehr für die angegebenen Zwecke benötigt. Dies ist bei einer gemeinsamen Verwendung 

des Knotens durch mehrere Anwendungen wichtig. Der Knoten selbst 

kann nicht ohne weiteres feststellen, welche Anwendung ihn freigegeben hat, d.h. 

für welchen Verwendungszweck er nicht mehr benötigt wird. Bei Freigabe eines 

Knotens kann nun ermittelt werden, von welchem Benutzer er gebraucht wurde. 

Hat ein Anwender nun den Knoten für Live TV eingesetzt und auch den Videorekorder 

gestartet, kann die Geräteverwaltung von NMM den Verwendungszweck 

der Knoten nicht erkennen, da lediglich Benutzer-, jedoch keine Verwendungsinformationen 

übertragen werden. Das Zurücknehmen des Verwendungszwecks 

kann wie folgt vorgenommen werden: 

/ ∗ 


∗ / 



/ ∗ 

Zurücknehmen des Verwendungszwecks 

∗ / 

usage->unsetUsage(priority, 

this->getInterface()); 

5.3.6 Bestimmung einer verwendbaren Quelle 

Zur Bestimmung einer verwendbaren TV-Quelle wurde der in Abschnitt 5.3 entwickelte 

Algorithmus in der Klasse TVManager implementiert. Das Klassendiagramm 

der TVManager-Klasse ist in Abbildung 5.26 zu sehen. Diese bestimmt 

für einen zu setzenden Kanal die zugeordneten TV-Karten, was mit einem 

Zugriff auf die globale Kanalliste durchgeführt wird. Anschließend ermittelt 

sie aus den TV-Quellen eine verwendbare TV-Karte und verbindet diese mit 

dem angegebenen NMM-Flussgraphen. Dazu ist auch festzulegen, für welchen 

Zweck der TVManager eine TV-Quelle suchen soll, da dieser neben LiveTV auch 

133


134 

Abbildung 5.26: Die Klasse TVManager. 

zur Suche einer Quelle für das DVB-EPG-Plugin (siehe Abschnitt 4.2.5) genutzt 

wird. Dies erfolgt durch Übergabe des Verwendungszwecks im Konstruktor der 

TVManager-Klasse. 

Die Spezifizierung des Flussgraphen wird von der Anwendung vorgenommen, indem 

sie - mit Ausnahme der Quelle - alle zu verwendenden Knoten sowie deren 

Kanten festlegt. Diesen Graphen und den mit der Quelle zu verbindenden Knoten 

teilt sie dem TVManager mit. 

Weiterhin kann der TVManager informiert werden, welche Senken der Flussgraph 

verwendet. Dadurch werden diese mit einem von NMM bereitgestellten Synchronizer 

verbunden, was bei einem mehrfachen Zugriff auf diese Quelle zu einer 

synchronen Wiedergabe der Audio- und Video-Daten zwischen den entsprechenden 

Rechnern führt. Eine Beschreibung der Synchronisierung findet sich in [Did02]. 

Zur Suche einer geeigneten TV-Quelle wird der TVManager-Klasse mittels der 

setChannel(int c)-Methode eine Kanalnummer übergeben, für welchen eine 

TV-Quelle gesucht werden soll. Sie bezieht sich auf den entsprechenden Kanal 

in der globalen Kanalliste. Somit sind alle TV-Karten bekannt, die diesen Kanal 

bereitstellen. 

Die Vorgehensweise des TVManager ist in Abbildung 5.27 graphisch dargestellt. 

Die Klasse prüft zuerst, ob momentan eine TV-Karte verwendet und der gewünschte 

Kanal von dieser zur Verfügung gestellt wird. Bei Verwendung einer TV-Karte 

ist deren zugehörige GraphURL gespeichert. Sie wird in der von der globalen Kanalliste 

gelieferten TV-Karten-Liste gesucht. Wurde die TV-Karte gefunden, wird 

überprüft, ob die TV-Quelle als Master verwendet wird. Dies wird durch Erfragen


Abbildung 5.27: Das Sequenzdiagramm zeigt den Ablauf der Suche einer verwendbaren 

TV-Karte durch den TVManager. Es stehen zwei TV-Karten zur Verfügung, 

wobei die erste davon momentan verwendet wird. Die zweite TV-Karte wird von 

einer höher priorisierten Anwendung genutzt. 

des Staus über das IUsage-Interface des verwendeten Knotens vollzogen. Ist die 

Anwendung Master, wird der gewünschte Kanal eingestellt. 

Wird momentan keine TV-Quelle verwendet, die aktuell genutzte stellt den gewünschten 

Kanal nicht bereit oder wird auf sie als Salve zugegriffen, dann muss 

eine neue TV-Quelle ermittelt werden. Dazu wird gemäß der Konvention zuerst 

nach einer TV-Karte mit Master-Status gesucht, was in der Methode request- 

CardExclusive(...) realisiert wurde. Diese nutzt den von der Anwendung 

festgelegten NMM-Flussgraphen, mit dem die entsprechend zu testende Quelle 

verbunden und deren Verwendbarkeit geprüft wird. Dazu werden die spezifizierten 

Knoten angefordert. Um für das DVB-EPG-Plugin eine geeignete TV-Karte 

zu finden wird beim Anfordern der Knoten zusätzlich festgelegt, dass diese das 

ITVGuideProducer-Interface implementieren müssen um als EPG-Quelle dienen 

zu können. Andernfalls wird mit der Überprüfung der nächsten TV-Karte fortgefahren. 

Als Anforderungs-Richtlinie für das Session-Sharing wird bei der Knotenbeschreibung 

der Quelle SHARED_OR_EXCLUSIVE_THEN_SHARED gesetzt um bereits 

verwendete Knoten anfordern zu können oder anderen Anwendungen das 

Mitbenutzen des Knotens zu gestatten. Das Session-Sharing in NMM wurde in 

Abschnitt 3.2 vorgestellt. 

135


136 

Ist die Quelle von einer anderen Anwendung bereits belegt, wird nun festgestellt, 

welcher Kanal eingestellt ist. Entspricht dieser dem gewünschten, werden Informationen 

über die TV-Karte gespeichert um bei einer erfolglosen Suche diese Quelle 

u.U. als Slave verwenden zu können. Zu den abgelegten Informationen zählen neben 

der GraphURL und dem eingestellten Kanal auch der Verwendungszweck der 

Quelle, der bei einem evtl. Zugriff als Slave berücksichtigt wird. Falls auf die TV- 

Quelle als Master zugegriffen werden kann, wird zuerst der ggf. momentan verwendete 

NMM-Graph freigegeben. Anschließend werden die Knoten des neuen 

Graphen verbunden und der gewünschte Kanal eingestellt, sodass der Flussgraph 

gestartet werden kann. Andernfalls werden die Knoten desselben wieder freigegeben 

und die nächste TV-Quelle überprüft. 

Falls keine TV-Quelle mit Master-Status ermittelt werden konnte, wird versucht 

auf eine TV-Karte als Slave zuzugreifen. Dafür in Frage kommende Quellen wurden 

bei der Suche nach einer Master-Karte bereits gefunden. Diese Funktionalität 

wurde in der Methode requestCardShared() implementiert. Sie versucht 

zuerst TV-Karten zu nutzen, die mit dem Videorekorder belegt sind, da bei diesem 

die Wahrscheinlichkeit eines Kanalwechsels im Vergleich zu Live TV geringer 

ist. Eine solche Vorgehensweise dient dem Minimieren der Suchanfragen nach 

einer neuen TV-Quelle. Eine Berücksichtigung der Präferenz der TV-Karte ist aus 

diesen Gründen zweitrangig. Als Anforderungs-Richtlinie des Quellknotens wird 

SHARED verwendet, da die ermittelten TV-Karten bereits belegt sind und ggf. 

mitverwendet werden sollen. Weiterhin wird jede TV-Karte dahingehend geprüft, 

ob der gewünschte Kanal noch eingestellt ist und somit als Slave daraufzugegriffen 

werden kann. Anschließend folgt das Testen der TV-Karten mit LiveTV-Belegung. 

Sollte auch auf diesem Wege keine verwendbare TV-Karte gefunden werden ist es 

nicht möglich, den gewünschten Kanal zur Verfügung zu stellen. Andernfalls wird 

der ggf. momentan verwendete Flussgraph freigegeben und die Knoten des neuen 

Graphen verbunden, so dass dieser gestartet werden kann. 

Eine besondere Vorgehensweise wird bei einem sequentiellen Kanalwechsel mittels 

der Methoden channelUp() und channelDown() angewendet. Sie versuchen 

solange die Kanäle durchzuschalten, bis sie entweder einen empfangbaren 

Sender gefunden haben oder wieder an ihrem Ausgangspunkt angelangt sind. Um 

den Vorgang zu beschleunigen und unnötige Anfragen an TV-Karten zu vermeiden, 

werden Daten zu bereits überprüften und von höher priorisierten Anwendungen genutzten 

TV-Karten gespeichert, sodass diese nicht erneut getestet werden müssen. 

Im Gegensatz dazu wären freie oder von niedriger priorisierten Anwendungen verwendete 

TV-Karten als benutzbar erkannt und der entsprechende Knoten mit dem 

NMM-Graphen verbunden worden. Die zu speichernden Daten umfassen die GraphURL 

der TV-Karte sowie deren momentan eingestellten Kanal. 

Als Beispiel sei die Vorgehensweise der Methode channelUp() erklärt. Dazu 

stehen drei TV-Karten A, B und C bereit. Die globale Kanalliste enthält folgende 

Informationen: Kanal 1 kann von TV-Karte A und B empfangen werden, Kanal 

2 von Karte A und Kanal 3 von TV-Karte B und C. Das Ausgangsszenario stellt 

sich wie folgt dar: Der Videorekorder verwendet momentan Karte A und hat Kanal 

1 eingestellt. Eine Live TV-Anwendung hat Kanal 1 auf Karte B eingestellt und 

schaltet nun mittels channelUp() weiter. Daraufhin wird von der globalen Ka-


nalliste ermittelt, dass lediglich Karte B Kanal 2 bereitstellt. Da Karte B jedoch 

zum Empfang von Kanal 1 verwendet wird, werden diese Informationen abgespeichert. 

Somit ist Kanal 2 nicht zu empfangen. Deshalb wird nun versucht Kanal 

3 einzustellen, welcher von den Karten B und C bereitgestellt wird. Auf Grund 

der zuvor gespeicherten Informationen ist bereits bekannt, dass Karte B verwendet 

wird und auf dieser Kanal 1 eingestellt ist. Karte B wird deshalb aus der Karten- 

Liste, die aus der globalen Kanalliste ermittelt wurde, entfernt. Auf diese Weise 

wird verhindert, dass sie beim bei der Suche nach einer Master-Karte angesprochen 

wird. Lediglich Karte C wird deshalb getestet, was erfolgreich ist und Kanal 

3 somit empfangen werden kann. Die gespeicherten Informationen sind anschließend 

zu löschen, da Karte 1 beim nächten Umschaltversuch wieder frei sein kann. 

5.4 Integration in die Multimedia-Box 

Zur Integration der beschriebenen Konzepte in die Multimedia-Box wurden die in 

[BCE + 02] und [Kle03] entwickelten Zustände TVTimer und LiveTV überarbeitet 

und ergänzt. 

5.4.1 Der TVTimer-Zustand 

Zur Bedienung des Videorekorders wurde der TVTimer-Zustand der Multimedia- 

Box komplett überarbeitet. Der Status des Zustandes zu Beginn dieser Arbeit wurde 

bereits in Kapitel 3.3 beschrieben. 

Zu den Anforderungen, welche an die neue Implementierung des Zustandes gestellt 

wurden, zählte neben der übersichtlichen Anzeige der einprogrammierten 

Aufnahmen auch das Einblenden vorhandener EPG-Informationen. Zudem sollte 

die manuelle Eingabe und das Bearbeiten von Aufnahmen erleichtert, erkannte 

Konflikte angezeigt und manuell aufgelöst werden. 

Graphische Benutzeroberfläche 

Zur Erfüllung dieser Anforderungen wurde die graphische Benutzeroberfläche des 

TVTimer-Zustandes in zwei Widgets aufgeteilt, wie in Abbildung 5.28 zu sehen 

ist. Das obere Widget zeigt alle einprogrammierten Aufnahmen, die nach ihrem 

Status gruppiert sind. Innerhalb einer Gruppe sind sie nach Zeiten geordnet. Zuerst 

werden alle abgeschlossenen Aufzeichnungen angezeigt, gefolgt von solchen, die 

gerade aufgezeichnet werden. Es schließt sich eine Gruppe von Aufnahmen an, die 

für eine zukünftige Aufzeichnung einprogrammiert sind und endet mit denen, für 

die ein Konflikt erkannt wurde und aus diesem Grund nicht aufgezeichnet werden. 

Dadurch wird eine Übersicht aller nicht programmierbaren Aufnahmen geboten 

um diese schneller identifizieren zu können. 

Die angezeigten Informationen der einzelnen Aufnahmen in der Liste beschrän- 

137


138 

Abbildung 5.28: Der TVTimer-Zustand zeigt im oberen Widget programmierte 

Aufnahmen in einer Listendarstellung an. Im unteren Widget werden zu einer 

selektierten Aufnahme zusätzliche Informationen sowie vorhandene EPG- 

Informationen angezeigt. 

ken sich auf Tag und Monat sowie Start- und Stopp-Zeit. Die fehlende Angabe der 

Stopp-Zeit – dies ist bei Aufnahmen der Fall, die aus dem LiveTV-Zustand heraus 

ohne EPG-Informationen programmiert werden (siehe Abschnitt 5.4.2) – wird 

durch Querstriche gekennzeichnet. Darauf folgt der Kanal, für den die Aufnahme 

programmiert wurde. Die letzte Spalte enthält Informationen über den Status einer 

Aufnahme, der jeweils - außer SLEEPING - im Volltext angezeigt wird. Bei 

Aufnahmen mit Status SLEEPING bleibt jenes Feld entweder leer oder die einprogrammierte 

Periode wird angegebenen. Dazu zählen: 

Daily Die Aufnahme wird täglich zu der angegebenen Uhrzeit ausgeführt. 

Weekly Die Aufnahme wird wöchentlich zu der angegebenen Uhrzeit ausgeführt. 

Monthly Die Aufnahme wird monatlich zu der angegebenen Uhrzeit ausgeführt. 

Weekdays Die Aufnahme wird wochentäglich zu der angegebenen Uhrzeit ausgeführt. 

Weekends Die Aufnahme wird an jedem Wochenendtag zu der angegebenen Uhrzeit 

ausgeführt. 

* Die Aufnahme wird auf Basis von EPG-Informationen wiederholt ausgeführt. 

*Channel Die Aufnahme wird auf Basis von EPG-Informationen nur auf diesem 

Kanal wiederholt. 

*ChannelTime Die Aufnahme wird auf Basis von EPG-Informationen nur auf 

diesem Kanal zu der angegebenen Uhrzeit wiederholt. 

Das untere Widget enthält erweiterte Informationen zu einer Aufnahme. Dazu zählen 

Start- und Stopp-Zeit inklusive Datum, der für die Aufnahme programmierte


Abbildung 5.29: Wurde eine Wiederholung basierend auf EPG-Informationen programmiert, 

werden die Startzeiten aller bisher gefundenen Sendungen angezeigt. 

Kanal, die GraphURL der zugeteilten TV-Karte und der Benutzername des Anwenders, 

welcher die Aufnahme programmiert hat. 

Sollten EPG-Informationen vorhanden sein, werden zudem der Titel der aufzunehmenden 

Sendung und die erweiterte Beschreibung angezeigt. 

Ist für die Aufnahme eine auf EPG-Informationen basierende Periode eingestellt 

worden, sind in diesem Widget zusätzlich die Start-Zeiten der bisher gefundenen 

Daten aufgeführt (siehe Abbildung 5.29). 

Bedienung 

In Anlehnung an die Bedienung der restlichen Zustände der Multimedia-Box wird 

auch hier das Wechseln der Widgets mit den Tasten ’Rechts’ und ’Links’ bewerkstelligt. 

Das Scrollen innerhalb der Widgets kann durch Drücken der Tasten ’Hoch’ 

und ’Runter’ erfolgen. 

Die Farbknöpfe werden, abhängig von der gewählten Aufnahme, mit unterschiedlicher 

Funktionalität belegt. Mittels des roten Farbknopfes kann der Benutzer eine 

Aufnahme löschen oder eine laufende Aufnahme stoppen. Ist er dazu nicht berechtigt, 

weil die Aufzeichnung von einem anderen Benutzer erstellt wurde, wird bei 

dem Versuch eine solche zu löschen, eine Fehlermeldung eingeblendet. 

Der gelbe Farbknopf wird in der Übersicht je nach Status der Aufzeichnung unterschiedlich 

belegt. Durch Einsatz dieses Knopfes wird eine bereits aufgezeichnete 

Sendung mit Hilfe des Playlist-Zustandes [Kle03] abgespielt, wozu diesem der 

gespeicherte Dateiname übergeben wird. Ebenso kann eine laufende Aufnahme 

betrachtet werden, wozu die Anwendung in den LiveTV-Zustand wechselt. 

Bei einem festgestellten Konflikt werden im oberen Widget durch Betätigen des 

139


140 

gelben Knopfes die markierte Aufzeichnung sowie alle mit ihr in Konflikt stehenden 

aufgeführt. Durch Löschen oder Bearbeiten einzelner programmierter Aufnahmen 

kann der Konflikt aufgelöst werden. 

Durch Drücken des blauen Farbknopfes kann eine Aufnahme manuell erstellt werden, 

wobei die Zeiten entsprechend vorbelegt sind. Als Start-Zeit wird die aktuelle 

Uhrzeit plus eine Minute, als Stopp-Zeit plus zwei Minuten vorgegeben. Diese Angaben 

können nun nach Belieben verändert werden. 

Durch betätigen des grünen Farbknopfes können Änderungen an Aufnahme-Daten 

vorgenommen werden. So ist es möglich Aufnahme-Zeiten zu bearbeiten mit Hilfe 

des Zahlenblocks der Fernbedienung. Weiterhin kann durch die ’Hoch’- bzw 

’Runter’-Taste der Kanal gewechselt werden. Der gelbe Farbknopf wird zur Änderung 

der Periode eingesetzt. Wiederholtes Drücken desselben ermöglicht das 

Durchschalten der verfügbaren Perioden. Hat der Benutzer die Aufnahmeinformationen 

seinen Wünschen angepasst, können diese durch Betätigen der grünen Taste 

übernommen, durch Drücken des roten Farbknopfes verworfen werden. 


Beim Start der Multimedia-Box legt der TVTimer-Zustand den Videorekorder lokal 

an oder verbindet sich mit einem im Netzwerk verfügbaren. Dies ist in der 

Konfigurations-Datei der Multimedia-Box angegeben. Eine vollständige Liste der 

Variablen zur Konfiguration des Videorekorders ist in Anhang A aufgeführt. 

Zur Programmierung und Bearbeitung der Aufnahmen werden die GUI-Elemente 

ausgewertet und die entsprechenden Methoden auf dem ITVTimer-Interface des 

Videorekorders aufgerufen. Durch das Registrieren eines EventListeners bei dem 

ITVTimerEvents-Interface des Videorekorders wird der TVTimer-Zustand über 

Zustandsänderungen von Aufzeichnungen benachrichtigt, woraufhin die Anzeige 

aktualisiert wird. Zudem werden EventListener für Methoden des ITVTimer- 

Interfaces registriert, sodass die Anzeige erneuert wird, wenn eine andere Anwendung 

eine Aufnahme bei dem Videorekorder programmiert, ändert oder löscht. 

In Abschnitt 3.3 wurde beschrieben, dass eine Aufnahme in dem Tasklist-Zustand 

angezeigt wurde, da dies der DVBRecorder-Zustandes vornahm. Durch die in dieser 

Arbeit erfolgte Änderung am Videorekorder der Multimedia-Box werden Aufnahmen 

nicht mehr durch deren Zustand vorgenommen, weshalb laufende Aufzeichnungen 

nicht mehr im Tasklist-Zustand angezeigt werden. 

5.4.2 Der LiveTV-Zustand 

In diesem Abschnitt wird der LiveTV-Zustand um die Konzepte des Mehrbenutzer- 

TV erweitert. Die Timeshifting-Funktionalität blieb bei der Neuentwicklung erhalten. 

Der Status des LiveTV-Zustands vor dieser Arbeit wurde bereits in Abschnitt 

3.3 erläutert.


Abbildung 5.30: Im LiveTV-Zustand werden am unteren Rand die Startzeiten sowie 

die Titel der momentan laufenden und nachfolgenden Sendung angezeigt. In 

der linken oberen Ecke werden Informationen über den Kanal und die verwendete 

TV-Quelle angezeigt. In der rechten oberen Ecke ist der rote Punkt zu sehen, der 

eine momentane Aufnahme des Videorekorders signalisiert. 

Benutzeroberfläche 

Neben der Anzeige der EPG-Informationen, wie in Abschnitt 4.5.3 beschrieben, 

werden allgemeine Senderinformationen in der linken oberen Ecke eingeblendet 

(siehe Abbildung 5.30). Diese beinhalten die Kanalnummer des Senders in der 

globalen Kanalliste und den dort angegebenen Sendernamen. Weiterhin wird angezeigt, 

ob man sich gerade im Timeshifting-Modus oder im Live TV befindet. Die 

letzte Zeile enthält den Rechnernamen, dessen TV-Karte momentan als Quelle verwendet 

wird sowie den Status der Anwendung, ob sie die Quelle als Master oder 

als Slave nutzt. 

Weiterhin wird darüber informiert, ob momentan eine Aufnahme getätigt wird. 

Dies zeigt ein roter Punkt in der rechten oberen Ecke an. 

Bedienung 

Die Bedienung des LiveTV-Zustandes wurde weitestgehend von der ersten Version 

übernommen, wodurch u.a. die Kanäle einzeln durchgeschaltet werden können. 

Neu hinzugefügt wurde die Möglichkeit des Kanalwechsels durch Angabe der Kanalnummer 

des Senders in der globalen Kanalliste. Dazu wird in der Mitte des 

Bildschirms ein Fenster eingeblendet, in das man eine Nummer, bestehend aus 

bis zu vier Ziffern, eingeben kann. Drei Sekunden nach Eingabe der letzten Ziffer 

blendet sich das Fenster wieder aus und es wird der gewählte Kanal eingestellt. 

Sollte das nicht möglich sein, da alle TV-Karten, die den Kanal bereitstellen, schon 

anderweitig verwendet werden oder die eingebene Nummer größer als die Anzahl 

verfügbarer Kanäle ist, wird dies dem Benutzer durch eine entsprechende Meldung 

mitgeteilt. 

141


142 

Abbildung 5.31: Der gezeigte Teilgraph wird im LiveTV-Zustand erstellt. Die 

Quelle wird von der TVManager-Klasse ermittelt und mit diesem Teilgraphen 

verbunden. Die globalen Knoten der Multimedia-Box sind grau unterlegt. 

Außerdem wird die direkte Aufnahme des momentan eingestellten Senders durch 

Drücken des roten Farbknopfes unterstützt. Dazu wird bei vorhandenen EPG-Informationen 

die aktuelle Sendung bis zu deren Ende aufgezeichnet. Existieren 

diese nicht, läuft die Aufnahme solange, bis sie entweder von dem Anwender 

im TVTimer-Zustand manuell oder vom Videorekorder automatisch beendet wird, 

wie in Abschnitt 5.2.2.4 beschrieben. Sollten der Videorekorder und der LiveTV- 

Zustand eine TV-Karte gemeinsam verwenden, kann mittels des roten Farbknopfes 

in den TVTimer-Zustand gewechselt werden um ggf. die Aufnahme zu beenden. 


Zur Suche einer verwendbaren TV-Karte wird die Klasse TVManager verwendet. 

Zuerst wird der Flussgraph aus Knoten für das Timeshifting sowie zum Dekodieren 

bzw. Ausgeben der Audio- und Video-Daten festgelegt (siehe Abbildung 5.31). 

Beim Einstellen von Kanälen können diese sequentiell durchgeschaltet oder direkt 

gesetzt werden, was bei der Fehlerbehandlung unterschieden wird. Dies wird bei 

einem Wechsel der TV-Karte während der Kanal-Suche durch einen Hinweis angezeigt, 

wie in Abbildung 5.32 dargestellt. Sollte keine geeignete TV-Karte zur Verfügung 

stehen, wird im sequentiellen Fall solange weitergeschaltet, bis ein verfügbarer 

Kanal gefunden ist. Wurde ein Kanal gefunden, wird durch eine Meldung angezeigt, 

dass Sender übersprungen wurden. Entspricht dieser demjenigen, der den 

Ausgangspunkt der Suche darstellt, wird ebenfalls eine entsprechende Hinweismeldung 

eingeblendet. Ist es nicht möglich, über den Nummernblock der Fernbedienung 

einen Sender direkt einzustellen, erfolgt eine Fehlermeldung. Als Alternative 

wird die Suche nach dem nächsten verfügbaren Kanal angeboten. 

Der LiveTV-Zustand registriert beim Starten einen EventListener bei der TV-Quelle, 

um auf einen Kanalwechsel durch den Master zu reagieren. Dadurch wird eine Hinweismeldung 

eingeblendet die es ermöglicht, die TV-Quellen-Suche wieder anzustoßen, 

damit der aktuell eingestellte Sender weiterhin empfangen werden kann. 

Sollte dies erfolglos sein, wird der nächst empfangbare Kanal gesucht. Nach dem 

Wechsel einer TV-Quelle wird bei dieser erneut ein EventListener registriert.


Abbildung 5.32: Sollte bei einem Kanalwechsel die TV-Quelle gewechselt werden, 

wird dies durch eine entsprechende Meldung angezeigt. 

Zur Benachrichtigung der Anwendung über einen Statuswechsel auf der TV-Karte, 

wenn sie also vom Master zum Slave wird oder umgekehrt, implementiert der 

LiveTV-Zustand das IUsageNotify-Interface. Dieses übergibt er der TVManager-Klasse 

zur Registrierung bei der verwendeten TV-Quelle. 


In diesem Kapitel wurden Szenarien vorgestellt, die den Zugriff mehrerer Anwendungen 

auf mehrere TV-Karten beschreiben. Nach einer kurzen Betrachtung des 

Zugriffs eines Benutzers auf eine TV-Quelle wurde dieses Szenario um mehrere 

Quellen erweitert und zu dessen Realisierung die globale Kanalliste entwickelt, 

welche jedem Kanal die zur Verfügung stehenden TV-Karten gemäß der Präferenz 

des Benutzers zuordnet. Neben Aufbau und Erstellung wurde zudem die Datenstruktur 

erläutert, welche die Informationen der Liste speichert. 

Als erste Applikation zur Verwendung der globalen Kanalliste wurde der Videorekorder 

beschrieben, der Aufzeichnungen auf vorhandene TV-Karten verteilt und 

Konflikte zwischen verschiedenen Aufnahmen erkennt. Im Weiteren wurden die 

Möglichkeiten durch die Anbindung eines EPGs und dessen Realisierung aufgezeigt, 

wozu neben dem Anzeigen der Informationen zu einer Aufnahme die automatische 

Wiederholung von Sendungen mit vergleichbaren EPG-Daten zählt. 

In der Folge ist ein Algortihmus erarbeitet worden, der den Zugriff mehrerer Benutzer 

auf mehrere TV-Quellen steuert. Dieser ordnet den verschiedenen Anwendungen 

verfügbare TV-Karten unter Berücksichtigung der momentanen Verwendungsart 

zu. Dazu wurde eine Hierachie der Anwendungen EPG, Live TV und Videorekorder 

festgelegt, mit deren Hilfe die Kontrollmöglichkeit der Anwendungen 

auf einzelnen TV-Karten beschränkt werden können. Zur Implementierung dessen 

wurde die Klasse Usage entwickelt, mit deren Hilfe die Verwendungsart in 

NMM-Knoten gespeichert wird. Die Zuteilung einer TV-Karte wurde in der Klasse 

TVManager realisiert. 

143


144 

Das Kapitel endet mit der Integration der vorgestellten Klassen und Konzepte 

in die Multimedia-Box. Zuerst wurde der Multimedia-Box-Zustand TVTimer zur 

Steuerung des Videorekorders beschrieben. Mit ihm können Aufnahmen erstellt, 

verändert und gelöscht werden. Auch die Beschreibung der realisierten manuellen 

Konfliktauflösung wurde thematisiert. Darauf folgte die Beschreibung des 

LiveTV-Zustandes, der sowohl um die Anbindung an den realisierten EPG als auch 

um die Möglichkeit des Zugriffs auf mehrere TV-Karten erweitert wurde. Hierzu 

zählen das Erkennen eines Status-Wechsels auf der verwendeten Karte sowie 

die Ausnahme-Behandlung im Falle einer erfolglosen Suche nach einer geeigneten 

TV-Quelle. Letzteres ist durch entsprechende Fehlermeldungen und vordefinierte 

Reaktionen realisiert worden.

Kapitel 6 

Zusammenfassung und Ausblick 

In diesem Kapitel werden die erreichten Ziele zusammengefasst und ein Ausblick 

auf Erweiterungmöglichkeiten gegeben. 

6.1 Erreichte Ziele 

In der vorliegenden Diplomarbeit wurden die TV-Eigenschaften der Multimedia- 

Box erweitert. Die anvisierten Ziele bestanden in der Entwicklung einer Elektronischen 

Programmzeitschrift (EPG) und der Realisierung des Mehrbenutzer-TV, 

welche Anwendungsszenarien beschreiben, in denen der Zugriff mehrerer Anwendungen 

auf mehrere TV-Quellen automatisch geregelt wird. Zu diesem Zweck wurde 

der TVTimer- und der LiveTV-Zustand der Multimedia-Box um die Möglichkeit 

des Zugriffs auf mehrere TV-Karten erweitert. 

Als erste Erweiterung wurde der EPG vorgestellt, der mit Hilfe von externen Programmen 

Informationen aus dem Internet sammelt oder entsprechende Daten aus 

dem digitalen oder analogen Fernsehstrom ausliest. Das Einbinden dieser Werkzeuge 

wurde als Plugin-Struktur realisiert, sodass weitere Quellen dem EPG leicht 

hinzugefügt werden können. Im Rahmen dieser Arbeit sind verschiedene Plugins 

zur Verwendung der oben genannten Quellen erstellt worden. Zum einen wurden 

die XMLTV-Tools integriert, welche ihre Informationen bei speziellen Diensten 

im Internet abfragen, zum anderen wurde nxtvepg eingebunden, welches Daten 

über die Austastlücke des Videotextes erhält. Schließlich wurde ein Plugin entwickelt, 

das EPG-Informationen aus dem DVB-Datenstrom extrahiert, wozu der 

DVBReadNode von NMM um die entsprechende Funktionalität erweitert wurde. 

Alle auf diese Weise gesammelten Daten werden auf der Festplatte abgelegt, damit 

sie beim Beenden der Anwendung nicht verloren gehen. Dazu werden sie in 

einer Verzeichnisstruktur mit XML-Daten gespeichert um einen schnellen Zugriff 

auf Informationen zu ermöglichen ohne den gesamten Datenbestand durchsuchen 

zu müssen. Die Verzeichnisse sind so aufgebaut, dass zu jedem Kanal ein eigenes 

Unterverzeichnis existiert, in welchem die EPG-Informationen in separaten Datei- 

145

KAPITEL 6. Zusammenfassung und Ausblick 

146 

en enthalten sind. Für jeden Tag wird eine eigene Datei mit den entsprechenden 

XML-Daten erstellt. Weiterhin wird im EPG-Verzeichnis eine Datei angelegt, die 

einen XML-Baum mit Kanal-Informationen enthält, was einen schnellen Zugriff 

auf diese Informationen ermöglicht. 

Eine Eigenschaft des EPG ist das in Abschnitt 4.2 vorgestellte gleichzeitige Sammeln 

von Informationen von unterschiedlichen Quellen. Zu diesem Zweck werden 

den Quellen Prioritäten zugewiesen, wodurch es möglich ist Daten von höher priorisierten 

Quellen zu bevorzugen. Dazu wird festgestellt, ob sich vorhandene Daten 

mit neuen überschneiden und diese ggf. ersetzt oder ergänzt. 

Zum Zugriff auf die gesammelten Informationen werden verschiedene Methoden 

unterstützt, womit Daten nach bestimmten Kriterien abgefragt werden können. 

Diese reichen von der Abfrage einer einzelnen bis zum Durchsuchen des gesamten 

Datensatzes nach mehreren Informationen. 

Außerdem wurde der EPG um eine Peer-to-Peer-Funktion erweitert, welche das 

Weiterleiten einer Anfrage an im Netzwerk verteilte EPGs erlaubt. Dadurch kann 

das Sammeln von EPG-Informationen auf verschiedene Rechner verteilt werden. 

Bei lokal nicht vorhandenen oder unvollständigen Informationen werden die verteilt 

laufenden EPGs abgefragt, ob sie die gewünschten Daten bereitstellen. 

Zur Bedienung des EPG wurde die Multimedia-Box um den TVGuide- und den 

Search-Zustand ergänzt. Der TVGuide-Zustand dient dem Blättern in den EPG- 

Informationen. Hier können das Tagesprogramm der Sender und Informationen zu 

einzelnen Sendungen eingesehen werden. Der Search-Zustand dient dem Durchsuchen 

der Datenbestände des EPG. Hier können verschiedene Suchkriterien definiert 

werden wie das Einschränken der Suche z.B. auf bestimmte Kanäle oder 

Schlagworte. Anschließend werden die gefundenen Daten entsprechend aufbereitet 

und angezeigt. 

Die zweite Erweiterung betrifft den Videorekorder und die Live TV-Funktionalität 

der Multimedia-Box. Im Rahmen dieser Diplomarbeit wurde die Einschränkung 

des Zugriffs auf nur eine TV-Karte aufgehoben. Dazu ist die globale Kanalliste 

eingeführt worden die angibt, über welche Quellen der jeweilige Kanal empfangen 

werden kann. Diese Karten können lokal oder im Netzwerk verteilt sein. Weiterhin 

wurde berücksichtigt, dass jede der oben genannten Anwendungen diese Quellen 

nutzen kann, so auch der EPG zum Sammeln von Daten. Zu diesem Zweck 

wurden die NMM-Knoten um die Speichermöglichkeit eines Verwendungszwecks 

erweitert. Mit diesen Informationen kann nun festgelegt werden, welche Berechtigung 

einer Anwendung auf dem entsprechenden Knoten eingeräumt wird. Zur 

Realisierung wurde die Hierarchie der Prioritäten so aufgebaut, dass zunächst dem 

Videorekorder die höchste Priorität zukommt, gefolgt von Live TV und schließlich 

dem EPG. Des Weiteren wurde auf das von NMM bereitgestellte Session-Sharing 

zurückgegriffen, sodass eine große Auswahl an Kanälen zur Verfügung steht. Dadurch 

ist es möglich, dass mehrere Anwendungen eine TV-Quelle gemeinsam nutzen. 

Dies erforderte die Einführung des Konzepts des Master- und Slave-Zugriffs 

auf TV-Karten, sodass festgestellt werden kann, welche Anwendung kontrollierend 

auf eine Karte zugreifen darf. Auf dieser Basis wurde ein Algorithmus entwickelt,

6.2. ERWEITERUNGSMÖGLICHKEITEN 

der automatisch verwendbare TV-Karten ermittelt und diese der Anwendung zur 

gewünschten Verwendungsabsicht zuteilt. 

Schließlich wurde der Videorekorder um eine Konflikterkennung erweitert, welche 

die Zuordnung von TV-Quellen zu Aufnahmen realisiert, indem sie überlappende 

Aufzeichnungen feststellt und ihnen freie TV-Karten zuteilt. Dabei wird erfragt, ob 

überlappende Aufnahmen für den gleichen Kanal programmiert werden sollen. In 

diesem Fall kann mittels des in NMM vorhandenen Session-Sharing-Dienstes die 

gleiche TV-Ressource verwendet werden. Weiterhin unterstützt der Videorekorder 

den Zugriff auf einen EPG, was die Abfrage von Informationen zu der Aufzeichnung 

einer Sendung ermöglicht. Darüberhinaus können Aufnahmen auf Basis vergleichbarer 

EPG-Informationen automatisch wiederholt und auf einen bestimmten 

Kanal bzw. eine Sendezeit eingeschränkt werden. Neben diesen EPG-Perioden stehen 

auch zeitenbasierte Modi, wie z.B. eine tägliche oder wöchentliche Aufnahme, 

zur Verfügung. 

Die Bedienung des Videorekorders wurde durch die Überarbeitung des TVTimer- 

Zustandes realisiert. Über diesen ist es möglich neue Aufzeichnungen zu programmieren 

und Daten zu bereits einprogrammierten Aufnahmen zu verändern oder diese 

zu löschen. Des Weiteren wurde eine manuelle Konflikt-Auflösung implementiert, 

durch die alle zu einer bestimmten in Konflikt stehenden Aufnahme kompakt 

angezeigt werden um so bei Bedarf entsprechende Einträge zu löschen. 

Für die Anwendung der genannten Vorgehensweisen beim Fernsehen wurde der 

LiveTV-Zustand der Multimedia-Box überarbeitet. Dieser verwendet den entwickelten 

Algorithmus zur Bestimmung einer verwendbaren TV-Karte. Gleichfalls wird 

geprüft, ob der Benutzer zu einem Kanalwechsel berechtigt ist oder für den nächsten 

Kanal eine neue TV-Karte zugewiesen werden muss. Weiterhin wurde der 

LiveTV-Zustand um den Zugriff auf den EPG erweitert, damit vorhandene Informationen 

eingeblendet werden können. 

6.2 Erweiterungsmöglichkeiten 

Im folgenden Abschnitt werden Erweiterungsmöglichkeiten dieser Arbeit aufgeführt. 

Neben einer Beschreibung der Funktionalität werden zusätzlich Möglichkeiten 

zur Realisierung aufgezeigt. 

6.2.1 EPG-Plugins 

Neben den in dieser Arbeit realisierten EPG-Plugins existieren noch weitere Quellen 

für EPG-Informationen. Ein anderer Lieferant solcher Daten ist z.B. der kostenpflichtige 

Dienst von tvtv.de [tvtb], welcher über ein eigenes Programm Daten 

im XMLTV-Format bereitstellt. Außerdem wäre das Abrufen der Informationen 

bei entsprechenden Service-Providern denkbar, wie es die Windows Media Center 

Edition durchführt. 

147


148 

Um diese Quellen zu nutzen müssen analog zu den bereits vorhandenen weitere 

Plugins geschrieben werden, die diese Daten sammeln und dem EPG zur Verwaltung 

übergeben, damit er sie verwalten kann. Änderungen an der Implementierung 

des EPG sind durch die realisierte Plugin-Struktur nicht nötig. 

6.2.2 Benachrichtigung über eintreffende EPG-Informationen 

Der in dieser Arbeit realisierte EPG kann eine graphische Benutzeroberfläche lediglich 

darüber benachrichtigen, dass neue Informationen hinzugefügt wurden. 

Über den Inhalt dieser Daten ist dabei nichts in Erfahrung zu bringen. Es wäre möglich 

den EPG um einen Benachrichtigungs-Dienst zu erweitern. Der Benutzer kann 

sich so über neue Daten informieren lassen, die z.B. ein festgelegtes Schlagwort 

enthalten. Eine weitere Option wäre die Benachrichtigung des Videorekorders über 

Änderungen in der Programmabfolge eines Senders und die daraus resultierende 

notwendige Anpassung der Startzeit einer geplanten Aufnahme. Außerdem könnte 

der Videorekorder so über neue Daten zu vorgesehenen RANDOM-Perioden informiert 

werden anstatt nach jeder getätigten Aufnahme eine erneute Suchanfrage 

an den EPG zu stellen, wie in Abschnitt 5.2.2.5 beschrieben. 

Zur Realisierung müsste eine Klasse implementiert werden, bei der entsprechende 

Suchmasken registriert werden können und die entsprechende Anwendung über 

eventuelle Treffer informiert. Diese Klasse hat die Aufgabe nach erfolgreichem 

Hinzufügen der Daten in der insertEvent()-Methode der TVGuide-Klasse 

zu prüfen, ob die angegeben Filterkriterien zutreffend sind. Die zu informierende 

Anwendung implementiert ein entsprechendes Interface, das sie bei dem Objekt 

registriert und mit dessen Hilfe sie benachrichtigt wird. Dabei können die neuen 

Daten schon übertragen werden, sodass ein erneutes Abfragen des EPG nicht notwendig 

ist. 

6.2.3 Zusammenschluß mehrerer Videorekorder 

Der in dieser Arbeit entwickelte Videorekorder ist als zentraler Server realisiert, damit 

Konflikte zwischen Aufnahmen leicht erkannt und aufgelöst werden können. 

Als weiterer Schritt wäre das Management mehrerer Videorekorder auf verschiedenen 

Rechnern denkbar. Dazu müsste ein Algorithmus implementiert werden, 

der das Einprogrammieren von Aufnahmen auf die verschiedenen Videorekorder 

verteilt. Weiterhin müsste eine Kommunikation zwischen den Videorekordern 

realisiert werden. Dadurch sollen Aufnahmen, die auf Grund nicht mehr erreichbarer 

TV-Karten oder wegen Konflikten bei einer automatischen Wiederholung fehlschlagen, 

auf die restlichen Videorekorder verteilt werden. 

Es könnte versucht werden zur Erstellung einer Aufnahme bei allen zur Verfügung 

stehenden Videorekordern diese zu programmieren. Dazu müssten die Videorekorer 

sequentiell angesprochen werden, bis die Aufzeichnung erfolgreich programmiert 

ist oder alle Videorekorder einen Konflikt meldeten. Dabei sollte jedoch garantiert 

sein, dass zur Vermeidung von Konflikten nicht zwei Videorekorder auf die

gleiche TV-Karte zugreifen. 

6.2.4 Master-Slave-Konzept auf Middleware-Ebene 

6.2. ERWEITERUNGSMÖGLICHKEITEN 

Das in dieser Arbeit entwickelte Master-Slave-Konzept zur Einschränkung der Zugriffsmöglichkeiten 

auf eine TV-Karte wurde auf Anwendungs-Ebene realisiert. 

Dies bedeutet, dass jede Applikation vor einem Kanalwechsel prüfen muss, ob sie 

dazu berechtigt ist. 

Denkbar wäre auch eine Realisierung dieses Konzeptes in der Basis-Schicht von 

NMM. Dies würde bedeuten, dass ein Knoten automatisch erkennt, welche empfangenen 

Events er zulassen darf und welche er verwerfen muss. Wichtig dabei ist, 

dass der Knoten nicht blind alle Events verwirft, sobald er Slave ist, sondern unterscheiden 

kann, welche Events einer speziellen Prüfung bedürfen. Andernfalls wäre 

es nicht möglich die Verwendbarkeit des Knotens zu prüfen, da alle Methoden zum 

Abfragen von Informationen nicht ausgeführt werden können. 

Eine mögliche Realsierung wäre das Blockieren aller Methoden eines oder mehrerer, 

festgelegter Interfaces im Slave-Fall um eine Ausführung zu verhindern. Ein 

Knoten enthält eine Liste von Interface-Namen und prüft jede Methode, ob sie 

von einem Interface aus dieser Liste stammt. Ist dieses Interface enthalten, wird 

die Methode nicht ausgeführt. Dazu müssten bisherige Interfaces, die Methoden 

zum Setzen und Abfragen von Informationen besitzen, aufgeteilt werden, sodass 

Methoden zum Setzen blockiert und solche zum Abfragen erlaubt werden können. 

Die zweite Möglichkeit wäre ein Test des Methoden-Namens, der über ein Interface 

aufgerufen wird. Ein Knoten kann einen oder mehrere Reguläre Ausdrücke 

enthalten, mit deren Hilfe geprüft wird, ob eine Methode ausgeführt werden darf. 

Dazu müsste ggf. eine Namenskonvention für Methodennamen aufgestellt werden, 

die strikt einzuhalten ist. 

Zur Prüfung, welche Methode aufgerufen wurde und zu welchem Interface sie gehört, 

könnte ein entsprechender Test in das Event-System von NMM integriert werden. 

An dieser Stelle liegen die Methoden- und zugehörigen Interface-Namen als 

Zeichenkette vor, was einen Test mit Hilfe von Regulären Ausdrücken ermöglicht. 

149


150

Anhang A 

Neue Konfigurations-Variablen in 

der Multimedia-Box 

Im Folgenden werden alle Variablen aufgelistet, mit deren Hilfe der EPG, der Videorekorder 

und LiveTV in der Multimedia-Box konfiguriert werden können. Diese 

sind in der Konfigurations-Datei der Multimedia-Box anzugeben. Dies ist die 

Datei .mmboxrc, welche im $HOME-Verzeichnis des Benutzers abgelegt ist. Sie 

wird erstellt durch Kopieren, Editieren und anschließendes Umbenennen der Datei 

mmboxrc_sample aus dem resources-Verzeichnis von NMM [NMM]. 

Weitere Informationen können aus [Wel05] entnommen werden. 

A.1 Konfiguration des EPG 

• Angabe der Anzahl der zu verwendenden EPG-Quellen: 

epgsources_number=0 

• Die Variablen zur Angabe der EPG-Quellen sind durchnummeriert von 0 bis 

epgsources_number-1. Mögliche Werte sind: 

DVB epgsource_x=dvb 

xmltv epgsource_x=xmltv 

nxtvepg epgsource_x=nxtvepg 

• Hier kann angegeben werden, wenn zu einem entfernten EPG eine Verbindung 

hergestellt werden aoll um auf dessen Daten zuzugreifen. Es werden 

keine Daten lokal gespeichert: 

epglocation=: 

• Zur Konfiguration der Peer-to-Peer-Funktionalität des EPG muss zuerst die 

Anzahl der zu verwendenden Rechner angegeben werden: 

epgpeers_number=0 

151

ANHANG A. Neue Konfigurations-Variablen in der Multimedia-Box 

152 

Anschließend werden die Adressen der Rechner spezifiziert: 

epgpeer_0=: 

epgpeer_1=: 

• Zur Konfiguration des XMLTV-Plugins muss festgelegt werden, für welches 

Land Informationen gesammelt werden sollen. Dies legt gleichzeitig das zu 

verwendende externe Programm fest: 

xmltv_locale=de 

Zudem kann festgelegt werden, in welchem Intervall ein erneutes Sammeln 

ausgeführt werden soll. Dies wird durch den Zeitabstand der Wiederholungen 

(m = minütlich, h = stündlich, d = täglich) und einem Multiplikator für 

den Zeitabstand angegeben. So bedeutet die Angabe von ’d3’ z.B. ’alle drei 

Tage’: 

xmltv_period=d3 

• Zur Verwendung des Nxtvepg-Plugins muss diesem der Provider mitgeteilt 

werden, der Informationen bereitstellt. Dies geschieht durch Angabe des entsprechenden 

Hexadezimal-Wertes: 

nxtvepg_provider=0d92 

Des Weiteren muss der Pfad angegeben werden, unter dem nxtvepg die 

gesammelten Daten ablegt: 

nxtvepg_dbdir= 

Zudem kann festgelegt werden, in welchem Intervall ein erneutes Sammeln 

ausgeführt werden soll: 

nxtvepg_period=d3 

• Das DVBEPG-Plugin verwendet zur Feststellung der verfügbaren Kanäle 

die globale Kanalliste, die in Abschnitt 5.2.1 vorgestellt wurde. Hier kann 

eine alternative Kanalliste zur Festlegung von TV-Karten angegeben werden, 

die ausschließlich für den EPG verwendet werden sollen: 

dvbepgChannelFile= 

/home//.nmm/tv_channels_dvbepg.xml 

Sie wird durch Verwendung des channelReader durch folgenden Aufruf 

erstellt: 

channelReader \ 

-f /home//.nmm/tv\_channels\_dvbepg.xml 

A.2 Konfiguration des Videorekorders 

• Die folgende Variable dient der Angabe des Verzeichnisses, in welchem die 

Aufnahmen gespeichert werden sollen, ausgehend von dem Pfad, der in der 

rootpath-Variable der .mmboxrc festgelegt wurde:

tvdestinationdirectory=TV-Recordings 

A.3. KONFIGURATION VON LIVE TV 

• Soll eine Verbindung zu einem Videorekorder hergestellt werden, der im 

Netzwerk als zentraler Server (siehe Abschnitt 5.2.2) verfügbar ist, kann dies 

hier angegeben werden: 

tvtimerlocation=: 

• Der Videorekorder verwendet die globale Kanalliste zur Bestimmung der 

verfügbaren Kanäle. Soll eine alternative Kanalliste verwendet werden um 

TV-Karten festzulegen, die ausschließlich vom Videorekorder verwendet werden 

sollen, kann diese hier spezifiziert werden. Diese Variable wird nur berücksichtigt, 

wenn der Videorekoder lokal in der Multimedia-Box läuft. 

recorderChannelFile= 

/home//.nmm/tv_channels_rec.xml 


erstellt: 


-f /home//.nmm/tv\_channels\_rec.xml 

• Die folgende Variable legt fest, ob in der GUI des TVTimer-Zustandes einprogrammierte 

Aufnahmen angezeigt werden sollen: 

displaySleeping=1 

• Die folgende Variable legt fest, ob in der GUI des TVTimer-Zustandes laufende 

Aufnahmen angezeigt werden sollen: 

displayRecording=1 

• Die folgende Variable legt fest, ob in der GUI des TVTimer-Zustandes aufgezeichnete 

Sendungen angezeigt werden sollen: 

displayRecorded=1 

A.3 Konfiguration von Live TV 

Die folgenden Variablen legen die zu verwendenden TV-Quellen fest. Sie werden 

von dem Tool channelReader ausgewertet, das, basierend auf diesen Informationen, 

die globale Kanalliste erstellt. 

• Angabe der Anzahl der zu verwendenden TV-Quellen: 

tvhosts_number=0 

153

ANHANG A. Neue Konfigurations-Variablen in der Multimedia-Box 

154 

• Anschließend werden die einzelnen TV-Quellen durch Angabe der GraphURL 

festgelegt. Diese sind von 0 bis tvhosts_number-1 durchnummeriert. 

Angabe einer DVB-Karte: 

tvhost_x=dvbtv:///?=... 

Angabe einer IVTV-Karte: 

tvhost_x=ivtv:///?=... 

• Der LiveTV-Zustand greift zur Feststellung verfügbarer Kanäle auf die globale 

Kanalliste zu. Soll eine alternative Kanalliste verwendet werden um 

TV-Karten festzulegen, die ausschließlich von Live TV verwendet werden 

sollen, kann diese hier angegeben werden: 

tvChannelFile=/home//.nmm/tv_channels_live.xml 


erstellt: 


-f /home//.nmm/tv\_channels\_live.xml

Anhang B 

Konfigurations-Dateien 

Hier wird ein Überblick über die in dieser Arbeit vorgestellten Konfigurations- 

Dateien gegeben. Dies beinhaltet die Default-Konfigurations-Dateien der EPG- 

Plugins, die Datei zur Angabe von Aliasen für Sendernamen und die globale Kanalliste. 

Alle diese Dateien dürfen vom Benutzer editiert werden. 

B.1 Default-Konfigurations-Dateien für EPG-Plugins 

Die Default-Konfigurations-Dateien der EPG-Plugins befinden sich in dem Verzeichnis 

resources von NMM im Unterverzeichnis tvguide. 

Die Datei XMLTVPlugin.conf enthält Default-Konfigurationen für das XML- 

TV-Plugin des EPG. 

 

 

 

 

tv_grab_de_tvtoday 

tv_grab_fi 

 

Die Datei NxtvepgPlugin.conf enhält Default-Konfigurationen für das Nxtvepg-Plugin 

des EPG. 

 

 

 

 

 

 

 

155

ANHANG B. Konfigurations-Dateien 

156 

B.2 Datei zur Angabe von Aliasen für Sendernamen 

Die Datei channelAliases.xml befindet sich im resources-Verzeichnis 

von NMM im Unterverzeichnis tvguide und enthält Aliase für Sendernamen. 

 

 

Pro 7 

PRO 7 

Pro sieben 

Pro-7 

 

 

KiKa 

KinderKanal 

 

 

HESSEN 

Hessen-3 

 

... 

 

B.3 Videorekorder und Live TV 

Zur Feststellung der verwendbaren TV-Kanäle greifen der Videorekorder und Live 

TV auf die globale Kanalliste zu, die in dem $HOME-Verzeichnis des Benutzers im 

Unterverzeichnis .nmm standardmäßig unter dem Namen tv_channels.xml 

gespeichert wird. Sie wird von dem Programm channelReader durch Auswerten 

der in der Datei .mmboxrc festgelegten TV-Quellen erstellt. 

 

 


\ 

ivtv://host?freqtable=pal-europe&input=4\ 

 

 

 


\ 

ivtv://host?freqtable=pal-europe&input=4\ 

 

 

 


 

... 

Abbildungsverzeichnis 

2.1 Videotext von ARD . . . . . . . . . . . . . . . . . . . . . . . . . 11 

2.2 Der TV Guide des Grundig Sydney SE7240 . . . . . . . . . . . . 11 

2.3 InterVideo MSIPVS . . . . . . . . . . . . . . . . . . . . . . . . . 12 

2.4 Konfliktauflösung der MS MCE . . . . . . . . . . . . . . . . . . 13 

2.5 Der EPG der Microsoft Windows Media Center Edition . . . . . . 14 

2.6 Videorekorder GUI bei MS MCE . . . . . . . . . . . . . . . . . . 14 

2.7 Der EPG von SageTV2 . . . . . . . . . . . . . . . . . . . . . . . 15 

2.8 xawtv mit nxtvepg . . . . . . . . . . . . . . . . . . . . . . . . . 17 

2.9 Hauptmenu von WebVCR+ . . . . . . . . . . . . . . . . . . . . . 18 

2.10 Der EPG während Live TV bei VDR . . . . . . . . . . . . . . . . 19 

2.11 Der EPG von VDR . . . . . . . . . . . . . . . . . . . . . . . . . 20 

2.12 Der Videorekorder von VDR . . . . . . . . . . . . . . . . . . . . 20 

2.13 Der EPG von freevo . . . . . . . . . . . . . . . . . . . . . . . . . 22 

2.14 MythTV - EPG und Live TV . . . . . . . . . . . . . . . . . . . . 23 

2.15 Konfliktauflösung bei MythTV . . . . . . . . . . . . . . . . . . . 23 

3.1 Verteilter Flussgraph . . . . . . . . . . . . . . . . . . . . . . . . 29 

3.2 Verteilter Flussgraph . . . . . . . . . . . . . . . . . . . . . . . . 30 

3.3 NMM Session-Sharing . . . . . . . . . . . . . . . . . . . . . . . 33 

3.4 Die Multimedia-Box . . . . . . . . . . . . . . . . . . . . . . . . 34 

3.5 Architektur der MMBox-Anwendung . . . . . . . . . . . . . . . 36 

3.6 MMBox-Anwendung mit mehreren aktiven Zuständen . . . . . . 37 

4.1 Zentraler EPG im Netzwerk . . . . . . . . . . . . . . . . . . . . 40 

4.2 Verteilter EPG im Netzwerk . . . . . . . . . . . . . . . . . . . . 42 

4.3 Die Klasse TVGuide . . . . . . . . . . . . . . . . . . . . . . . . 43 

4.4 Zusammenhang der Klassen des EPG . . . . . . . . . . . . . . . 44 

4.5 Die Klasse TVGuidePluginManager . . . . . . . . . . . . . 46 

4.6 Laden eines TVGuidePlugins und Anfordern eines Interface . . . 47 

4.7 Die Klasse TVGuidePlugin . . . . . . . . . . . . . . . . . . . 47 

4.8 Die Zustände eines TVGuidePlugins . . . . . . . . . . . . . . 48 

4.9 Die Klasse ChannelDescription . . . . . . . . . . . . . . . 50 

4.10 Die Klasse ProgramDescription . . . . . . . . . . . . . . . 51 

4.11 Die Klasse LocalTime . . . . . . . . . . . . . . . . . . . . . . 52 

4.12 Die Klasse XMLTVPlugin . . . . . . . . . . . . . . . . . . . . 54 

4.13 Die Klasse Fork . . . . . . . . . . . . . . . . . . . . . . . . . . 56 

4.14 Die Klasse NxtvepgPlugin . . . . . . . . . . . . . . . . . . . 62 

4.15 Die Klasse DVBEPGPlugin . . . . . . . . . . . . . . . . . . . . 63 

4.16 Graph zum Sammeln von EPG-Informationen von DVB . . . . . 63 

157

ABBILDUNGSVERZEICHNIS 

158 

4.17 Die Klasse DVBReadNodeTVGuideManager . . . . . . . . . 64 

4.18 Vergleich libxml2 - Xerces-c . . . . . . . . . . . . . . . . . . . . 66 

4.19 Die Klasse TVGuideDataManagement . . . . . . . . . . . . 67 

4.20 Die Verzeichnisstruktur des EPG . . . . . . . . . . . . . . . . . . 67 

4.21 Abfragen von EPG-Informationen . . . . . . . . . . . . . . . . . 72 

4.22 Die Klasse ProgramFilter . . . . . . . . . . . . . . . . . . . 73 

4.23 Ein Peer-to-Peer-Szenario des EPG . . . . . . . . . . . . . . . . . 76 

4.24 Eine Lücke in EPG-Daten . . . . . . . . . . . . . . . . . . . . . 77 

4.25 Schleife im Peer-to-Peer-Szenario des EPG . . . . . . . . . . . . 78 

4.26 Die Klasse TVGuidePeerConnector . . . . . . . . . . . . . 79 

4.27 Stellen einer verteilten Anfrage . . . . . . . . . . . . . . . . . . . 80 

4.28 Die Klassendiagramme der Handler-Klassen des EPG . . . . . . . 81 

4.29 Die Klasse TVGuidePeerHandlerFactory . . . . . . . . . 82 

4.30 Anfragen eines Handlers bei der Factory . . . . . . . . . . . . . . 83 

4.31 Interfaces zur Peer-to-Peer-Funktionalität . . . . . . . . . . . . . 83 

4.32 Verteilung einer Anfrage im Netzwerk . . . . . . . . . . . . . . . 84 

4.33 GUI des TVGuide-Zustandes . . . . . . . . . . . . . . . . . . . . 86 

4.34 Anzeige von Aufnamhen im TVGuide-Zustand . . . . . . . . . . 87 

4.35 Die Klasse TableUnit . . . . . . . . . . . . . . . . . . . . . . 88 

4.36 GUI des Search-Zustandes . . . . . . . . . . . . . . . . . . . . . 91 

4.37 Ergebnisanzeige des Search-Zustandes . . . . . . . . . . . . . . . 92 

4.38 Die Klasse TextInput . . . . . . . . . . . . . . . . . . . . . . 93 

4.39 GUI des LiveTV-Zustandes . . . . . . . . . . . . . . . . . . . . . 95 

4.40 Übersicht aller aktuell laufenden Sendungen . . . . . . . . . . . . 96 

5.1 Szenario Mehrbenutzer-TV . . . . . . . . . . . . . . . . . . . . . 100 

5.2 Zugriff einer Anwendung auf mehrere TV-Karten . . . . . . . . . 102 

5.3 Die Klassen TVChannel und TVChannelList . . . . . . . . 103 

5.4 Das Interface IChannelInfo . . . . . . . . . . . . . . . . . . 106 

5.5 Videorekorder im Netzwerk . . . . . . . . . . . . . . . . . . . . 107 

5.6 Die Klassen des Videorekorder . . . . . . . . . . . . . . . . . . . 108 

5.7 Die Klasse TVTimerControl . . . . . . . . . . . . . . . . . . 109 

5.8 Die Klasse TVTimerEntry . . . . . . . . . . . . . . . . . . . . 110 

5.9 Zustände der Klasse TVTimerEntry . . . . . . . . . . . . . . . 111 

5.10 Die Klasse TVTimerList . . . . . . . . . . . . . . . . . . . . 113 

5.11 Programmieren einer Aufnahme . . . . . . . . . . . . . . . . . . 114 

5.12 Die Klasse TVTimerScheduler . . . . . . . . . . . . . . . . 114 

5.13 Die Klasse TVTimerConflictChecker . . . . . . . . . . . . 115 

5.14 Konflikte zwischen Aufnahmen . . . . . . . . . . . . . . . . . . . 116 

5.15 Die Klasse TVRecorderManager . . . . . . . . . . . . . . . . 117 

5.16 Starten einer Aufnahme . . . . . . . . . . . . . . . . . . . . . . . 118 

5.17 Die Klasse TVRecorder . . . . . . . . . . . . . . . . . . . . . 118 

5.18 Flussgraph zur Aufnahme einer Sendung . . . . . . . . . . . . . . 119 

5.19 Reaktion des Videorekorders bei nicht-vorhandener TV-Karte . . . 120 

5.20 Löschen einer Aufnahme . . . . . . . . . . . . . . . . . . . . . . 122 

5.21 Zusammenspiel Live TV - EPG . . . . . . . . . . . . . . . . . . . 125 

5.22 Zusammenspiel Live TV - Live TV . . . . . . . . . . . . . . . . . 126 

5.23 Zusammenspiel LiveTV - Videorekorder . . . . . . . . . . . . . . 127


5.24 Zugriff mehrerer Anwendung auf mehrere TV-Karten . . . . . . . 128 

5.25 Die Usage-Klasse . . . . . . . . . . . . . . . . . . . . . . . . . 131 

5.26 Die Klasse TVManager . . . . . . . . . . . . . . . . . . . . . . 134 

5.27 Bestimmen einer verwendbaren TV-Karte . . . . . . . . . . . . . 135 

5.28 GUI des TVTimer-Zustandes . . . . . . . . . . . . . . . . . . . . 138 

5.29 Aufnahme-Wiederholungen basierend auf EPG-Informationen . . 139 

5.30 GUI des LiveTV-Zustandes . . . . . . . . . . . . . . . . . . . . . 141 

5.31 LiveTV-Graph der MMBox . . . . . . . . . . . . . . . . . . . . . 142 

5.32 Meldung über Kartenwechsel . . . . . . . . . . . . . . . . . . . . 143 

159


160

Literaturverzeichnis 

[Apa] Apache XML Project. Xerces-C++. http://xml.apache.org/xerces-c. 

[ASTa] SES ASTRA. Empfang von ASTRA - Digitale Satellitenprogramme 

von ASTRA. http://www.ses-astra.com/market/deutschland/ 

receiving/digital. 

[ASTb] SES ASTRA. Homepage. http://www.ses-astra.com. 

[Avo] Bram Avontuur. vcr - A video capture program for Linux. 

http://www.stack.nl/~brama/vcr. 

[BBE + 00] H. Baldus, M. Baumeister, H. Eggenhuisen, A. Montvay, and W. Stut. 

WWICE - An architecture for In-Home Digital Networks. In 

Proceedings of Multimedia Computing and Networking (MMCN), 2000. 

[BCE + 02] Patrick Becker, Patrick Cernko, Wolfgang Enderlein, Marc Klein, and 

Markus Sand. The Multimedia-Box - Design and Development of a 

Multimedia Home Entertainment System for Linux, 2002. 

Fortgeschrittenen Praktikum, Universität des Saarlandes. 

[Ber72] Lexikon-Institut Bertelsmann, editor. Das moderne Lexikon. 

Verlagsgruppe Bertelsmann GmbH/Bertelsmann Lexikon-Verlag, 1972. 

Band 9. 

[Bon03] Sabina Bonnici. A Design Model for Electronic Programme Guides. In 

Proceedings of the 1st European Conference on Interactive Television: 

from Viewers to Actors?, pages 49–57, 2003. 

[Bou] Ronald Bourret. XML and Databases. 

http://www.rpbourret.com/xml/XMLAndDatabases.htm. 

[Cla99] James Clark. XSL Transformations (XSLT), 1999. 

http://www.w3.org/TR/xslt. 

[Cli01] Clip2. The Gnutella Protocol Specification v0.4, März 2001. 

[Deu] Deutsche TV-Plattform e.V. Das ÜberallFernsehen. 

http://www.ueberall-tv.de/. 

[Did02] Stephan Didas. Synchronization in the Network-Integrated Multimedia 

Middleware (NMM), 2002. Fortgeschrittenen Praktikum, Universität 

des Saarlandes. 

161

LITERATURVERZEICHNIS 

162 

[ETS97a] ETSI. A guideline for the use of DVB specifications and standards. 

Technical report, European Telecommunication Standards Institute, 

1997. 

[ETS97b] ETSI. Electronic Programme Guide (EPG); Protocol for a TV Guide 

using electronic data transmission, 1997. 

[ETS97c] ETSI. Enhanced Teletext specification, 1997. 

[ETS03] ETSI. Digital Video Broadcasting (DVB): Multimedia Home Platform 

(MHP) Specification 1.1.1, 2003. 

[ETS04a] ETSI. Digital Video Broadcasting (DVB); Guidelines of 

implementation and usage of Service Information (SI), 2004. 

[ETS04b] ETSI. Digital Video Broadcasting (DVB); Specification for Service 

Information (SI) in DVB Systems, 2004. 

[Fre] Frey Technologies LCC. SageTV. http://www.sage.tv. 

[fRG99] Institut für Rundfunktechnik GmbH. CustomTV, 1999. 

http://www.irt.de/customtv/. 

[Fri03] Jeffrey E. F. Friedl. Reguläre Ausdrücke. O’Reilly, 2003. 

[GHJV95] Erich Gamma, Richard Helm, Raplh E. Johnson, and John Vlissides. 

Design Patterns : elements of reusable object-oriented software. 

Addison-Wesley, 1995. 

[Hal97] Brian Hall. Beej’s Guide to Unix Interprocess Communication, 1997. 

http://www.ecst.csuchico.edu/~beej/guide/ipc/. 

[Har02] Ian Harries. Distributed Video Recorder and Player, 2002. 

http://www.doc.ic.ac.uk/~ih/teaching/dvcr/. 

[Hau] Hauppauge Computer Works. WinTV-PVR-350. 

http://www.hauppauge.com/pages/products/data_pvr350.html. 

[Ins] European Telecommunication Standards Institute. Homepage. 

http://www.etsi.org. 

[ISO04] ISO/IEC. MPEG-2, Offizieller Titel: 13818-1 bis 11: Information 

Technology – Generic coding of movingpictures and associated audio 

information – Part 1 to 11, 1994 bis 2004. 

[ITW] ITWissen.info. Bibliothek - Definition: ITWissen.info - IT Lexikon. 

http://www.itwissen.info/?ano=01-005774&id=31. 

[Kaba] Kabel Deutschland. Homepage. 

http://www.kabeldeutschland.de/index.php. 

[Kabb] Kabel Deutschland. Service. http://www.kabeldeutschland.de/service/ 

haeufiggestelltefragen/kabelanschluss.html.

[Kle03] Marc Klein. Design and Development of a Multimedia 

Home-Entertainment System, 2003. Diplomarbeit, Universität des 

Saarlandes. 

[Knoa] Gerd Knorr. bttv. http://www.bytesex.org/v4l2/bttv.html. 

[Knob] Gerd Knorr. xawtv. http://www.bytesex.org/xawtv. 

[Koo] Andreas Kool. vdr-analogTV. 

http://www.akool.homepage.t-online.de/analogtv/index.html. 

[Lag] Krister Lagerström. Freevo. http:://freevo.sourceforge.net. 

[Lev] Chuck Lever. Linux NFS faq. http://nfs.sourceforge.net/. 

[lib] libXML2. libXML2 - The XML C parser and toolkit of Gnome. 

http://www.xmlsoft.org/. 

[LLC02] McObject LLC. Data Management in Set-Top Box Electronic 

Programming Guides, 2002. 

[Loh03] Marco Lohse. The NMM Interface Definition Language, April 2003. 

http://www.networkmultimedia.org/Docs/. 

[Loh05] Marco Lohse. Network-Integrated Multimedia Middleware, Services, 

and Applications. PhD thesis, Lehrstuhl für Computergrafik, 

Universtität des Saarlandes, Juni 2005. 


[LRS02] Marco Lohse, Michael Repplinger, and Philipp Slusallek. An Open 

Middleware Architecture for Network-Integrated Multimedia. In 

Protocols and Systems for Interactive Distributed Multimedia Systems, 

Joint International Workshops on Interactive Distributed Multimedia 

Systems and Protocols for Multimedia Systems, IDMS/PROMS 2002, 

Proceedings, volume 2515 of Lecture Notes in Computer Science, pages 

327–338. Springer, 2002. 

[LRS03] Marco Lohse, Michael Repplinger, and Philipp Slusallek. Session 

Sharing as Middleware Service for Distributed Multimedia 

Applications. In Interactive Multimedia on Next Generation Networks, 

Proceedings of First International Workshop on Multimedia Interactive 

Protocols and Systems, MIPS 2003, volume 2899 of Lecture Notes in 

Computer Science, pages 258–269. Springer, 2003. 

[LRS05] Marco Lohse, Michael Repplinger, and Philipp Slusallek. Dynamic 

Media Routing in Multi-User Home Entertainment Systems. In 

Proceedings of The Eleventh International Conference on Distributed 

Multimedia Systems (DMS), pages 271–276. Knowledge Systems 

Institute, 2005. 

[LS02] Marco Lohse and Philipp Slusallek. An Open Platform for Multimedia 

Entertainment Systems. In EUROPRIX Scholars Conference at 

MindTrek Media Week, 2002. 

163


164 

[LS03] Marco Lohse and Philipp Slusallek. Middleware Support for Seamless 

Multimedia Home Entertainment for Mobile Users and Heterogeneous 

Environments. In Proceedings of The 7th IASTED International 

Conference on Internet and Multimedia Systems and Applications 

(IMSA), pages 217–222. ACTA Press, 2003. 

[LSW01] Marco Lohse, Philipp Slusallek, and Patrick Wambach. Extended 

Format Definition and Quality-driven Format Negotiation in 

Multimedia Systems. In Multimedia 2001 – Proceedings of the 

Eurographics Workshop, pages 65–74. Springer, 2001. 

[man01] ctime manpage, Dezember 2001. 

[Mica] Microsoft Corporation. Microsoft Media Center Extender. 

http://www.microsoft.com/windowsxp/mediacenter/ 

extender/default.mspx. 

[Micb] Microsoft Corporation. Microsoft Windows XP Media Center Edition 

2005. http://www.microsoft.com/germany/windowsxp/ 

mediacenter/default.mspx. 

[MPl] MPlayer. http://www.mplayerhq.hu. 

[MSIC] Ltd Micro-Star Int’l Co. VOX USB2.0 TV Box. 

http://www.msi.com.tw/program/products/multimedia/ 

mut/pro_mut_detail.php?UID=536. 

[MyS] MySQL AB. MySQL AB :: The World’s Most Popular Open Source 

Database. http://www.mysql.com/. 

[NMM] NMM work group. Network-Integrated Multimedia Middleware 

(NMM). http://www.networkmultimedia.org. 

[Per] Perl.com. http://www.perl.com. 

[Qui05] Liam Quin. Extensible Markup Language (XML), 2005. 

http://www.w3.org/XML/. 

[Rep03] Michael Repplinger. An Architecture for the Integration and Control of 

Distributed Multimedia Devices, 2003. Diplomarbeit, Universität des 

Saarlandes. 

[Ric] Isaac Richards. MythTV. http://www.mythtv.org. 

[RL04] Michael Repplinger and Marco Lohse. Clic - An Application for 

Setting up NMM Multimedia Flow Graphs, Juli 2004. 

http://www.networkmultimedia.org/Docs. 

[Sch] Klaus Schmiedinger. Video Disc Recorder. 

http:://www.cadsoft.de/vdr. 

[SGI] SGI. Standard Template Library Programmer’s Guide. 

http://www.sgi.com/tech/stl.

[SM00] Richard Stones and Neil Mathew. Linux Programmierung. MITP 

Verlag, 2000. 

[STO02] STORit consortium. STORit Home page, 2002. 

http://www.extra.research.philips.com/euprojects/storit/. 

[Str98] Bjarne Stroustrup. The C++-programming language. 

Addison-Wesley-Longman, 1998. 

[Sun] Sun Microsystems. Java Technology. http://java.sun.com. 


[TBL96] H. Frystyk T. Berners-Lee, R. Fielding. RFC 1945 - Hypertext Transfer 

Protocol – HTTP/1.0. Technical report, MIT/LCS, May 1996. 

[Thu] Paul Thurrott. Paul Thurrott’s SuperSite for Windows. 

http://www.winsupersite.com/. 

[TVA] TVAnytime Forum. http://www.tv-anytime.org/. 

[TVTa] TVToday. http://www.tvtoday.de. 

[tvtb] tvtv.de. http://www.tvtv.de. 

[UMT] UMTS Forum : Home. http://www.umts-forum.org/. 

[Vix93] Paul Vixie. cron manpage, Dezember 1993. 

[Vol] Sascha Volkenandt. Video Disk Recorder Extensions and Scripts: 

Client/Server Streaming. 

www.magoa.net/linux/index.php?view=streamdev-stable. 

[Wam01] Patrick Wambach. Formatdefinition und Formatverhandlung von 

Multimedia-Geräten, 2001. Diplomarbeit, Universität des Saarlandes. 

[Web] WebVCR+. http:://webvcrplus.sourceforge.net. 

[Wel05] Christoph Wellner. Setting up LiveTV, TVGuide and TVTimer of the 

NMM Multimedia-Box, August 2005. 

http://www.networkmultimedia.org/Docs/. 

[Wie] Christian Wieninger. VDR-EPG-Search. 

http://people.freenet.de/cwieninger/html/vdr-epg-search.html. 

[Wika] Wikipedia. Digitales Fernsehen. 

http://de.wikipedia.org/wiki/Digitales_Fernsehen. 

[Wikb] Wikipedia. Elektonische Programmzeitschrift. 

http://de.wikipedia.org/wiki/EPG. 

[Wikc] Wikipedia. Fernsehen. http://de.wikipedia.org/wiki/Fernsehen. 

[Wikd] Wikipedia. Hamming-Code. 

http://de.wikipedia.org/wiki/Hamming_code. 

[Wike] Wikipedia. Koordinierte Weltzeit. 

http://de.wikipedia.org/wiki/Koordinierte_Weltzeit. 

165


166 

[Wikf] Wikipedia. Peer-to-Peer. http://de.wikipedia.org/wiki/Peer-to-Peer. 

[Wikg] Wikipedia. Sommerzeit. http://de.wikipedia.org/wiki/MESZ. 

[Wikh] Wikipedia. Zeitzone. http://de.wikipedia.org/wiki/Zeitzone. 

[XML] XMLTV. http://membled.com/work/apps/xmltv/. 

[Zoe] Th. Zoerner. nexTView EPG Decoder Software. 

http://nxtvepg.sourceforge.net. 

[Zot05] Volker Zota. Multimedial Vereint. c’t - Magazin für Computertechnik, 

1, 2005.

Design und Implementierung eines Mehrbenutzer- Szenarios ... - NMM

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?