Post on 26-Feb-2019
Faculteit Ingenieurswetenschappen
Vakgroep Informatietechnologie
Voorzitter: Prof. Dr. Ir. P. Lagasse
Onderzoeksgroep Wireless & Cable
Directeur: prof. dr. ir. L. Martens
Ontwerp van een intelligente EPGvoor het MHP-platform
door
Stijn Hennebel
Promotor: Prof. Dr. Ir. L. Martens
Scriptiebegeleiders: Ir. T. Deryckere, Lic. M. Ide
Scriptie ingediend tot het behalen van de academische graad van
burgerlijk ingenieur in de computerwetenschappen
Academiejaar 2005–2006
Voorwoord
Deze thesis is het resultaat van maandenlang hard werken en vijf jaar studeren aan de Uni-
versiteit van Gent. Een speciaal woordje van dank gaat uit naar mijn ouders om me de kans
te geven deze studies tot een goed einde te brengen en voor de morele steun tijdens m’n opleiding.
Verder zou ik via dit voorwoord iedereen willen bedanken die op welke wijze dan ook mee-
gewerkt of geholpen heeft aan mijn eindwerk.
Ik bedank mijn promotor Luc Martens en mijn thesisbegeleiders Tom Deryckere en Michiel
Ide voor de goede begeleiding, nuttige tips en aanwijzingen.
Mijn dank gaat ook uit naar David Plets voor de leuke samenwerking en het helpen verbe-
teren van mijn schrijffouten.
Verder bedank ik ook Kristof Demeyere voor het gebruik van zijn DVB2IP-gateway.
Stijn Hennebel, juni 2006
Toelating tot bruikleen
“De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van
de scriptie te kopieren voor persoonlijk gebruik.
Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrek-
king tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit
deze scriptie.”
Stijn Hennebel, juni 2006
Ontwerp van een intelligente EPG
voor het MHP-platformdoor
Stijn Hennebel
Scriptie ingediend tot het behalen van de academische graad vanburgerlijk ingenieur in de computerwetenschappen
Academiejaar 2005–2006
Promotor: Prof. Dr. Ir. L. MartensScriptiebegeleiders: Ir. T. Deryckere, Lic. M. Ide
Faculteit IngenieurswetenschappenUniversiteit Gent
Vakgroep InformatietechnologieVoorzitter: Prof. Dr. Ir. P. LagasseOnderzoeksgroep Wireless & CableDirecteur: prof. dr. ir. L. Martens
Samenvatting
De ontwikkeling van een geavanceerde en intelligente EPG bovenop een eenvoudig uitbreidbarearchitectuur is het resultaat van deze thesis. Naar de gebruikers toe levert de gebruiksvriende-lijke applicatie een waaier aan mogelijkheden. Dankzij de informatieverkenner kunnen ze allemogelijke zenders overlopen, herinneringen en opnames instellen zonder ook maar een secondevan hun programma te missen. Het overzicht van de programma’s wordt op verschillende ma-nieren aangeboden, gesorteerd volgens zender, tijdstip of genre. Dankzij de movie informationserver verwent de EPG de gebruikers met extra filminformatie. Een VoD-server (video on de-mand) biedt de abonnees de mogelijkheid om vanuit hun luie zetel films of live events te bestellenen te bekijken. Als kers op de taart is het systeem zelflerend waardoor de EPG zelf actief opzoek gaat naar je favoriete programma’s. Hoewel het visuele aspect op onderzoeksniveau vanminder belang is, is er toch heel wat aandacht aan besteed. Het heeft namelijk een grote impactop de indruk die de applicatie nalaat.
De architectuur zorgt voor eenvoudige uitbreidbaarheid. Het toevoegen of vervangen van im-porteermogelijkheden, grafische interfaces, suggestiealgoritmes, . . . is heel eenvoudig. Dit maaktdeze applicatie een goede basis om ze verder uit te bouwen tot een allesbevattende EPG.
Trefwoorden
interactieve digitale televisie (iDTV), Multimedia Home Platform (MHP), Elektronisch pro-grammaboekje (EPG), personalisatie
Design of an intelligent EPG for the MHPenvironment.
Stijn Hennebel
Supervisor(s): Prof. Dr. Ir. L. Martens, Ir. T. Deryckere, Lic. M. Ide
Abstract—In this paper, we present an intelligent and advanced EPG andgive an overview of the functions a modern EPG should incorporate. Wewill show the architecture of a modular EPG system. This system enablesthe user to organize services according to his preferred view and record ap-plications using a PVR. Further the EPG will allow the addition of differentuser personalisation modules.
Keywords— Digital Interactive Television, Electronic Program Guide,Multimedia Home Platform, Personalization
I. I NTRODUCTION
WITH the advent of digital television, users are offeredhundreds of channels and even more programs. To help
them choose the programs of their interest, an EPG (electronicprogram guide) is needed. Simple EPGs show a list of programsthat are and will be broadcasted. Such an EPG provides only aview per service provider and results in long search and scrolltimes to find the appropriate program. An EPG that can organizethe programs more thematically (genre, age, language, . . . ) andthat tells the user where he can find what he wants will augmentthe usability of the application and improve the experience ofiDTV.The application is developed on top of the Multimedia HomePlatform (MHP) standard. MHP allows the development of in-teractive applications in a hardware platform independent waybecause it offers a common application programming interface(API), the DVB-J API. This standard is comprised of a numberof software packages that provide generic APIs to a wide rangeof features of the platform. The EPG is based on the MHP spec-ification 1.0.2[3], because this is currently mostly available onthe set-top boxes.Metadata is inserted in the broadcast stream to demultiplex thedifferent transport streams and to offer information about theevents. Retrieving this program specific information/service in-formation (PSI/SI) is one of the most important tasks of theEPG.
II. REQUIREMENTS
The EPG should help the users to find, select and acquire pro-grams of their interest. This will be implemented by providingdifferent views that sort the programs in different ways. Eachview will have his own purpose. There are some views wherethe user can browse by channel, by category, by genre, . . . Be-sides this functionality, there’s also a visible controller that al-lows the user to browse, search and schedule the recordings ofanother program, while continuing to watch.The EPG has to deliver as much information as possible. It canconnect to different dedicated servers who deliver specific infor-mation about programs or it can use for example PSI/SI infor-mation available in a DVB transport stream. E.g. in case of a
movie, it connects to a movie database to collect specific infor-mation, including director, actors, rating and even a trailer, if thecontent provider is willing to put these trailers into a transportstream. Video on demand (VoD) is also one of the possibilitiesthe EPG offers. The dedicated VoD server delivers movies andlive events the user can order.The EPG has a built-in PVR/PDR (personal video recorder /personal digital recorder) function if the set-top box supportsthis. The user can easily record a program by selecting it, so hedoesn’t have to worry about the start and end time.Users can plan their TV happening. They can easily select andadd programs to their planner. The EPG can give the user a re-minder or automatically switch to the pre-planned programs.
The application itself can be personalized. It supports multiplelanguages and it’s even possible to change the skin to a prede-fined or a self made one.And last but not least, the EPG is self-learning. It has a built-inrecommender function. Based on the user actions in the past, theuser preferences and the programs currently possible to choose,it can give some suggestions. The recommender function willnot be limited to one recommender algorithm. Pluggability forother algorithms is built-in.
III. A RCHITECTURE
The architecture is split up in different modules according totheir functionality. They each have their own responsibility. Theinteraction between the modules must be kept as low as possible.
A. Main module
The main is the controlling center of the application. Itarranges the start-up of the application and the initialisation ofall the other modules. Also the configuration management andthe planner functionality resides here.
B. Import module
The import module delivers the metadata that describes thedifferent programmes to the EPG. It controls a number of im-porting plug-ins. These plug-ins have to implement an Import-PlugIn interface which forces the plug-ins to deliver service dis-covery to the controller. This makes this system easily extend-able. Each plug-in takes care of a specific task such as im-porting service information (SI) from the stream, possible liveevents from a live event or video on demand (VoD) server. Itcan also fetch specific information such as movie informationfrom a movie database.
The EPG can be seen as an information center about TV pro-grams. It has to provide as much information as possible. Thisshould go further than just some simple description. As seenfrom the architecture, the metadata can be retrieved from sev-eral technological places. SI can be extracted from the broad-cast stream. This delivers basic information such as start time,duration, a short description, rating, running status etc.A video on demand server contains a list of possible movies orlive events which can be ordered by the user.The movie information server delivers specific movie related in-formation. It contains the data from IMDd (International MovieDatabase). Other dedicated servers who deliver specific infor-mation related to some programs such as e.g. Big Brother orextra data such as e.g. ratings are also included.
C. EPGdata module
The EPGdata module is the data manager of the application.It contains all the relevant data acquired by the import mod-ule. This module also provides specific data functions such assearching, sorting and so on . . .
D. User Suggestion Module
The recommender algorithms can be split into different cate-gories ([2], [5]).• Implicit algorithmsThese algorithms work with data only obtained by the self-learning process. It suffers from the cold-start problem.• Explicit algorithmsAn explicit algorithm works with initial start-up informationprovided by the user. Therefor it immediately delivers accurateresults. But the user must be willing to spend some effort.• Algorithms based on stereotypesPeople are classified into stereotypes or a combination of it. Byinterrogating the user according his age, sex, occupation, etc.the system defines the right stereotype and delivers recommen-dations conform his profile.The EPG handles a hybrid system containing different kind ofalgorithms ([6]). Those are combined in a slightly dynamic way.Each recommendation is delivered together with a confidenceand likeliness value. The former describes how sure the algo-rithm is about his decision. The latter estimates the apprecia-tion of the suggested program. Based on confidence, duplicaterecommendations are eliminated and the most confident one re-mains.In most cases a TV is used by more than one user ([4]). So herearises a problem because those users (e.g. children and parents)can have a completely different TV behaviour. When users haveto log in, they will see this too much as a burden. By incorpo-rating the time of the day, a family profile can be built. E.g. inthe late evening it will mostly be the parents who watch TV. Themetadata is stored on a global and on a dynamic way. The dy-namic table only incorporates the actions of the last seven dayswhich makes it possible to always take into account the mostrecent evolutions.
The internal system consists of three parts ([1]). The registrationsubmodule records the viewing behaviour of the users and storestheir choices in the user database. The data submodule keeps
track of all the data. It collects the data from the remote userdatabase and gets the data from the data manager. The recom-mender submodule has several recommender algorithms. Theyall use the data as input, deliver suggestions and implement aspecific interface, which makes the system easily upgradeableby simply inserting newer or more sophisticated algorithms.
E. Graphical Module
The graphical module contains everything with respect to thegraphical user interface. There are different modes, each withtheir own purpose and their own screen. E.g. there’s a modethat shows an overview of all the current programs. The usercan easily select what he wants to see at that moment. There arealso modes to search programs on the basis of keywords, to setsome configuration parameters and so on . . . It’s easy to extendthe applicating by adding new screens. Implementing the rightinterface suffices.
F. System Resources Module
If an application wants to use the scarce resources, he has toreserve them, e.g. the different screen layers have to be reserved.This module takes care of this.
G. Play Module
The JavaTV service selection API is used in this module totake care of playing the content.
H. Client Connection Module
Some modules, such as the import module and the user sug-gestion module, have to use the return channel to connect toremote servers. This module abstracts the details of a socketconnection and the encapsulation of an object into a XML-file.It consists of an asynchronous system with a built-in priorityscheduler.
IV. CONCLUSIONS
In this paper, we have presented an open, modular and eas-ily extendable architecture for an intelligent and advanced EPG.It is built as a framework around the requirements for a userfriendly EPG and allows to use external modules that fulfil theserequirements. So the different functionalities can easily be re-placed by newer or more sophisticated ones.
REFERENCES
[1] Blanco-Fernndez, Y., Pazos-Arias, J.J., Gil-Solla, A. et al. (2004).AVATAR:An Advanced Multi-Agent Recommender System of Personalized TV Con-tents by Semantic Reasoning. Spain, Department of Telematic Engineering,University of Vigo.
[2] Buczak, A.L, Zimmerman, J. & Kurapati,K. (2002). “Personalization: Im-proving Ease-of-Use, Trust and Accuracy of a TV Show Recommender”.USA, Philips Research USA.
[3] European Telecommunications Standards Institute (ETSI) (2002). DigitalVideo Broadcasting (DVB) - Multimedia Home Platform (MHP) Specifica-tion 1.0.2, Doc.nr.: TS 101 812 v1.2.1.
[4] Goren-Bar, D. & Glinansky, O. (2002). Family Stereotyping - A Model toFilter TV Programs for Multiple Viewers, Israel, Department of InformationSystems Engineering, Ben-Gurion University of the Negev.
[5] Kurapati, K. & Gutta, S. (2002). TV Personalization through Stereotypes.USA, Philips Research USA.
[6] Van Setten, M., Veenstra, M. & NijholtPrediction, A. (2002). Strategies:Combining Prediction Techniques to Optimize Personalization. The Nether-lands, Telematica Instituut & University of Twente.
INHOUDSOPGAVE i
Inhoudsopgave
1 Inleiding 1
1.1 iDTV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 MHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.1 Architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.2 Profielen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.3 Xlets & Application lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.4 API’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 EPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Requirements 8
2.1 Doelstellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Overzicht van de belangrijkste functionaliteiten . . . . . . . . . . . . . . . . . . . 9
2.3 Kwaliteitsaspecten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1 Uitbreidbaarheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.2 Gebruiksvriendelijkheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.3 Beschikbaarheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.4 Prestaties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Scenario’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.1 Scenario 1: Huidig programmaoverzicht . . . . . . . . . . . . . . . . . . . 12
2.4.2 Scenario 2: Categorieoverzicht . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.3 Scenario 3: Zoekscherm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Architectuur EPG 15
3.1 Algemene structuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Overzicht packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
INHOUDSOPGAVE ii
3.3 Modulair overzicht van de algemene architectuur . . . . . . . . . . . . . . . . . . 18
4 Bespreking verschillende modules 20
4.1 Main Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1.1 Configuratiegegevens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1.2 Xlet interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.3 Herinneringen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.4 Initialisatiefase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.5 Dirigerende functie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.6 Starten van de applicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Client Connection Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.1 Return Channel Request Protocol (RCRP) . . . . . . . . . . . . . . . . . 25
4.2.2 Interne Architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 Import Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3.1 Opstarttijd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3.2 Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.3 Broadcast stroom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.4 LE- & VoD-server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.5 Movie Information Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.6 Overige mogelijke servers . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.7 Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.8 Keuze SI - externe server . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.9 Intern systeem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.4 EPGdata Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4.1 Ontwerp interne opslag . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4.2 Zoekfuncties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.4.3 Model-view paradigma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.4.4 Programmatypes en -subtypes . . . . . . . . . . . . . . . . . . . . . . . . 49
4.5 Play Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.5.1 Locator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.5.2 JMF-systeem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.5.3 JavaTV Service Selection API . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.5.4 Keuze van gebruikt systeem . . . . . . . . . . . . . . . . . . . . . . . . . . 52
INHOUDSOPGAVE iii
4.5.5 Overzicht mogelijkheden . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.6 Resource Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.6.1 Intern systeem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.6.2 De verschillende schermlagen . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.6.3 Terugkeerkanaal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.6.4 Event manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.7 Graphical Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.7.1 Intern systeem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.7.2 Taal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.7.3 Skins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.7.4 Vaak gebruikte componenten . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.7.5 Verschillende schermen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.8 User Suggestion Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.8.1 Aanbevelingsalgoritmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.8.2 Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.8.3 Intern systeem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5 Bespreking verschillende servers 85
5.1 Movie Information Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.1.1 Inhoud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.1.2 Werking & mogelijkheden . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.1.3 Installatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.1.4 Uitbreidingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.2 AEPG server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.2.1 Databank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.2.2 Configuration server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.2.3 User suggestion server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.3 VoD server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6 Besluit 93
6.1 Algemeen besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.2 Algemene uitbreidingen en integraties . . . . . . . . . . . . . . . . . . . . . . . . 95
INHOUDSOPGAVE iv
A XML-bestanden 98
A.1 Filminformatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
A.2 Configuratiegegevens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
A.3 Suggestiegegevens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
A.3.1 Registreren gebruikersactie . . . . . . . . . . . . . . . . . . . . . . . . . . 101
A.3.2 Registreren suggestievoorkeuren . . . . . . . . . . . . . . . . . . . . . . . 102
A.3.3 Specifieke aanvraag suggestiegegevens . . . . . . . . . . . . . . . . . . . . 104
A.3.4 Suggestiegegevens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
A.4 VoD server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
A.4.1 Initialisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
A.4.2 VoD- & LE-informatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
B Databanktabellen 116
B.1 Algemeen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
B.1.1 USERIDTABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
B.2 Configuratiegedeelte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
B.2.1 LANGUAGETABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
B.2.2 RCTABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
B.2.3 SERVERIDTABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
B.2.4 SERVERSTABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
B.2.5 CHANNELTABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
B.2.6 TVSEQTABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
B.2.7 RADIOSEQTABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
B.3 Suggestiegedeelte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
B.3.1 PROGRAMTYPEGLOBALTABLE . . . . . . . . . . . . . . . . . . . . . 119
B.3.2 PROGRAMSUBTYPEGLOBALTABLE . . . . . . . . . . . . . . . . . . . 119
B.3.3 CHANNELGLOBALTABLE . . . . . . . . . . . . . . . . . . . . . . . . . 120
B.3.4 CASTTABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
B.3.5 DIRECTORTABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
C Schermafbeeldingen 121
C.1 Hoofdscherm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
C.2 Informatieverkenner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
INHOUDSOPGAVE v
C.3 Programma’s op dit momemt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
C.4 Volledig TV overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
C.5 Herinneringenoverzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
C.6 Virtuele videotheek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
C.7 Categorieoverzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
C.8 Suggesties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
C.9 Zoeken naar programma’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
C.10 Instellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
C.11 Extraatje : Snake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
D UML-schema’s 128
D.1 Main module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
D.2 Client connection module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
D.3 Import module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
D.4 EPG data module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
D.5 User suggestion module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
D.6 Graphical module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
D.7 Resource module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Lijst van afkortingen vi
Lijst van afkortingen
AIT Application Information Table
API Application Programming Interface
AWT Abstract Window Toolkit
DAVIC Digital Audio Visual Council
DBMS Database Management System
DSL Digital Subscriber Line
EIT Event Information Table
EPG Electronic Program Guide
ETSI European Telecommunications Standards Institute
FIT Family Interactive TV system
FTP File Transfer Protocol
HAVi Home Audio/Video Interoperability
HTTP Hypertext Transfer Protocol
iDTV interactieve Digitale Televisie
IMDb Internet Movie Database
IP Internet Protocol
JMF Java Multimedia Framework
LE Live Events
Lijst van afkortingen vii
MHP Multimedia Home Platform
NTSC National Television System(s) Committee
OCAP Open Cable Application Platform
PAL Phase Alternating Line
PDR Personal Digital Recorder
PVR Personal Video Recorder
RCRP Return Channel Request Protocol
Secam Sequentiel couleur a memoire
SI Service Information
SMS Short Message Service
SQL Structured Query Language
VoD Video on Demand
VoIP Voice over IP
XML Extensible Markup Language
LIJST VAN FIGUREN viii
Lijst van figuren
1.1 De softwarestapel in een MHP-gebaseerd systeem . . . . . . . . . . . . . . . . . . 2
1.2 Overzicht van de drie profielen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Overzicht van de verschillende API’s . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 scenario 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 scenario 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1 De modulaire architectuur van de EPG. . . . . . . . . . . . . . . . . . . . . . . . 19
4.1 De fasen en overgangen van een Xlet . . . . . . . . . . . . . . . . . . . . . . . . . 21
C.1 Hoofdmenu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
C.2 Informatieverkenner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
C.3 Huidig programmaoverzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
C.4 Volledig tv-overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
C.5 Herinneringenoverzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
C.6 Virtuele videotheek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
C.7 MovieInformationScreen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
C.8 Categorieoverzicht: input-gedeelte . . . . . . . . . . . . . . . . . . . . . . . . . . 125
C.9 Categorieoverzicht: resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
C.10 Suggestievoorkeuren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
C.11 Zoekscherm: resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
C.12 Instellingenmenu: skin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
C.13 Snake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
D.1 UML-schema: main module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
LIJST VAN FIGUREN ix
D.2 UML-schema: planner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
D.3 UML-schema: client connection module . . . . . . . . . . . . . . . . . . . . . . . 129
D.4 UML-schema: import module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
D.5 UML-schema: import SI plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
D.6 UML-schema: import VoD plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . 131
D.7 UML-schema: EPGdata module . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
D.8 UML-schema: user suggestion module . . . . . . . . . . . . . . . . . . . . . . . . 132
D.9 UML-schema: user suggestion module overview . . . . . . . . . . . . . . . . . . . 132
D.10 UML-schema: graphical module . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
D.11 UML-schema: full overview screen . . . . . . . . . . . . . . . . . . . . . . . . . . 134
D.12 UML-schema: resource module . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
INLEIDING 1
Hoofdstuk 1
Inleiding
1.1 iDTV
Aanvankelijk bood analoge televisie enkel lokale interactiviteit. De kijker had de mogelijkheid
om te zappen van de ene naar de andere zender. Later voegde men hier teletekst aan toe.
In dit systeem worden de pagina’s continu in een lus gebroadcast. Wanneer de gebruiker een
pagina opvraagt, wacht de tv gewoonweg tot deze op de kabel gevonden wordt. De laatste
jaren zit de regionale interactiviteit, die via parallelle kanalen zoals SMS verloopt, in de lift.
Televisiemaatschappijen zagen hun inkomsten sterk stijgen door in te spelen op de groeiende
SMS-hype. Men is en blijft echter beperkt tot het een-richtings broadcastverkeer.
De opkomst van interactieve digitale televisie (iDTV) opent heel wat perspectieven. Dank-
zij het terugkeerkanaal kan de kijker via de afstandsbediening ondergedompeld worden in de
wereld van interactieve televisie waarin hij of zij actief betrokken wordt. Compleet op maat
aangeboden diensten zijn mogelijk! Applicaties als een elektronisch programmmaboekje (EPG),
een sportportaal, een instant messenger . . . bieden diensten aan die de mensen over de streep
moet trekken digitale tv in huis te halen. Gepersonaliseerde publiciteit, interactief deelnemen
aan (gok)spelletjes en quizen, . . . gaan de televisiemaatschappijen ongetwijfeld nog veel geld
opleveren.
Digitale televisie heeft het grote voordeel dat het meer zenders kan aanbieden dankzij een effi-
cientere bandbreedte benutting. Een transportstroom kan immers dankzij de MPEG-2-codering
meerdere digitale kanalen bevatten waar voorheen slechts een analoog kanaal deze volledig in
beslag nam. Digitaal betekent dat er naast het traditionele beeld en geluid er ook informatie
1.2 MHP 2
in bits en bytes verstuurd kan worden. Bijgevolg kan men naast het aanbieden van applicaties
ook metadata meesturen, dewelke een EPG kan gebruiken om de kijker te informeren over de
tv-programma’s.
Om voor interoperabiliteit te zorgen, is er nood aan een platform dat wereldwijd gebruikt
wordt. Momenteel zijn er een aantal beschikbaar, zoals OpenTV, MediaHighway en IPTV van
Microsoft. Multimedia Home Platform (MHP) is ontwikkeld door het Digital Video Broadcast
project (DVB) waarin wereldwijd zo’n 270 bedrijven, netwerkoperatoren, softwareontwikkelaars
en andere zetelen. MHP is een volledig open Java gebaseerd middleware platform. De specifi-
caties en de API’s kunnen gratis van het internet gedownload worden.
1.2 MHP
MHP is een open middleware systeem ontwikkeld door DVB voor interactieve digitale televisie.
Ze is gebaseerd op de programmeertaal Java, DVB-J. Dankzij de middleware is het mogelijk om
applicaties te ontwikkelen onafhankelijk van het hardwareplatform waarop ze draaien.
Figuur 1.1: De softwarestapel in een MHP-gebaseerd systeem. bron: Wikipedia
1.2.1 Architectuur
De MHP-omgeving is gebaseerd op het gebruik van een Java Virtuele Machine en een aantal
generieke API’s die toegang verlenen tot specifieke systeembronnen en voorzieningen om bij-
voorbeeld service information (SI) uit de broadcast stroom op te vragen. De applicaties maken
1.2 MHP 3
gebruik van deze API’s om de nodige functionaliteiten te implementeren zonder zich ook maar
iets van de onderliggende hardwarestructuur aan te trekken. 1.2.4 geeft een overzicht van de
verschillende API’s. De set-top box voorziet de gebruiker de mogelijkheid toegang te verkrijgen
tot de verschillende applicaties en digitale tv- en radiokanalen via de ”Navigator”. Figuur 1.1
geeft een overzicht van de softwarestapel in een MHP-gebaseerd systeem.
1.2.2 Profielen
MHP is een verzameling van standaarden die het volledige middlewaresysteem beschrijven. Ze
is onderverdeeld in profielen zodat niet alle toepassingen alles hiervan moeten implementeren.
Een profiel verwijst naar een specifiek toepassingsgebied. Er zijn drie verschillende profielen:
Figuur 1.2: Overzicht van de drie profielen bron: www.mhp.org
1. Enhanced Broadcast Profile ([9])
Dit profiel is ontworpen om de functionaliteit van de bestaande middlewaresystemen en
de programma’s die erop draaien te ondersteunen. Dit profiel ondersteunt geen tot heel
weinig interactie via het terugkeerkanaal. Set-top boxen die enkel dit profiel ondersteunen
hoeven niet al te krachtig te zijn.
2. Interactive TV Profile ([9])
Het interactief tv-profiel levert goed uitgebouwde terugkeerkanaalmogelijkheden. Boven-
dien laat dit profiel toe om de applicatie via het terugkeerkanaal in te laden. Dit was in
profiel 1 helemaal niet het geval.
1.2 MHP 4
3. Internet Acces Profile ([12])
Het internettoegangsprofiel heeft nood aan een goed uitgeruste en krachtige set-top box.
Zoals de naam aangeeft beschikt ze over de nodige API’s om internetgebaseerde inhoud
op tv te brengen. In dit profiel is het DVB-HTML element optioneel.
De set-top box in het labo ondersteunt, net als de meeste huidige set-top boxen de 1.0.3 speci-
ficatie. Bijgevolg is deze thesis hierop gebaseerd.
1.2.3 Xlets & Application lifecycle
Een interactief digitaal televisieprogramma werkt niet zoals een conventioneel java-programma
waar ze het enige programma draaiend op de virtuele machine is en bovendien hierover volledige
controle heeft. In een digitale tv-ontvanger moeten meerdere applicaties samen bestaan. Er
bestaat reeds een goed model hiervoor, namelijk de Applets. Men heeft het principe van Applets
aangepast naar de televisieomgeving en deze Xlets genoemd. Ze worden aangestuurd door de
application manager. Hoe dit in zijn werk gaat, komt uitgebreid aan bod in 4.1.2 op pagina 21.
1.2.4 API’s
Figuur 1.3 levert een grafisch overzicht van de verschillende API’s. Enkel de DAVIC resource
notification API ontbreekt. Hieronder worden de belangrijkste opgesomd en kort besproken.
Figuur 1.3: Overzicht van de verschillende API’s. (bron: [21])
DAVIC resource notification API
Het beheren van de schaarse bronnen wordt hier geregeld. Dit komt verder uitvoerig aan
bod in 4.6 op pagina 53.
1.2 MHP 5
Tuner API
Deze API levert de nodige functies om hardwarematig af te stemmen op een welbepaalde
transportstroom.
SI
SI of service information levert de metadata over de programma’s. Zowel JavaTV als DVB
leveren elk een eigen API met als doel deze SI uit de stroom op te vragen. Beide worden
volledig uit de doeken gedaan in 4.3.3 op pagina 33.
JMF
Java Multimedia Framework (JMF) wordt voornamelijk gebruikt om beeld en geluid af te
spelen. Zie 4.5.2 op pagina 51 voor meer informatie.
JavaTV service selection API
De functies nodig om van kanaal (in digitale tv-termen: service) te veranderen, worden
hier aangeboden. Meer uitleg is te vinden in 4.5.3 op pagina 52.
Terugkeerkanaal API
Enkel indien het terugkeerkanaal niet over een breedbandverbinding zoals kabel of DSL
beschikt, maar via een gewone inbelverbinding verloopt, wordt deze als een schaarse sys-
teembron gezien. Deze API regelt het reserveren van zo’n terugkeerkanaal (zie 4.6.3 op
pagina 55).
AWT
De Abstract Window Toolkit (AWT) is de grafische basis-API uit de Java-specificatie.
Hetgeen niet geschikt leek voor een televisieomgeving werd eruitgehaald.
HAVi
De Home Audio/Video Interoperability API (HAVi) levert een verzameling van grafische
componenten die in de meeste gevallen verder bouwen op de AWT-componenten. Ze zijn
speciaal aan de tv-omgeving aangepast.
DVB UI API
Deze API bouwt ook verder op AWT. Ze levert echter aan de huidige componenten extra
mogelijkheden zoals bijvoorbeeld doorzichtige kleuren.
UI Event API
1.3 EPG 6
De verwerking van de User Input Events, zoals het indrukken van de toetsen op de af-
standsbediening, behandelt deze API.
1.3 EPG
Dankzij de opkomst van digitale televisie overspoelen de netwerkoperatoren hun abonnees met
digitale zenders in alle geuren en kleuren. Opdat ze nog het bos doorheen de bomen zouden zien,
is er een elektronisch programmaboekje (Electronic Program Guide, EPG) nodig die hen bijstaat
in het zoeken naar hun favoriete programma’s. De EPG vervangt dus als het ware de tv-gids of
de pagina’s uit de krant die een overzicht bieden van het volledig tv-aanbod. Eenvoudige EPG’s
leveren enkel een overzicht van alle zenders met hun programma’s. Bijgevolg moet de gebruiker
alles overlopen om een gewenst programma te vinden. Een goede EPG is echter actief in plaats
van passief en helpt de gebruiker in het zoeken naar de geschikte programma’s.
Een EPG zal in de toekomst steeds meer en meer aan belang inwinnen. Deze applicatie
wordt een verzamelplaats voor allerhande informatie. Men koopt wekelijks zijn tv-gids in de
winkel om te weten wat er op tv is, maar ook voor de talrijke weetjes over de bekende vlamingen
en de beroemdheden, voor de interviews, voor de quoteringen die films krijgen, . . .
Huidige EPG’s gaan hier helemaal niet zo ver in. Ze leveren de basisinformatie en dit op een
passieve manier. Dit bracht me op het idee om een EPG te ontwikkelen die verder gaat dan
het leveren van de basisinformatie en vooral een EPG die actief de gebruiker helpt door zelf
een aantal programma’s voor te stellen op basis van een zelflerend systeem. Handige systeem-
pjes zoals een zoekmachine helpen de gebruiker om zelf actief zijn programma’s te zoeken. De
integratie van een opnamesysteem (Personal Video Recorder, PVR) zal zeker en vast als een
pluspunt beschouwd worden.
Om het mogelijk te maken de EPG systematisch verder uit te breiden met extra mogelijkheden,
had ik als doel voor deze thesis een applicatie te ontwikkelen waarbij de architectuur het toevoe-
gen van nieuwe functionaliteiten zo eenvoudig mogelijk maakt. Basisbenodigdheden zoals het
verzorgen van de communicatie met externe servers via het IP-netwerk moet de kern van het
systeem volledig zelf regelen. Dit versnelt het ontwikkelingsproces van de nieuwe mogelijkheden
en vermindert de kans op incompatibiliteiten.
In hoofdstuk 2 worden de doelstellingen en de functionaliteiten uit de doeken gedaan. Deze
worden geıllustreerd aan de hand van een aantal scenario’s. De algemene architecturale structuur
1.3 EPG 7
komt aan bod in hoofdstuk 3. Hoofdstuk 4 bevat het grootste gedeelte. De functionaliteiten,
gebundeld in modules worden er volledig onder de loep genomen. De verschillende interne
systemen worden er tot op een zekere diepte besproken, afhankelijk van hun belangrijkheid.
Samen met de EPG zijn er aan aantal servers ontwikkeld die de nodige informatie verschaffen
en opslaan. Een overzicht hiervan is te vinden in hoofdstuk 5. We eindigen met een besluit in
hoofdstuk 6.
REQUIREMENTS 8
Hoofdstuk 2
Requirements
2.1 Doelstellingen
Het doel van deze thesis is het ontwikkelen van een geavanceerd elektronisch programmaboekje,
beter bekend als EPG (Electronic Program Guide). Dit brengt met zich mee dat ik heel wat
kennis over het MHP-platform en de bijhorende API’s moest opdoen. De applicatie moet aan een
aantal kwaliteitsvoorwaarden voldoen, zowel naar de gebruikers toe als naar de ontwikkelaars,
die deze applicatie eventueel in de toekomst zullen uitbreiden.
Gebruikers moeten in staat gesteld worden om op een eenvoudige en gebruiksvriendelijke
manier te kunnen bladeren tussen de vele programma’s en kanalen die digitale tv hen aanbiedt.
De EPG sorteert de programma’s naargelang hun kanaal of categorie. Er zijn verschillende
schermen, elk met hun eigen functionaliteit om het de gebruiker zo gemakkelijk mogelijk te
maken.
De EPG heeft als doel zoveel mogelijk informatie te verschaffen. Ze haalt de basisinformatie uit
de broadcast stroom die service information (SI) bevat. Ze kan ook communiceren met meerdere
servers die specifieke informatie over programma’s, films en dergelijke leveren. Bijvoorbeeld in
het geval van een film, haalt de EPG extra filmspecifieke gegevens zoals de acteurs/actrices en
de regisseur op bij een filmdatabank.
De EPG laat de gebruikers toe herinneringen in te stellen om op die manier hun volledige
tv-avond te plannen. Wanneer een herinnering afloopt, verschijnt er ofwel een melding, ofwel
schakelt deze automatisch over naar het desbetreffend programma. Vervolgens bevat de ap-
2.2 Overzicht van de belangrijkste functionaliteiten 9
plicatie een zoeksysteem om het volledig tv-aanbod algemeen op een aantal kernwoorden te
doorzoeken. Bovendien heeft de EPG een ingebouwde opnamefunctie PVR/PDR (Personal Vi-
deo Recorder [7] / Personal Digital Recorder [6]), waarbij de gebruiker eenvoudig een programma
kan selecteren zonder zich zorgen te maken over de start- en eindtijden.
De informatieverkenner biedt de mogelijkheid om alle zenders te overlopen, herinneringen en
opnames in te stellen zonder ook maar een seconde van je programma te missen. Op het onder-
ste gedeelte na, blijft het volledige videobeeld immers zichtbaar.
Met de ingebouwde virtuele videotheek is het mogelijk om films of live events (LE) zoals concer-
ten vanuit je luie zetel te bestellen en te bekijken. De EPG ondersteunt ook de typische functies
zoals play, pause, stop, FFW en FRW.
Het revolutionaire aan deze EPG is ongetwijfeld het zelflerend systeem. Het registreert de
acties van de gebruiker en op basis van een leerproces kan het na een zeker verloop van tijd
bepalen wat de voorkeuren van deze gebruiker zijn. Indien de gebruiker dit wenst, kan hij of zij
dit leerproces versnellen door zijn of haar voorkeuren in te geven. Dankzij dit systeem kan de
EPG een aantal programma’s aanbevelen. Het is namelijk niet altijd eenvoudig om alle kanalen
te overlopen om een programma binnen je interessegebied te zoeken. En zeker niet wanneer er
zo’n honderd kanalen aangeboden worden.
Naar de kant van de softwareontwikkelaars toe, is het vooral belangrijk dat ze op een een-
voudige manier de applicatie verder kunnen uitbouwen. Een goed gestructureerde modulaire
architectuur zorgt ervoor dat men op een transparante wijze nieuwe importeereenheden, scher-
men, kiesalgoritmes, . . . kan toevoegen.
2.2 Overzicht van de belangrijkste functionaliteiten
• overzicht van alle tv- en radioprogramma’s met hun informatie zoals genre en korte inhoud.
• overzicht volgens categorie of genre om snel iets binnen je interessegebied te vinden
• informatieverkenner: alle zenders overlopen, herinneringen en opnames instellen zonder
ook maar een seconde van je programma te missen
2.3 Kwaliteitsaspecten 10
• extra filmgegevens dankzij volledig uitgewerkte filmdatabank
• goed uitgebouwde zoekfuncties
• herinneringen instellen en ze beheren
• volledig automatisch een programma laten opnemen
• zelflerend systeem
– levert aanbevelingen die je vaak zelf nooit zou ontdekken
– mogelijkheid om initiele voorkeuren in te geven
• virtuele videotheek met films en live events dankzij VoD-server
• personalisatie van de applicatie door verschillende skins, zelfs mogelijkheid om eigen skin
samen te stellen
• ondersteunt Nederlands en Engels, uitbreiding naar meerdere talen voorzien
• extraatje: het populaire spelletje Snake
2.3 Kwaliteitsaspecten
2.3.1 Uitbreidbaarheid
Het onderhoud van een applicatie is van cruciaal belang. Wanneer men teveel aanpassingen
moet doorvoeren om een nieuwe functionaliteit in te voegen of aan te passen, kan de kost hiervan
heel hoog liggen. Dit kan men vermijden door een transparante architectuur. De verschillende
modules werken met een vooraf gedefinieerde interface zodat men ze zonder enige problemen kan
vervangen. Wanneer er bijvoorbeeld later een andere importeermodule gebruikt wordt, moet dit
zo weinig mogelijk implicaties hebben op de rest van het programma. Het volledig onderliggend
systeem is erop voorzien om op een gemakkelijke manier nieuwe importeereenheden, schermen,
kiesalgoritmes, . . . toe te voegen.
2.3.2 Gebruiksvriendelijkheid
Aangezien alle lagen van de bevolking gebruik van deze EPG zullen maken, moet deze enorm
gebruiksvriendelijk zijn. Er zullen namelijk ook mensen die nog nooit een computer van dichtbij
2.3 Kwaliteitsaspecten 11
gezien hebben hiermee werken. Er moet telkens duidelijk aangegeven worden wat de mogelijk-
heden zijn en waarvoor de verschillende knoppen op de afstandsbediening staan.
2.3.3 Beschikbaarheid
De verwachtingen ten opzichte van een televisietoestel zijn compleet anders dan deze ten opzichte
van een computer. Het vastlopen van een computer wordt algemeen aanvaard. Bij een tv ligt
dit totaal anders. Een tv moet altijd werken en bovendien liefst in real time. Wanneer er toch
fouten optreden, moeten deze zoveel mogelijk verborgen blijven voor de gebruiker. Een zeer
uitvoerige foutcorrectie is dus onontbeerlijk!
2.3.4 Prestaties
De mensen verwachten dat een tv steeds onmiddellijk doet wat ze vragen. Dit is niet altijd
mogelijk. Hiervoor moet de applicatie dus telkens duidelijke signalen geven naar de gebruiker
toe, bijvoorbeeld wanneer een applicatie bezig is met het ophalen van gegevens. De latentie moet
in de mate van het mogelijke verborgen worden. In deze EPG worden eerst de belangrijkste
gegevens geımporteerd. Terwijl de reeds opgehaalde gegevens aan de gebruiker aangeboden
worden, worden de overige gegevens verder opgehaald. Op deze manier zal de opstarttijd heel
wat verbeteren.
2.4 Scenario’s 12
2.4 Scenario’s
Hieronder zullen we een drietal scenario’s beschrijven die aangeven welke weg ze doorheen de
applicatie volgen. Ze tonen mooi aan hoe de verschillende modules interageren met elkaar. We
vertrekken steeds vanuit de preconditie dat de EPG opgestart is en dat alle programma’s reeds
geımporteerd zijn. We starten in het hoofdmenu.
2.4.1 Gebruiker kiest een programma uit het huidige programmaoverzicht
De gebruiker selecteert het juiste icoontje in het hoofdmenu en bevestigt met de OK-toets. Hij
of zij bladert doorheen het overzicht met de huidige programma’s via de pijltjetoets naar links.
Hij of zij kiest een programma en drukt op de OK-toets om dit te bekijken. Deze actie wordt
via de GraphicalController aan de hoofdmodule doorgegeven. De main geeft de afspeelmodule
de opdracht om over te schakelen naar deze zender en geeft deze actie verder door aan de
suggestiemodule, die dit verder zal verwerken.
Figuur 2.1: Scenario 1: huidig programmaoverzicht
2.4 Scenario’s 13
2.4.2 Gebruiker vraagt alle komedies op in het categorieoverzicht en kiest er
een uit om op te nemen
De gebruiker selecteert het juiste icoontje in het hoofdmenu en bevestigt met de OK-toets. De
GraphicalController maakt het hoofdmenu onzichtbaar en laat het categerieoverzicht tevoor-
schijn komen. Via een menu kiest de gebruiker eerst de categorie ’film’ en daarna specifiek
’komedies’. Een lijst van alle komedies verschijnt op het scherm. De gebruiker kiest er een
uit en drukt op de groene toets om ze op te nemen. Deze actie wordt opnieuw via de Grap-
hicalController doorgegeven aan de hoofdmodule die dit verder doorgeeft aan de PVR- en de
suggestiemodule. Beide verwerken ze de aanvraag.
Figuur 2.2: Scenario 2: categorieoverzicht
2.4.3 Gebruiker zoekt een programma via het zoekscherm en stelt een her-
innering in voor het gevonden programma
In het zoekscherm aangekomen, drukt de gebruiker op de OK-toets om kernwoorden in te geven.
Wanneer hij klaar is, drukt hij op de exit-toets. Vervolgens drukt hij op de gele toets om een
genre in te voegen. Hij kiest het gewenste type en subtype en bevestigd met de OK-toets. Via de
rode toets start hij het zoeken. De opslageenheid wordt volledig doorzocht en levert een aantal
resultaten. Deze worden op het scherm getoond. De gebruiker doorloopt deze resultaten, kiest
er een uit en drukt op de gele toets om hiervoor een herinnering in te stellen.
ARCHITECTUUR EPG 15
Hoofdstuk 3
Architectuur EPG
3.1 Algemene structuur
Een goed gestructureerde architectuur is essentieel om de nodige kwaliteitseisen te garanderen.
De architectuur van de EPG wordt opgesplitst in verschillende modules, elk men hun eigen
specifieke taak en verantwoordelijkheid. De interacties tussen de verschillende modules moet zo
laag mogelijk zijn. Op die manier bekomt men een transparante en modulaire architectuur die
gemakkelijk uitbreidbaar is. Elke module heeft een interface die de functies naar de buitenwereld
toe definieert. Hoe deze functies ingevuld worden, hangt enkel van de desbetreffende module af.
Elke module op zich heeft terug een eigen architectuur. De ene is natuurlijk heel wat uitge-
breider dan de andere. Aan het hoofd van elke module staat een controller die verantwoordelijk
is voor het reilen en zeilen binnenin zijn eigen subsysteem. Behalve het ophalen van gegevens
uit de opslageenheid, verlopen alle interacties met de overige modules via deze controller. Dit
zorgt ervoor dat het systeem eenvoudig uitbreidbaar is waar nodig. De kern van het systeem
blijft immers ongewijzigd.
Wanneer men bijvoorbeeld een nieuw scherm toevoegt aan de grafische module, dan zal alle
communicatie met de client connection module via de GraphicalController verlopen. De client
connection module hoeft dus helemaal geen weet te hebben van dit nieuwe scherm. Ze levert
het antwoord gewoon aan de GraphicalController die zelf verantwoordelijk is om het aan de
juiste klasse in zijn eigen subsysteem af te leveren. Mocht dit nieuwe scherm echter rechtstreeks
communiceren met het asynchrone systeem in de client connection module, dan zou men deze
laatste moeten aanpassen om het in de mogelijkheid te stellen de juiste klasse het antwoord te
bezorgen.
3.2 Overzicht packages 16
We hebben hier dus een duidelijke hierarchische structuur. De hoofdmodule bevat de Xlet-
klasse die de verschillende controllers aanstuurt. Die controllers sturen dan verder hun eigen
subsysteem aan. Het subsysteem binnen een module is gebundeld in een package. Er zijn ook een
tweetal packages die geen module, maar eerder een afgebakend geheel vormen. In de volgende
sectie geven we hiervan een overzicht.
3.2 Overzicht packages
• clientconnectionmodule
Deze package bevat de volledige client connection module, die alles in en rond het terug-
keerkanaal regelt. Elke module die een verbinding met een server wil opzetten, kan gebruik
maken van deze module.
• epgdatamodule
Dit is de EPGdata module die als opslageenheid fungeert. Ze bevat alle relevante data voor
de hele applicatie en levert elke module de nodige gegevens. Ze is voorzien van opslag-,
zoek- en sorteerfuncties.
• nanoxml
Sommige modules moeten XML-bestanden parsen. Hiervoor maken ze gebruik van deze
package, ontwikkeld door Marc De Scheemaecker. Het betreft de NanoXML 2 Lite versie1.
• playmodule
Het overschakelen naar een zender en het afspelen van de inhoud ervan wordt hier in de
afspeelmodule geregeld.
• resourcemodule
Het initialiseren en het reserveren van de verschillende systeembronnen gebeurt in de
systeembronnenmodule.
• usersuggestionmodule
Deze module bevat het volledig zelflerend systeem. Ze verwerkt de geregistreerde gebrui-
kersacties en verstuurt deze gegevens naar de server. Verder levert ze op basis van de
opgedane kennis en de mogelijke programma’s een aantal aanbevelingen.1te downloaden op http://nanoxml.cyberelf.be/
3.2 Overzicht packages 17
– USalgorithms
Deze subpackage bevat alle kiesalgoritmes.
• planner
Deze package, een onderdeel van de hoofdmodule, verzorgt het bijhouden van de herinne-
ringen en het weergeven van de nodige meldingen.
• graphicalmodule
De grafische module bevat naast een aantal algemene componenten, subpackages die elk
een specifiek scherm bevatten. Hieronder een overzicht:
– categoryscreen
Dit scherm levert een overzicht van de programma’s ingedeeld naargelang hun cate-
gorie.
– currentscreen
Hier worden alle programma’s weergegeven die zich afspelen op het moment van
opvragen.
– fulloverviewscreen
In dit scherm wordt een volledig overzicht van alle tv- en radioprogramma’s weerge-
geven.
– mainscreen
Dit is het hoofdscherm van waaruit men toegang heeft tot alle overige schermen.
– navigatorscreen
Deze package bevat de informatieverkenner.
– plannerscreen
Het herinneringenoverzicht, een scherm waar men deze kan beheren.
– pvrscreen
Het PVR-scherm dat niet geımplementeerd is.
– searchscreen
In het zoekscherm kan de gebruiker aan de hand van kernwoorden het volledig pro-
grammaoverzicht doorzoeken.
– setupscreen
Het instellingenmenu levert de gebruiker de mogelijkheid om de taal in te stellen, het
3.3 Modulair overzicht van de algemene architectuur 18
uitzicht te personaliseren, de volgorde van de zenders in te geven en de terugkeerka-
naalparameters in te geven.
– suggestionscreen
Hier kan men enerzijds suggesties opvragen en anderzijds de initiele voorkeuren door-
geven.
– vodscreen
De virtuele videotheek levert films en live events.
• importmodule
Het importeren van de nodige gegevens gebeurt hier in de importeermodule.
• mainmodule
De hoofdmodule, het hart van de applicatie, bevindt zich in deze package.
3.3 Modulair overzicht van de algemene architectuur
Op de volgende pagina bevindt zich een modulair overzicht van de architectuur. De pijlen tonen
de interacties tussen de verschillende modules aan. De PVR-module is niet langer opgeno-
men. Wegens hardwarematige redenen (geen set-top box met PVR-ondersteuning beschikbaar
in het testlabo) hebben we dit laten vallen. De opnamefunctie is echter volledig in de appli-
catie ingebakken zodat het volstaat een PVR-module te ontwikkelen en deze te linken aan de
hoofdmodule.
Dit boek is grotendeels opgesplitst volgens de modulaire architectuur. Aangezien elke module
een bundeling van gelijkaardige functionaliteiten is, is het handig om ook deze module per
module te bespreken. Hoe belangrijker de module in het opzicht van uitbreiding is, hoe dieper
en gedetailleerder er op de materie ingegaan wordt. Indien men later de applicatie uitbreidt, is
het nodig om de werking van sommige interne systemen goed te kennen. De client connection
module is hier een mooi voorbeeld van. Elke module maakt gebruik hiervan en bijgevolg is
het nuttig om deze module wat dieper uit te werken. Per module wordt de algemene functie
ervan geschetst. Verder worden de mogelijke technologieen, systemen, API’s, . . . overlopen en
indien nodig de keuzes verantwoord. Dit wordt vaak gevolgd door een bespreking van het intern
systeem en de implementatie ervan.
3.3 Modulair overzicht van de algemene architectuur 19
Figuur 3.1: De modulaire architectuur van de EPG.
BESPREKING VERSCHILLENDE MODULES 20
Hoofdstuk 4
Bespreking verschillende modules
4.1 Main Module
De hoofdmodule is de controlerende entiteit binnen de applicatie. Zij initialiseert alle modules
en stuurt deze aan. Er is een overkoepelende interface ontwikkeld zodat elke module op dezelfde
manier aangesproken wordt: de EPGmodule. Deze bevat twee funties:
• public void init();
In deze functie wordt de module geınitialiseerd.
• public void stopAndDestroy();
Hier wordt de werking van de volledige module stopgezet en het verbruikt geheugen vrijgegeven.
De hoofdklasse XletEPG bevat alle controlerende eenheden van de modules en heeft deze
gesorteerd in een rij van EPGmodule-objecten. Het toevoegen van een nieuwe module is geen
enkel probleem. Deze moet enkel aan de EPGmodule-interface voldoen. Indien ze ook resultaten
van het terugkeerkanaal wil ontvangen, moet ze ook de RCReceiveInterface implementeren. Deze
interface wordt verder uitvoerig besproken in de client connection module (zie 4.2.2 op p 30).
Het UML-schema van de hoofdmodule is terug te vinden in D.1.
4.1.1 Configuratiegegevens
De configuratiegegevens voor de applicatie kunnen op een server opgeslagen en bijgevolg ook
opgevraagd worden. De applicatie slaat deze gegevens niet in het geheugen van de set-top box
op omdat dit geheugen niet blijvend is. Later kan men dit natuurlijk eenvoudig uitbreiden zodat
deze gegevens zich in het blijvend geheugen van de set-top box zullen bevinden.
4.1 Main Module 21
Door de functie getConfigData() op de ClientConnectionInterface op te roepen, kan de hoofd-
module de configuratiegegevens aan de configuratieserver opvragen. De client connection mo-
dule levert een ConfigObject als antwoord. Deze bevat alle nodige gegevens zoals de taal, de
terugkeerkanaalparameters, de IP-adressen en poortnummers van de verschillende servers en de
volgorde van de tv- en radiozenders. De XletEPG-klasse zal deze gegevens verder verspreiden
over de geınteresseerde modules.
4.1.2 Xlet interface
De XletEPG-klasse is de hoofdklasse en bijgevolg implementeert deze de Xlet-interface. Deze
interface bevat de vier belangrijke functies opdat de application manager de levensloop van de
Xlet zou kunnen aansturen:
• initXlet
• startXlet
• pauseXlet
• destroyXlet
Xlets hebben een gelijkaardige werking als Applets. Ze worden aangestuurd door een application
manager die zich in de middleware van de set-top box bevindt. Er kunnen meerdere Xlets naast
elkaar werken, bijgevolg is een goede coordinatie geen overbodige luxe. Een Xlet kan zich in vier
verschillende fasen bevinden. Hieronder een schema om dit duidelijker te maken:
Figuur 4.1: De vier fasen waarin een Xlet zich kan bevinden en de mogelijke overgangen ertussen.
4.1 Main Module 22
Van zodra de Xlet-klasse ingeladen is, bevindt deze zich in de loaded-fase. Wanneer de
gebruiker de applicatie opstart (of de Xlet is gesignaleerd als automatisch opstarten), dan zal de
application manager de initXlet()-functie op de Xlet oproepen. Deze initialiseert zichzelf en komt
in de paused-fase terecht. Daarna wordt de startXlet()-functie opgeroepen en gaat de applicatie
over in de started-fase. De Xlet is nu klaar om gebruikt te worden. Tijdens het gebruik van de
applicatie kan de application manager de Xlet vragen over te gaan naar de paused-fase. Tijdens
deze fase wordt de Xlet opgedragen zoveel mogelijk systeembronnen vrij te geven zodat andere
applicaties hiervan gebruik kunnen maken. Wanneer de startXlet()-functie opnieuw opgeroepen
wordt, wordt de Xlet terug actief. Om de Xlet definitief volledig af te sluiten, moet men de
destroyXlet()-functie oproepen.
4.1.3 Herinneringen
De EPG levert de mogelijkheid om herinneringen voor welbepaalde programma’s in de toekomst
in te stellen. Op die manier kan de gebruiker als het ware z’n volledige tv-avond samenstellen.
Wanneer de herinnering afloopt, komt er een melding op het scherm en speelt er een deuntje.
Wanneer de gebruiker zich elders bevindt, kan hij dankzij het geluidje toch op de hoogte ge-
bracht worden van de herinnering.
Een melding verschijnt telkens twee minuten voor het programma werkelijk gaat beginnen. Dan
heeft de gebruiker keuze uit drie mogelijkheden. Ofwel schakelt hij onmiddellijk over naar deze
zender, ofwel laat hij de EPG automatisch overschakelen wanneer dit programma effectief zal
beginnen, ofwel negeert hij de herinnering en verwijdert deze.
Er bestaat een volledig uitgewerkt scherm dat de mogelijkheid biedt om een overzicht te beko-
men van de herinneringen die momenteel ingesteld staan. De gebruiker kan er herinneringen
verwijderen, instellen dat het programma opgenomen moet worden en de programma’s instellen
zodat de EPG al dan niet automatisch zal overschakelen wanneer ze beginnen.
Intern Systeem
De hoofdklasse binnen de package planner is de klasse Planner. Deze bevat een lijst van program-
ma’s waarvoor een herinnering is ingesteld. Er wordt gebruik gemaakt van de TVTimer -klasse
uit de JavaTV API om de timer-functionaliteiten te realiseren. Het UML-schema bevindt zich
in D.2.
Er kan slechts een TVTimer -object opgevraagd worden. Bijgevolg is het niet mogelijk om sim-
4.1 Main Module 23
pelweg voor elke herinnering een timer aan te maken. De verschillende herinneringen worden
eerst chronologisch gesorteerd. Daarna wordt de timer ingesteld op de herinnering die het eerst
zal aflopen. Wanneer deze afloopt, wordt de timer simpelweg op de volgende herinnering inge-
steld. Op die manier kan een TVTimer -object alle herinneringen verwerken.
De configuratie van de TVTimer gebeurt aan de hand van een TVTimerSpec-klasse. Deze klas-
se is uitgebreid tot een TVProgramTimerSpec door het programma waarvoor de herinnering
ingesteld is als extra variabele eraan toe te voegen. Wanneer de timer afloopt, wordt er een
TVTimerWentOffEvent gegenereerd, dewelke de TVProgramTimerSpec bevat. Die event wordt
opgevangen door de klasse TVTimerListener die de TVTimerWentOffListener implementeert.
Deze verwittigt de Planner -klasse door de functie firstTimerHasWentOff() op te roepen.
Wanneer de firstTimerHasWentOff()-functie opgeroepen wordt, wordt er een venster gecreeerd
dat de melding weergeeft. Het inladen van het geluid zorgt voor een kleine vertraging. Het
geluidsfragment is een mp2-bestand. MHP ondersteunt namelijk slechts een formaat voor ge-
luidsfragmenten: MPEG-1 layer 1 of layer 2, met de beperkingen zoals beschreven in [8]. Dit
venster wordt bovenop het huidig scherm geplaatst, door deze bovenop de hoogste component
op de hoofdcontainer te plaatsen. Dit is de component met index 0.
4.1.4 Initialisatiefase
Eerst en vooral worden de controllers van de verschillende modules gecreeerd. Deze worden
samengebracht onder een rij van EPGmodule-objecten. Daarna worden ze allen geınitialiseerd
door op elk object de functie init() op te roepen.
In een tweede stap start men de thread op die de nodige gegevens zal importeren. Dit moet
immers zo vroeg mogelijk gebeuren om de vertraging door het importeren zo klein mogelijk te
houden. Wanneer de applicatie volledig opgestart is, zal hierdoor het grootste gedeelte van de
gegevens reeds opgehaald zijn.
Daarna reserveert de hoofdklasse de systeembronnen voor de verschillende schermlagen en
plaatst een afbeelding in de achtergrond.
In de laatste stap maakt deze het HScene-object aan. Een HScene is een AWT-Container waarin
de applicatie zijn componenten kan plaatsen om deze zichtbaar te maken voor de gebruiker om
zo voor interactie te zorgen. De HScene bevindt zich op het hoogste niveau binnen de grafische
hierarchie. Het genereren van de HScene gebeurt aan de hand van een template. Eerst ontwik-
kelt men een HSceneTemplate met een aantal eigenschappen zoals de grootte en de positionering
4.1 Main Module 24
van de scene op de fysieke beeldbuis. Daarna vraagt men de HSceneFactory een HScene-object
te leveren die zo goed mogelijk voldoet aan de template. De GraphicalController, tevens een
AWT-Container wordt vervolgens aan de geleverde HScene toegevoegd. Alle overige containers
en componenten worden in de toekomst aan de GraphicalController toegevoegd om zo voor een
duidelijke structuur te zorgen.
4.1.5 Dirigerende functie
De hoofdmodule heeft als hoofdzaak de verschillende modules te coordineren. Wanneer bij-
voorbeeld in de grafische module er een opdracht gegeven wordt om over te schakelen naar een
ander kanaal, wordt deze opdracht doorgegeven aan de hoofdmodule. Deze module stuurt de
afspeelmodule aan om de aanvraag te voltooien en speelt deze actie ook door aan de sugges-
tiemodule om zo de acties van de gebruiker bij te houden voor verdere analyse. De grafische
module hoeft dus helemaal geen rekening te houden met het doorspelen van de gebruikersacties
naar de suggestiemodule, de hoofdmodule zorgt hiervoor.
De hoofdmodule vormt dus vaak de link tussen twee of meerdere verschillende modules. Dit
heeft als grote voordeel dat het systeem op een zeer gecontroleerde en transparante manier te
werk gaat. Elke aanvraag tot het overschakelen naar een ander kanaal, of tot het opnemen
van een programma, of tot het toevoegen van een herinnering eindigt in een functie van de
hoofdmodule. Vanuit deze functie vertrekt er verder een aanvraag naar de module die deze
aanvraag verder kan verwerken. Zo kan bijvoorbeeld zeer eenvoudig een PVR-module toegevoegd
worden. Men moet enkel voor een link tussen de functie recordProgram() en de PVR-module
zorgen. Mochten er meerdere communicatiewegen zijn, zou dit echter helemaal niet zo eenvoudig
zijn. . .
De MainControllerInterface bundelt twee groepen van functies: de functies opgeroepen door
de grafische module en de functie opgeroepen door de importeermodule. De importeermodule
heeft slechts een functie ter beschikking. De functie notifyImportMessage(int type) dient om de
hoofdmodule op de hoogte te houden indien er een importeerfase afgewerkt is.
De grafische module heeft daarentegen heel wat meer functies ter beschikking. De belangrijkste
zijn: het overschakelen naar een zender, het opnemen van een programma en het toevoegen
of verwijderen van een herinnering. De overige functies dienen om een aantal suggesties op te
vragen, om de Xlet af te sluiten of om de focus terug te geven aan het laatst gebruikte scherm.
4.2 Client Connection Module 25
De Planner -klasse gebruikt deze laatste functie. Wanneer deze klasse een grafische melding op
het scherm doet verschijnen, verkrijgt dit venster focus om te kunnen luisteren naar KeyEvents.
Na het sluiten van deze melding, moet de focus natuurlijk teruggegeven worden aan het scherm
dat de focus had voor die melding. Hiervoor dient dus de functie giveFocusToPreviousScreen().
4.1.6 Starten van de applicatie
De applicatie start in een onzichtbare mode. Op die manier worden alle gegevens mooi geımporteerd
zonder dat de gebruiker er iets van merkt. Zodra de gebruiker op de EPG-toets drukt, komt de
EPG tevoorschijn en levert hij de nodige functionaliteiten.
4.2 Client Connection Module
Verschillende modules zullen gebruik maken van het terugkeerkanaal om interactief gegevens te
versturen en/of te ontvangen. Wanneer men bijvoorbeeld extra informatie over een film wil, dan
wordt deze opgevraagd bij een externe filmdatabank. Of wanneer het systeem de acties van de
gebruiker registreert om zelflerend te zijn, dan worden deze gegevens naar een externe server
verstuurd.
Opdat de verschillende modules het terugkeerkanaal op een heel eenvoudige manier zouden
kunnen gebruiken, is er een aparte module ontwikkeld die heel dit gebeuren zal uitvoeren en
coordineren: de client connection module.
Deze module bevat een asynchroon systeem. Een aanvraag wordt er gedeponeerd, verwerkt
en het antwoord wordt asynchroon terug naar de aanvragende module gestuurd.
De ene aanvraag zal natuurlijk belangrijker zijn dan de ander. Het opvragen van filminformatie
heeft bijvoorbeeld een hogere prioriteit dan het registreren van gebruikersacties. De tevredenheid
van de gebruiker hangt namelijk grotendeels af van de wachttijden. Opdat een aanvraag voor
filminformatie niet nutteloos zou moeten wachten op de verwerking van gebruikersacties, is het
systeem voorzien van een priority scheduler. Er zijn drie mogelijke prioriteiten: hoog, medium
en laag.
4.2.1 Return Channel Request Protocol (RCRP)
Het systeem kent verschillende mogelijke aanvragen (filminformatie, gebruikersacties, configu-
ratiegegevens, . . . ). Bij de ene zal er een XML-bestand verstuurd worden, bij de ander volstaat
4.2 Client Connection Module 26
een eenvoudig commando. Daarnaast moet elke aanvraag over een id beschikken zodat intern
in het systeem, deze eenvoudig kan bijhouden welke module welke aanvraag deed. Om dit alles
soepel te laten verlopen, is het Return Channel Request Protocol (RCRP) ontwikkeld.
Deze bevat 4 veldjes.
• ID : 2 bytes. Per byte zijn er slechts 7 bits geldig (Java Byte system). Hierdoor zijn er
maximaal 127 x 127 = 16255 mogelijke id’s. Dat zou ruimschoots moeten volstaan.
• RequestType: 1 byte : dit is het type van aanvraag
– movie information server
– user suggestion server
– configuration server
– VoD-server
– LE-server
• RequestSubType: 1 byte : dit zorgt voor een opdeling binnenin het type
– movie information server
∗ basisinformatie
∗ vorige + cast
∗ vorige + korte beschrijving
∗ vorige + foutjes in de film
∗ vorige + opmerkelijke uitspraken
– user suggestion server
∗ registratie gebruikersactie
∗ registratie initiele suggestievoorkeuren
∗ opvragen van alle verwerkte gegevens
∗ opvragen van specifieke verwerkte gegevens
– configuration server
∗ alle configuratiegegevens opvragen
∗ taalvoorkeur
∗ terugkeerkanaalparameters
4.2 Client Connection Module 27
∗ IP & poortnummer van movie information server
∗ IP & poortnummer van de configuration server
∗ IP & poortnummer van de user suggestion server
∗ IP & poortnummer van de video on demand server
∗ IP & poortnummer van de live event server
∗ volgorde televisieprogramma’s
∗ volgorde radioprogramma’s
∗ volgorde televisie- & radioprogramma’s
– VoD server
∗ lijst met VoD films opvragen
∗ VoD film bestellen
∗ play
∗ pauze
∗ stop
∗ vooruitspoelen
∗ achteruitspoelen
– LE server
∗ lijst met live events opvragen
∗ live event bestellen
∗ play
∗ pauze
∗ stop
∗ vooruitspoelen
∗ achteruitspoelen
• PayloadType : 1 byte (karakter), geeft aan in welke vorm de payload staat
– C: commando
– X: XML
– U: user suggestion
– H: http
4.2 Client Connection Module 28
– S: SQL-statement
• Payload zelf. Dit heeft natuurlijk een variabele lengte en bevat de eigenlijke gegevens die
verstuurd worden.
iDTV-Applicaties kunnen dit protocol heel algemeen invullen en bijgevolg het gemakkelijk
overnemen. De requesttypes en -subtypes kan men zelf naar eigen goeddunken invullen en ze
zorgen ervoor dat de server onmiddellijk weet welke gegevens de client nodig heeft, indien hij
ook dit protocol ondersteunt en dezelfde conventies qua types en subtypes hanteert.
Het protocol heeft een header van slechts 5 bytes. De verschillende aanvragen kon men evengoed
via een XML-bestand aan de server doorgeven, maar dan zou de overhead veel groter zijn.
Omwille van performantieredenen werd dit hier zo kort en snel mogelijk gehouden.
4.2.2 Interne Architectuur
Het UML-schema van deze interne architectuur is afgebeeld in D.3.
RequestCollector
De hoofdklasse uit de client connection module is de RequestCollector -klasse. Deze implemen-
teert twee verschillende interfaces, nl. EPGmodule en ClientConnectionInterface. Deze laatste
bevat alle mogelijke functies die de aanvragen voor het terugkeerkanaal regelen. Dit gaat van
de gekende aanvragen zoals filminformatie, VoD, live events en dergelijke tot informatie bij
algemene servers, webservers, . . .
Een overzicht van de mogelijke functies:
• public void logUserAction(String logToSend);
• public void logUserPreferences(String prefsToSend);
• public int getDataUserSuggestion(short moduleID, byte reqSubType, String payload);
• public int getConfigData(short moduleID, byte reqSubType);
• public int getMovieInfo(short moduleID, String title, byte reqSubType, short priority);
• public int getVODinformation(short moduleID, int VODid, byte reqSubType, short prio-
rity);
4.2 Client Connection Module 29
• public int getLEinformation(short moduleID, int LEid, byte reqSubType, short priority);
• public void doVODaction(short moduleID, int VODid, byte reqSubType);
• public void doLEaction(short moduleID, int VODid, byte reqSubType);
• public int getDataWebServer(short moduleID, String IPwebServer, int portNr, short pri-
ority, byte reqType, byte reqSubType, String payload, char payloadType);
• public void sendDataToServer(String IPserver, int portnr, short priority, byte reqType,
byte reqSubType, String payload, char payloadType, boolean RCRPon);
• public int getDataCommonServer(short moduleID, String IPserver, int portNr, short pri-
ority, byte reqType, byte reqSubType, String payload, char payloadType);
De drie laatste functies laten toe om gegevens uit te wisselen met servers die RCRP niet onder-
steunen. Het gebruik van dit protocol is dus helemaal geen vereiste!
De RequestController heeft drie buffers, elk met hun specifieke prioriteit. Een aanvraag
wordt omgezet naar een object van de klasse RequestItem en wordt naargelang de prioriteit in
de juiste buffer opgeslagen. Een RequestItem bevat alle gegevens die nodig zijn om deze verder
af te werken.
• id van de request
• id van de module die de aanvraag deed
• IP-adres en poortnummer van de server
• requesttype en -subtype
• payloadtype
• payload
• bijhouden indien al dan niet antwoord verwacht wordt
• bijhouden indien RCRP al dan niet gebruikt wordt.
Wanneer een van de huidige servers (VoD, LE, user suggestion , configuration) gebruikt wordt,
dan wordt het nodige IP-adres en poortnummer opgevraagd uit de RCCommonConfiguration-
klasse. In het ander geval worden deze meegeleverd als functieargument.
4.2 Client Connection Module 30
De klassen RCRequestType, RCRequestSubType, PayloadType en RequestPriority bevatten
een tekstuele representatie van de verschillende bytewaarden aan de hand van static final vari-
abelen. Dit zorgt voor een eenvoudiger gebruik en verhoogt de leesbaarheid van de code.
RCReceiveInterface
Enkel de controller van een module kan een aanvraag deponeren op voorwaarde dat hij de
RCReceiveInterface implementeert. Deze bevat slechts drie functies:
• public void registerUnprocessedRCreply(int ID, byte reqType, byte reqSubType, String
answer, char payloadType);
• public void registerProcessedRCreply(int ID, Object answer);
• public void registerRCError(int ID, int error);
De module krijgt dus ofwel een antwoord ofwel een foutmelding. Meestal wordt dit antwoord
omgezet naar een object. In de overige gevallen, levert men het antwoord zoals deze verkregen is
van de server. De decimale waarde van de eventuele foutmelding kan via de klasse RCErrorInfo
omgezet worden naar een tekstuele representatie.
Deze interface zorgt voor een eenvoudige uitbreidbaarheid van het systeem. Wanneer er een
nieuwe module toegevoegd wordt, moet deze enkel de RCReceiveInterface implementeren om
de client connection module te kunnen gebruiken. De communicatie tussen de client connection
module en de overige modules verloopt telkens via de controller van deze modules. De controllers
geven het verkregen antwoord door aan de klasse die de aanvraag deed binnen hun eigen intern
systeem.
Wanneer bijvoorbeeld in de grafische module, het VoD-scherm filminformatie wil opvragen,
dan zal hij deze aanvraag afgeven aan de GraphicalController, die op zich de aanvraag deponeert
bij de de client connection module. Wanneer deze laatste het antwoord verkregen heeft, levert
hij deze af bij de GraphicalController, die dit antwoord doorgeeft aan het VoD-scherm.
Dit kan omslachtig lijken, maar dit zorgt wel voor een robuust systeem. Er hoeven nergens
aanpassingen doorgevoerd te worden wanneer men een nieuw scherm toevoegt aan de grafi-
sche module. Indien dit nieuwe scherm immers externe informatie via het terugkeerkanaal wil
opvragen, deponeert hij simpelweg deze bij de GraphicalController.
4.2 Client Connection Module 31
RequestProcessor
Het belangrijkste onderdeel van de RequestCollector is de klasse RequestProcessor. Dit is een
thread die op regelmatige tijdstippen de RequestItems ophaalt, verwerkt en terugstuurt naar de
juiste module.
De thread vraagt de RequestItem met de hoogste prioriteit op. Indien RCRP gebruikt wordt,
dan gaat hij eerst de header ervan initialiseren. Daarna vult hij de payload op en verstuurt hij
de aanvraag over het IP-netwerk. Het effectief versturen op socketniveau wordt verzorgd door de
TcpSocketClient-klasse. Indien nodig, wacht hij op het antwoord van de server. Dit antwoord,
vaak in XML-vorm, zal daarna in de meeste gevallen geconverteerd worden tot een klasseobject.
Dit gebeurt door de klasse FormatConvertor. De RequestProcessor bevat een lijst met referenties
naar de verschillende modules die de RCReceiveInterface implementeren. Het antwoord, al dan
niet omgezet tot een klasseobject, wordt aan de hand van die referenties teruggestuurd naar de
oorspronkelijke module. Wanneer er ergens een fout optreedt, wordt de desbetreffende foutcode
doorgegeven aan de ontvangende module.
Het grootste gedeelte van de tijd zal deze verwerkingsthread geen werk verrichten. Ze moet
bijgevolg dan ook niet onnodig systeembronnen verspillen. Dit moet dus zo efficient mogelijk en
natuurlijk zonder gevaar voor deadlocks! De thread verwerkt onophoudelijk de elementen uit de
buffer tot deze leeg is. Daarna zou men de thread kunnen blokkeren en het verder zetten wanneer
er een element toegevoegd wordt. Maar het gebruik van suspend() en resume() impliceert een
groot risico op deadlocks. In het algemeen wordt het gebruik ervan ten strengste afgeraden.
Wanneer suspend() opgeroepen wordt binnen een gesynchronizeerd gedeelte, dan wordt deze
lock behouden en zal de thread blokkeren. Hierdoor kan het voorkomen dat een andere thread
wacht op toestemming om die bronnen te gebruiken en bijgevolg de eerste thread nooit kan laten
verder werken.
Om dit euvel te verhelpen, maak het systeem gebruik van de functies sleep() en interrupt().
Zodra de buffer leeg is, gaat de thread voor een lange tijd, zo’n 100 seconden, slapen. Wanneer
een module een element aan de buffer toevoegt, wordt deze thread onmiddellijk wakker gemaakt
opdat ze deze aanvraag kan verwerken. De thread blijft nooit langer dan de vooropgestelde tijd
slapen. Op die manier worden deadlocks uitgeschakeld.
4.3 Import Module 32
TcpSocketClient
De TcpSocketClient verzorgt de verbinding op socketniveau. Op die manier wordt deze laag
weggeabstraheerd. Een TcpSocketClient-object wordt geınitialiseerd aan de hand van een IP-
adres en een poortnummer. De nodige methodes zoals de verbinding opzetten of afsluiten en
het versturen en ontvangen van een byte array, String en int zijn er beschikbaar.
FormatConvertor
Configuratiegegevens, filminformatie en suggestiegegevens worden over het IP-netwerk in XML-
formaat verstuurd. Bij ontvangst worden deze geparset en omgezet naar het desbetreffende
klasseobject. Om de ontvangende klasse van deze taak te ontslaan, wordt dit in de klasse
FormatConvertor gedaan. Deze maakt gebruik van de nanoxml-package (NanoXML 2 Lite
versie). Dit is een lichtgewicht XML-parser, geschikt voor low-resource applicaties zoals Xlets.
4.3 Import Module
Het ophalen van de nodige informatie wordt geregeld door de importeermodule.
4.3.1 Opstarttijd
De belangrijkste taak is ongetwijfeld het importeren van de metadata. Dit is immers de data
waarmee het programma werkt. Dit levert al meteen een eerste probleem op. De data moet eerst
opgehaald worden alvorens het programma kan starten. Dit moet bijgevolg zo snel mogelijk ge-
beuren. Om de latentie hiervan zoveel mogelijk verborgen te houden, verloopt het importeren in
verschillende fasen. Eerst worden alle programma’s die zich op dit ogenblik afspelen opgehaald.
Experimenteel is gebleken dat er voor een honderdtal zenders hiervoor slechts een kleine zeven
seconden nodig zijn. Daarna verloopt dit importeerproces verder met alle programma’s volgend
op de huidige programma’s, dan de huidige radioprogramma’s, vervolgens alle overige toekom-
stige tv-programma’s, eindigend met alle overige radioprogramma’s. Dit importeren gebeurt in
parallel met het opstarten van de Xlet zelf. Op die manier is er slechts een kleine latentie.
De EPG start in een onzichtbare mode. In deze mode haalt de applicatie alle gegevens binnen
zonder dat de gebruiker ook maar iets van de vertraging merkt. Via de EPG-toets kan de ge-
bruiker de EPG tevoorschijn laten komen. Indien nog niet alle gegevens geımporteerd zijn, dan
kan men bladeren tussen de verschillende programma’s die zich op dit ogenblik afspelen, terwijl
4.3 Import Module 33
de overige programma’s verder binnengehaald worden. Deze vertraging volledig wegwerken is
momenteel technologisch gezien niet mogelijk. Het kan wel heel wat verbeterd worden door
bijvoorbeeld het gebruik van interne cache in de set-top box. Meer uitleg hierover in 4.3.7.
4.3.2 Metadata
Een EPG heeft als belangrijkste functie informatie geven over tv-programma’s. Deze informatie
moeten veel verder reiken dan enkel een klein tekstje met de korte inhoud ervan. Gegevens
zoals bijvoorbeeld kijkcijfers kunnen een meerwaarde betekenen. De EPG zal de gebruiker ook
extra programmaspecifieke gegevens leveren. Bijvoorbeeld bij programma’s zoals Big Brother
is het mogelijk om allerlei weetjes, nominatiegegevens en dergelijke op te vragen. Bij films
bijvoorbeeld kan men communiceren met een filmdatabank zoals IMDb om de regisseur, de
acteurs en actrices, het waarderingscijfer, . . . op te vragen en kan zelfs eventueel ook een trailer
aangeboden worden.
Eerst wordt de service informatie (SI) gelezen uit de broadcast stroom. Daarna gaat het
systeem na van welke programma’s men nog extra informatie kan opvragen. Het ophalen zelf
echter gebeurt slechts wanneer een gebruiker dit daadwerkelijk aanvraagt. Zodoende wordt er
geen extra informatie opgehaald die de gebruiker niet nodig heeft. We moeten immers rekening
houden met een eindig intern geheugen. De verschillende taken worden zoveel mogelijk uitge-
voerd in verschillende, parallel lopende threads. Op die manier kan men de latentie zo laag
mogelijk houden. De importeermodule zal dus zijn gegevens vanuit verschillende technologische
locaties halen, dewelke beschreven staan in 4.3.3, 4.3.4, 4.3.5 en 4.3.6.
4.3.3 Broadcast stroom
Vooraleerst is er de broadcast stroom die service information (SI) bevat. Deze levert de standaard
gegevens van een programma zoals de naam, het genre, de starttijd en de duur, de rating en ook
een kleine beschrijving. Het genre kan men aflezen uit de ”content descriptor”, die een hoofd-
en een subcategorie onderscheidt (zie [11]).
De SI-gegevens worden opgevraagd via asynchrone requests. Hiervoor bestaan er 2 verschil-
lende API’s, namelijk de DVB SI API en de JavaTV API. Het grote verschil tussen beide is dat
DVB SI toegang verleent tot alle SI-tabellen. JavaTV daarentegen is veel algemener. Ze kan ook
gebruikt worden in een OCAP-systeem. Ze werkt niet op niveau van SI-tabellen, maar werkt
4.3 Import Module 34
eerder met een taakgebaseerde aanpak. Je vraagt bijvoorbeeld de services op en ze worden je
geleverd. Hoe dit in de tabellen opgeslagen is, hoef je niet te weten. JavaTV heeft als groot
nadeel dat het geen toegang heeft tot op het descriptor-niveau. En dit is onontbeerlijk wanneer
men bijvoorbeeld het genre van een programma wil opvragen.
DVB SI API
De DVB SI API verleent je toegang tot alle SI-tabellen die deel uitmaken van de standaard
DVB SI-specificatie([10], [11]). We vertrekken van een databank die alle SI-tabellen bevat: de
SIDatabase. Deze bevat in feite niet alle SI-gegevens, maar heeft de mogelijkheid om deze op
te vragen. Door het oproepen van de statische functie getSIDatabase() op de singleton-klasse
SIDatabase bekomt men dit object. Nu kunnen we alle mogelijke tabellen opvragen, alsook het
toevoegen van verschillende soorten listeners, maar later hierover meer.
De kabel bestaat uit een aantal transportstromen. Deze bevatten elk op zich een aantal ser-
vices, vergelijkbaar met een zender binnen analoge tv. Binnenin zo’n service worden een aantal
events gedefinieerd, vergelijkbaar met een programma. Deze objecten worden voorgesteld door
de klassen SIService en SIEvent respectievelijk. Het opvragen van de nodige gegevens gebeurt
hierarchisch. Eerst worden de services opgevraagd en daarna, de events van de verkregen servi-
ces.
Via de functie retrieveSIServices(short retrieveMode, Object appData, SIRetrievalListener lis-
tener, int originalNetworkId, int transportStreamId, int serviceId, short[] someDescriptorTags)
kunnen alle Services voor een bepaald netwerk, voor een bepaalde transportstroom en met een
bepaalde service-id opgevraagd worden. Wanneer we -1 als transportstroom-id en als service-id
meegeven, dan bekomen we alle services over alle transportstromen. We hoeven dus enkel het
originele network-id op te vragen. Deze bekomen we door de functie retrieveActualSINetwork()
op te roepen.
Het volledig DVB SI-systeem werkt aan de hand van asynchrone aanvragen. De SI wordt
aan de SIDatabase opgevraagd. Deze zoekt deze gegevens op en bezorgt ze aan een SIRetrieval-
Listener. Verder kan er bij die aanvraag ook een zelf te definieren object AppData meegegeven
worden om de programmeur de mogelijkheid te bieden de SIRetrievalListener extra informatie
te verschaffen opdat die zo de ontvangen gegevens zou kunnen verwerken.
De SIDatabase kan deze gegevens op verschillende manieren ophalen. De retrieveMode-parameter
4.3 Import Module 35
uit de aanvraag bepaalt deze. Er zijn drie mogelijkheden:
• gegevens enkel uit de cache halen
• de gegevens enkel uit de stroom halen
• eerst in de cache kijken, zit het niet in de cache, dan pas uit de stroom halen
Indien men de gegevens uit de cache haalt, dan worden deze logischerwijze veel sneller bekomen
dan wanneer men ze uit de stroom haalt. Het nadeel is natuurlijk dat ze mogelijks verlopen
kunnen zijn.
Wanneer men een SIService-object bekomt, is het mogelijk via dit object de SIEvents ervan
op te vragen. Dit gebeurt in drie stappen (voor de duidelijkheid zijn de functieargumenten
weggelaten)
• het huidig programma: retrievePresentSIEvent()
• het programma daarop volgend : retrieveFollowingSIEvent()
• alle toekomstige programma’s binnen bepaald interval: retrieveScheduledSIEvents()
Verder is het ook mogelijk het type van de Service op te vragen. De verschillende mogelijkheden
zijn : digitale tv, digitale radio, Pal, Secam, NTSC, FM radio, . . . (zie [11])
Gegevens als id, naam, locator, en dergelijke kunnen natuurlijk ook opgevraagd worden.
Een SIEvent bevat alle nodige gegevens over een programma, zoals het genre, de duur, de
start- en eindtijd, de DvbLocator, de running status, een korte beschrijving, . . . Het genre wordt
bekomen door de twee content-nibbles op te vragen. Men bekomt een byte die opgesplitst wordt
in twee nibbles: de vier meest en minst significante bits. De meest significante bits stellen het
type voor en de minst significante het subtype zoals deze gedefinieerd zijn in [11].
De bekomen resultaten worden zoals eerder vermeld telkens doorgespeeld aan een object die
de interface SIRetrievalListener implementeert. Deze interface bevat slechts een functie: public
void postRetrievalEvent(SIRetrievalEvent event). De klasse SIRetrievalEvent heeft een aantal
subklasses, waaronder de klasse SISuccessfulRetrieveEvent. Wanneer het ontvangen object van
dit type is, betekent dit dat de aanvraag gelukt is en kan men de resultaten bekomen via de
functie getResults(). De overige subklassen wijzen op de oorzaak van het falen zoals bijvoorbeeld
SILackOfResourcesEvent, SITableNotFoundEvent, . . .
4.3 Import Module 36
Via het SIRetrievalEvent-object kan men het eerder meegestuurde AppData-object bekomen om
zo de verwerking van de ontvangen resultaten verder af te werken.
De SI-gegevens zijn helemaal niet statisch. Wat op het ene tijdstip een toekomstig pro-
gramma is, kan op een later tijdstip een huidig programma zijn. Om deze veranderingen in de
programmatie op te vangen kan men een SIMonitoringListener toevoegen aan de SIDatabase.
Wanneer er een verandering optreedt, ontvangt deze listener een SIMonitoringEvent. Deze event
bevat een SIMonitoringType dewelke aangeeft over welke soort verandering het gaat. De ver-
schillende mogelijkheden zijn: Service, Present Following Event, Scheduled Event, PMT Event,
Network en Boucquet. Dankzij deze listener is het niet nodig om op geregelde tijdstippen alles
opnieuw te importeren, maar enkel de gegevens die veranderd zijn op te halen. Dit maakt het
heel wat efficienter en zorgt ervoor dat het systeem altijd de meest recente gegevens bevat.
JavaTV API
De JavaTV API werkt op een andere manier. Deze API werkt zowel op het MHP-platform als
op het OCAP-platform, dat vooral in de Verenigde Staten enorm aan populariteit inwint. In
JavaTV vertrekt men van de SIManager. Dit is in tegenstelling tot de SIDatabase uit de DVB
SI API geen singleton klasse. Deze bevat immers alle service information in een welbepaalde
taal. Wanneer men de SI in verschillende talen wil, dan moet men meerdere instanties van de
SIManager creeren.
Het systeem van aanvragen is grotendeels dezelfde als deze in de DVB API. Ze werkt ook
met asynchrone requests. De resultaten worden echter doorgegeven aan een klasse die de SIRe-
questor -interface implementeert. Deze interface bevat twee functies:
• public void notifySuccess(SIRetrievable[] result)
Deze functie wordt opgeroepen wanneer de aanvraag gelukt is en verkrijgt de resultaten
als parameter.
• public void notifyFailure(SIRequestFailureType reason)
Wanneer het opvragen mislukt is, wordt deze functie opgeroepen. De oorzaak van het
falen wordt er meegedeeld. Door deze klasse te voorzien van de nodige gegevens, kan men
de resultaten er verwerken.
Hier wordt er dus niet met een listener gewerkt die de nodige events ontvangt. Per aanvraag
4.3 Import Module 37
wordt er een SIRequestor -instantie gecreeerd die de resultaten van deze aanvraag zal verwer-
ken. Dit is een nadeel ten opzichte van het DVB SI-systeem waarbij er slechts een centrale
ontvangsteenheid bestaat. Per aanvraag wordt er een SIRequest-object geınstantieerd, dat als
parameter de SIRequestor meekrijgt. Om de request te annuleren, kan men de functie cancel()
op het SIRequest-object oproepen.
Wanneer men de verschillende services wil opvragen, geeft men een filter mee aan de SIMa-
nager. Deze geeft alle services die aan deze filter voldoen terug. Zo kan men bijvoorbeeld enkel
de digitale tv services opvragen. Vervolgens vraagt men van de Service de ServiceDetails op.
Door de functie getProgramSchedule() op de verkregen ServiceDetails los te laten, verkrijgen
we het object dat de verschillende events binnen de service bundelt: ProgramSchedule. Deze
klasse levert opnieuw een aantal functies om op een asynchrone manier alle nodige events op te
vragen:
• retrieveCurrentProgramEvent(SIRequestor requestor)
• retrieveNextProgramEvent(ProgramEvent event, SIRequestor requestor)
• retrieveFutureProgramEvents(java.util.Date begin, java.util.Date end, SIRequestor reques-
tor)
Om hier het programma volgend op het huidig programma op te vragen, moeten we een referentie
naar het huidig programma als parameter meegeven. Dit zorgt voor heel wat complicaties omdat
beide los van elkaar verwerkt worden.
Uiteindelijk bekomen we ProgramEvent-objecten. Deze bevatten alle nodige gegevens van een
programma, behalve de beschrijving. Deze moet weerom opgevraagd worden met een asynchrone
request: retrieveDescription(SIRequestor requestor).
Er zijn dus heel wat asynchrone aanvragen nodig om alle programma’s op te vragen. Startend
van een Service-object zijn er nog drie asynchrone aanvragen nodig: een voor de ServiceDetails,
een voor ProgramEvent en een voor ProgramEventDescription.
Het luisteren naar veranderingen in de SI gebeurt op een gelijkaardige manier zoals in de
DVB-benadering. Hier worden er echter verschillende listeners, elk luisterend naar specifieke
veranderingen toegevoegd (ProgramScheduleListener, ServiceDetailsChangeListener, . . . ). Elk
van deze listeners ontvangt slechts een soort Event, bijvoorbeeld de ProgramScheduleListener
4.3 Import Module 38
ontvangt enkel de ProgramScheduleEvent. Op die manier kan men enkel inschrijven op de events
waarin men geınteresseerd is.
Keuze
Ik ben begonnen met het importeren van SI via de JavaTV API. Het feit dat JavaTV niet tot
op descriptor-niveau reikt, was me toen nog onbekend. Het importeren gebeurt slechts in twee
fasen: de huidige programma’s en alle overige programma’s. Dit werkt voortreffelijk. Ik heb dit
uitgetest door de SI uit de kabel van Telenet op te vragen. De testapplicatie importeerde mooi
alle nodige informatie. Via het JMF-systeem kon ik vloeiend tussen de verschillende zenders
schakelen, met als opmerking dat enkel de niet-geencrypteerde zenders beeld leverden. Enkel het
systeem om programma’s op te vragen is geımplementeerd. Er wordt niet naar veranderingen
geluisterd.
Er zijn echter een serieus aantal grote nadelen aan de JavaTV API. Het opvragen van de SI
vergt erg veel asynchrone aanvragen. Dit kan makkelijk oplopen tot een paar honderdtal. Per
zender moeten er namelijk (2 * #events +1) aanvragen verstuurd worden. Er moet bijgevolg
heel goed bijgehouden worden in hoeverre er aanvragen gelukt of mislukt zijn om te kunnen
nagaan wanneer alles geımporteerd is. Wanneer er bijvoorbeeld geen ServiceDetails beschikbaar
zijn, moet er niet verder gewacht worden op de ProgramEvent gegevens en ook niet meer op de
ProgramEventDescription.
Het opvragen van het huidig en het daaropvolgend programma is essentieel voor de informa-
tieverkenner. Meer informatie over de informatieverkenner vindt u in 4.7.5 op pagina 65. Het
opvragen van het programma volgend op het huidige is zoals eerder vermeld heel wat complexer
dan via de DVB SI API. Het meest doorslaggevende nadeel is natuurlijk dat deze API niet tot
op descriptor-niveau reikt. Het opvragen van het genre is hierdoor onmogelijk, tenzij men zelf
deze API zou uitbreiden . . .
Dit alles leidde mij ertoe het importeersysteem verder en volledig uit te bouwen aan de hand
van de DVB SI API. Qua opbouw is deze heel wat eenvoudiger. In het labo is een teststroom
ontwikkeld door het opnemen van een transportstroom uit de kabel van telenet. Het importeren
werkt voortreffelijk wanneer dit op deze zelfgemaakte transportstroom gebeurt. Het importeren
van de SI-informatie uit de kabel van Telenet lukt echter niet via de DVB SI API. De oorzaak
hiervan is me tot op heden nog steeds onbekend. De API slaagt er niet in om er de services te
4.3 Import Module 39
ontdekken.
4.3.4 LE- & VoD-server
Deze server levert ”video on demand” en ”live events” aan de gebruiker. Onder ”video on
demand” verstaat men een virtuele videotheek waarbij men een film kan bestellen. Live events
zijn bijvoorbeeld concerten, festivals, . . . die live opgenomen worden en aan de kijker beschikbaar
worden gesteld.
De VoD-server dient als tussenliggende server tussen de Xlet en de IP2DVB-gateway. Deze
gateway, ontwikkeld door Kristof Demeyere, zet de film zelf op de kabel en levert de juiste
locator aan de VoD-server. Dankzij deze locator kan de Xlet de film localiseren op de broadcast
stroom. Deze gateway wordt, evenals de VoD-server, geınitialiseerd via een XML-bestand. (zie
bijlage nr A.4.1)
Dit XML-bestand bevat de nodige gegevens over de film zelf zoals naam, beschrijving, prijs, e.d.
alsook de fysische locatie van het filmbestand.
Bij het opstarten van de EPG worden alle VoD- en LE-gegevens opgevraagd aan de VoD-
server. Deze worden in een XML-formaat gegoten met de nodige informatie zoals id, naam,
beschrijving, afbeelding en prijs en teruggestuurd naar de Xlet. Dit importeren gebeurt in een
aparte thread opdat dit het importeren van de programma’s uit de broadcast stroom niet zou
blokkeren. Een voorbeeld van zo’n XML-bestand is te vinden in A.4.2.
Het parsen hiervan wordt afgehandeld in de klassen ImportVOD en ImportLiveEvents naargelang
het type. De getallen die het genre bepalen, bevinden zich bij het element keywords. Per item
wordt er een VODElement of een LEElement gecreeerd en in de opslageenheid opgeslagen.
Wanneer alles geımporteerd is, verwittigt de hoofdmodule de GraphicalController die verder het
VodScreen hiervan op de hoogte brengt.
De Xlet kan aan de hand van de verkregen id’s de nodige acties op een bepaald item uitvoeren.
Deze acties zijn: afspelen, pauzeren, stoppen, vooruit- en achteruitspoelen. Deze acties worden
doorgegeven aan de gateway die het verdere verloop ervan verzorgt. Het doorgeven van deze
aanvragen verloopt via het HTTP-protocol. Om compatibiliteitsredenen heb ik hiervoor de
HTTP-module van Kristof overgenomen. Voor meer informatie over de IP2DVB-gateway verwijs
ik door naar Kristofs thesisverslag.
De EPG communiceert dus niet rechtstreeks met de IP2DVB-gateway, maar werkt via een
4.3 Import Module 40
tussenliggende, eigen ontwikkelde server. Op die manier kan later altijd op een eenvoudige
wijze overgeschakeld worden op een nieuwere versie of op een compleet ander systeem. De
communicatie tussen de Xlet en de eigen VoD-server blijft immers behouden. Dankzij het RCRP-
protocol kan men ook eenvoudig nieuwe acties toevoegen door deze als een nieuw subtype te
definieren.
4.3.5 Movie Information Server
De gebruiker wordt extra informatie over films aangeboden. De eigen ontwikkelde movie infor-
mation server levert deze gegevens. Zie 5.1 voor meer informatie over deze server.
4.3.6 Overige mogelijke servers
Dit zijn de servers die specifieke informatie bevatten die nuttig kunnen zijn voor de gebruikers.
Bijvoorbeeld een server die de kijkcijfers kan leveren, een server die trailers aanbiedt, een server
die programmaspecifieke weetjes levert, . . .
Momenteel zijn er geen zulke servers in gebruik.
4.3.7 Caching
De set-top box zal continu de SI-tabellen die het ontvangt in het cache geheugen opslaan. Op
deze manier kan de SI veel rapper gelezen worden. Want indien het in de cache zit, is er quasi
geen vertraging. Dus de mate waarin het caching gebeurt is een heel belangrijke factor in de
importeer- en bijgevolg de opstartsnelheid. Anderzijds houdt het natuurlijk ook een gevaar in.
Wanneer de cache niet de meest recente gegevens bevat, kan deze verkeerde gegevens leveren.
Er moet bijgevolg heel voorzichtig met de cache omgesprongen worden. Hoe dit cachen gebeurt
hangt volledig van de middleware van de set-top box af. Een EPG heeft er dus alle belang bij
dat de cache op een zo efficient mogelijke manier beheerd wordt. Ze moet dus vaak geupdatet
worden en zoveel mogelijk interessante SI bijhouden.
4.3.8 Keuze SI - externe server
Momenteel wordt de basisinformatie over de programma’s uit de stroom zelf gehaald. Een
alternatief bestaat erin deze informatie op te halen van een externe server. Beide systemen
hebben hun voor- en nadelen. Het ophalen van SI heeft als grote voordeel dat de EPG compleet
onafhankelijk van het terugkeerkanaal is. Het nadeel is echter dat het importeren van SI relatief
4.3 Import Module 41
traag verloopt. Via een externe server zal dit heel wat sneller verlopen, maar hiervoor moet er
natuurlijk zo’n server ontwikkeld en up-to-date gehouden worden. Een overzichtje:
SI
• voordelen
– onafhankelijk van het terugkeerkanaal.
– geen server vereist
• nadelen
– relatief traag
Externe server
• voordelen
– snel
• nadelen
– afhankelijk van het terugkeerkanaal
– ontwikkeling & onderhoud van deze server
Het manueel ingeven van de SI in de server is onbegonnen werk. Bijgevolg moet deze server
automatisch de SI ophalen uit de broadcast stroom. Er moet hiervoor een brug tussen het MHP-
platform en een server geslagen worden. Een eenvoudige oplossing bestaat erin een set-top box
de SI te laten importeren en deze via het terugkeerkanaal aan de server te bezorgen. Deze server
verspreidt de SI dan verder via het IP-netwerk naar de verschillende EPG-applicaties. De server
moet ook telkens alle applicaties op de hoogte houden van SI-veranderingen. Stream events
kunnen hier soelaas brengen.
Er is besloten om het importeren zonder externe server af te handelen en bijgevolg de SI uit
de broadcast stroom op te halen. Hiervoor zijn er een aantal redenen.
Ten eerste is het aangewezen een EPG te ontwikkelen die onafhankelijk van het terugkeerkanaal
kan functioneren. Zo’n terugkeerkanaal is immers niet standaard voorzien in het broadcast-
profiel. Vervolgens leek het, in het kader van deze thesis, eerder aangewezen om de SI rechtstreeks
uit de kabel op te halen, dan deze van een server te halen. Zo worden de mogelijkheden van
de desbetreffende API’s meer en beter benut. Deze thesis bestaat er - naar mijn mening -
4.3 Import Module 42
in om de verschillende MHP API’s te bestuderen en toe te passen in een Xlet. Hardwarematig
gezien zou het gebruik van een server ook een aantal praktische problemen met zich meebrengen.
De combinatie van een set-top box met een server dat tevens automatisch stream events kan
genereren is helemaal niet evident. Het zou het importeersysteem ook heel wat complexer maken,
waardoor ik minder tijd in de overige features zou kunnen steken.
4.3.9 Intern systeem
Zoals elke module heeft ook deze module een controller, namelijk de ImportController. Deze
implementeert vier interfaces
• EPGmodule
• RCReceiveInterface
• ImportInterface
• ImportControllerInterface
De ImportInterface is gericht naar buiten toe, naar de overige modules, terwijl de Import-
ControllerInterface gericht is naar de ImportPlugIns.
De ImportInterface biedt functies aan om het importeren te starten, op te vragen welke fase er
momenteel aan de gang is, om filminformatie op te vragen, om een overzicht van de plug-ins op
te vragen, . . . De ImportControllerInterface levert daarentegen de verschillende ImportPlugIns
de mogelijkheid om gegevens op te vragen via het terugkeerkanaal. Ze bevat simpelweg de func-
ties die de client connection module aanbiedt. Op die manier hoeven de huidige en eventuele
nieuwe plug-ins zich helemaal geen zorgen te maken over de details hiervan. Het volledig intern
systeem is weergegeven in een UML-schema in D.4. De plug-ins zijn er echter niet uitgewerkt.
De ImportController bevat de referenties naar de client connection module om de aanvragen
voor het terugkeerkanaal door te spelen. Daarnaast bevat ze ook een referentie naar de EPGda-
taInterface om de geımporteerde gegevens er te stockeren en naar de MainControllerInterface
om deze laatste op de hoogte te houden van de reeds afgewerkte fases.
Er zijn verschillende onderdelen, of plug-ins genoemd, die elk hun eigen taak verrichten. De
belangrijkste en tevens de grootste is de plug-in die de SI uit de broadcast stroom haalt. Daar-
naast zijn er nog twee plug-ins die de Vod-gegevens en de LE-gegevens importeren. De overige
4.3 Import Module 43
twee plug-ins, het importeren van programmaspecifieke informatie en algemene extra informatie
zijn reeds in het systeem geıntegreerd, maar zijn niet verder uitgewerkt. Deze worden als een
uitbreiding voor later beschouwd.
Opdat de ImportController deze op een eenvoudige manier kan beheren, moeten ze elk de Im-
portPlugIn-interface implementeren.
Voor de importeermodule is het heel belangrijk dat deze eenvoudig uitbreidbaar is. Later
kunnen er immers andere en nieuwe technologieen gebruikt worden om de nodige gegevens op
te halen. Het moet dus mogelijk zijn om een nieuwe plug-in te integreren. Zoals de naam reeds
doet vermoeden is dit is geen enkel probleem.
Indien men een plug-in wilt toevoegen aan de importeermodule, ontwikkelt men een klasse die
de ImportPlugIn-interface implementeert, wat de plug-in verplicht om voor basis ”service disco-
very” te zorgen. Deze interface zorgt er immers voor dat de basisinformatie over die plug-in kan
opgevraagd worden. Zo kan de ImportController bijvoorbeeld de mogelijke commando’s opvra-
gen dewelke hij kan uitvoeren op deze plug-in en heeft hij natuurlijk ook de mogelijkheid om deze
daadwerkelijk uit te voeren. De belangrijkste functie uit deze interface is de startImporting()-
functie waarmee de plug-in de opdracht wordt gegeven om het importeren te starten. Verder
zorgt deze interface er ook voor dat de plug-in de nodige gegevens via de ImportController van
het terugkeerkanaal kan ontvangen.
We gaan nu dieper in op de geımplementeerde plug-ins.
ImportSI
De belangrijkste klasse is de ImportSI -klasse. Het UML-schema ervan bevindt zich in D.5.
Deze implementeert de interfaces ImportPlugIn, RetrieveSIChangeInterface en Runnable. De
RetrieveSIChangeInterface legt de functies om de veranderingen binnen een service op te vragen
vast.
Deze klasse heeft twee belangrijke taken: het importeren van de gegevens en het up-to-date
houden van deze gegevens.
Het importeren gebeurt in afzonderlijke sequentiele fases:
1. huidige tv-programma’s
2. volgende tv-programma’s
3. huidige radioprogramma’s
4.3 Import Module 44
4. de overige tv-programma’s
5. de volgende radioprogramma’s
6. de overige radioprogramma’s
Het importeren van de huidige radioprogramma’s wordt hier voorgenomen op de overige tv-
programma’s omdat dit toch bijna geen vertraging met zich meebrengt.
Hoe men deze API gebruikt, is reeds eerder algemeen besproken in 4.3.3 op pagina 34. Hier-
onder wordt kort geschetst hoe dit naar de praktijk omgezet is.
Via de SIDatabase worden alle services opgevraagd. Deze worden naargelang het type in een
Vector met tv-services en een Vector met radioservices opgeslagen. Men stelt het aantal huidige,
volgende en overige tv-programma’s gelijk aan het aantal tv-zenders of radiozenders naargelang
het type. Per ontvangen resultaat wordt het juiste tellertje verhoogd. Deze teller wordt na-
tuurlijk ook verhoogd indien men een foutmelding als resultaat verkrijgt. Op die manier is het
mogelijk het aantal niet-afgewerkte aanvragen bij te houden. Er wordt telkens eerst in de cache
gekeken of de informatie er beschikbaar is, zo niet, wordt deze uit de transportstroom gehaald.
Indien alle informatie binnen een bepaalde fase opgehaald is, wordt deze informatie doorgegeven
aan de ImportController die deze gegevens opslaat in de opslageenheid en de MainController
hiervan op de hoogte brengt.
In de eerste fase worden alle huidige events van alle services verzameld, in de tweede fase alle
events daaropvolgend. Pas van zodra een fase afgewerkt is, worden de gegevens opgeslagen. Alle
overige programma’s worden telkens per service opgevraagd. Zodra men de resultaten ervan
ontvangt, worden deze alsook opgeslagen.
De klasse SIRequestProcessor die de SIRetrievalListener -interface implementeert zorgt voor
de verwerking van de resultaten aan de hand van het meegestuurde AppData-object. Dit object
bevat een short en een String. De short wordt gebruikt om het type van de aanvraag te defi-
nieren en de String om de naam van de zender mee te geven. Het type van de aanvraag wordt
gedefinieerd in de klasse ImportRequestType. De resultaten worden via een callbackmethode
terug naar de ImportSI -klasse bezorgd.
Wanneer er een verandering in de SIDatabase optreedt wordt de ImportSIMonitoringListener
hiervan op de hoogte gebracht. De SIMonitoringEvent geeft aan over welk type verandering het
4.4 EPGdata Module 45
gaat. Dit wordt via de callbackmethode getSpecificChangedService() terug doorgegeven aan de
ImportSI -klasse, dewelke de nodige gegevens opnieuw ophaalt.
ImportVOD
De klasse ImportVOD zorgt voor het importeren van de VoD-gegevens. Er wordt een thread
opgestart die de VoD-gegevens opvraagt aan de client connection module. Deze levert het XML-
bestand verkregen van de VoD-server in String-vorm. Dit XML-bestand bevat een aantal items,
dewelke geparset worden tot VODElementen. De Vector met deze elementen wordt doorgegeven
aan de ImportController die ze opslaat in de opslageenheid en vervolgens de MainControllerIn-
terface verwittigt dat de VoD-gegevens volledig geımporteerd is. Het UML-schema is beschreven
in D.6.
ImportLiveEvents
Het importeren van de live events gebeurt op een volledig gelijklopende manier zoals hierboven
beschreven.
4.4 EPGdata Module
Deze module heeft als functie het bijhouden van alle data, noodzakelijk voor de werking van de
applicatie. De geımporteerde gegevens worden in deze module op een efficiente manier opgesla-
gen en voor de gehele applicatie ter beschikking gesteld. Deze module verzorgt ook de specifieke
data gerelateerde functies zoals opslag, sorteren en zoeken.
De hoofdklasse binnen deze module is EPGdata. Deze implementeert de interfaces EPGmodule
en EPGdataInterface. Deze laatste biedt alle mogelijke functies aan voor het opslaan, opvragen,
sorteren, zoeken en verwijderen op allerlei mogelijke manieren van de tv- en radioprogramma’s.
Hoe de gegevens werkelijk intern opgeslagen worden staat hier volledig los van.
De EPGdata-klasse is een singleton klasse. Er kan dus slechts 1 object van die klasse aange-
maakt worden. Elke module kan eenvoudig de referentie naar dit object opvragen om zo de
nodige gegevens te bekomen.
4.4.1 Ontwerp interne opslag
De importeermodule levert in verschillende stappen de SI-informatie. Eerst alle huidige pro-
gramma’s, dan de programma’s daaropvolgend en het eindigt met alle overige programma’s in
4.4 EPGdata Module 46
de toekomst. Om dit eenvoudig bij te houden, bestaat er voor elke zender een klasse ChannelList
die het huidig, het volgend en alle toekomstige programma’s bijhoudt.
Wanneer de opslageenheid een Vector van huidige programma’s ontvangt, moet deze per pro-
gramma kijken in welk klasseobject dit programma opgeslagen moet worden.
De bedoeling is de verzameling van ChannelList-klassen zo compact mogelijk op te slaan
zonder aan performantie in te boeten. Java heeft verschillende soorten klassen om data bij te
houden, zoals List, Vector, ArrayList, HashTable, HashMap, . . . Deze hebben allen hun voor- en
nadelen.
Een Vector en HashTable hebben het grote voordeel ten opzichte van een ArrayList en HashMap
dat ze gesynchroniseerd zijn. Hiervoor moeten ze logischerwijs wel wat aan snelheid inboeten.
Dit is echter voor geen al te grote structuren te verwaarlozen. Aangezien de EPGdata module
zijn gegevens ter beschikking stelt aan meerdere modules die zelf meerdere threads bevatten, is
het aan te bevelen deze gegevens gesynchroniseerd op te slaan.
Het grote verschil tussen Vector en HashTable is het feit dat een Vector volgorde bewaart
en een HashTable niet. Dit heeft een aantal belangrijke implicaties.
Toevoegen van programma’s en het overlopen ervan zijn de twee belangrijkste acties en moeten
bijgevolg zo snel mogelijk gebeuren.
Het overlopen van de verschillende zenders is met een Vector heel eenvoudig. Eenmaal deze
gesorteerd is, kan men gewoonweg de zenders overlopen. Met een HashTable is dit niet het
geval. Deze behoudt de volgorde niet en bijgevolg is het niet mogelijk om de zenders makkelijk
te overlopen in een welbepaalde volgorde. Deze volgorde zou extern moeten opgeslagen worden.
Het toevoegen van programma’s is dan weer veel eenvoudiger aan de hand van een HashTable.
Het opzoeken gebeurt namelijk via de hashfunctie van de naam van de zender. Bij een Vector
daarentegen moet de volledige rij overlopen worden tot de juiste zender gevonden is.
Om de voordelen van beide datastructuren over te nemen, is er gebruik gemaakt van een
hybride oplossing. De ChannelList-objecten worden bijgehouden in een Vector. Op die manier
kan men deze dus enorm snel overlopen. Om te zoeken naar een bepaalde zender, maakt het
system gebruik van een HashTable, die per zender de index in de Vector bijhoudt. Hierdoor zal
het zoeken in die vector heel wat sneller verlopen. Wanneer echter de volledige Vector gesorteerd
wordt, moet ook de HashTable hieraan aangepast worden. Maar dit eenmalig kleine nadeel weegt
niet op tegen het grote voordeel van het snel zoeken.
4.4 EPGdata Module 47
Indien men extra filminformatie opvraagt via de movie information server, wordt ook deze
filminformatie opgeslagen in de opslageenheid. Dit gebeurt aan de hand van de klasse Movie.
Deze klasse is een subklasse van de klasse Program. Ze bevat naast de basisinformatie ook
typische filmgegevens zoals regisseur, cast, . . . Ook de gegevens van de VoD- en LE-programma’s
worden hier bijgehouden in de klassen VODElement en LEElement respectievelijk.
Samengevat bevat de EPGdata-klasse dus een Vector die per zender een object van de klasse
ChannelList bijhoudt, een Vector van VODElement-objecten , een Vector van LEElement-
objecten en een Vector van Movie-objecten. De klasse ChannelList bevat een current Program,
een next Program en een Vector van future Program-objecten. Elk object van de klasse Program
bevat alle nodige gegevens over een programma. Dit kan zowel een tv- als een radioprogramma
zijn. Een overzicht hiervan is terug te vinden in het UML-schema in D.7.
• naam van het programma
• naam van de zender
• de locator
• start- en eindtijd
• de duur in seconden
• programmatype en -subtype
• korte beschrijving
4.4.2 Zoekfuncties
De EPGdataInterface biedt een heleboel zoek- en sorteerfuncties aan. Zo is het mogelijk om
alle programma’s van een bepaald type, alle programma’s binnen twee bepaalde tijdstippen, alle
mogelijke genres die terug te vinden zijn in de opslageenheid, . . . op te vragen, en dit telkens
op verschillende manieren.
Er is eveneens een systeem voorzien om de volledige opslageenheid op kernwoorden te doorzoe-
ken. Een soort zoekmachine dus. Deze taak wordt uitbesteed aan de ChannelList-klasse die
op zich, z’n eigen programma’s doorzoekt. Er zijn twee verschillende methodes voorzien om te
zoeken op kernwoorden.
4.4 EPGdata Module 48
De eerste methode bestaat erin dat, los van het aantal kernwoorden, punten gegeven worden
op de belangrijkheid van overeenkomst. Wanneer de naam van het programma perfect overeen-
komt met een kernwoord, dan krijgt het 100% overeenkomst als score. Wanneer er slechts een
deel van de naam overeenkomt 40%. Wanneer de naam van de zender overeenkomt 30%, een
woord uit de beschrijving 20% en een genre 10%. Deze scores worden cumulatief toegekend.
Wanneer men bijvoorbeeld de zendernaam en twee woorden uit de beschrijving als kernwoorden
opgaf, dan bekomt dit programma de score van 70% overeenkomst.
In de tweede methode gaat men na welk percentage van de opgegeven kernwoorden ergens
in een programma terug te vinden zijn. Wanneer men bijvoorbeeld vijf kernwoorden opgeeft en
drie ervan komen voor in een programma (bijvoorbeeld: deel van de naam en twee woorden uit
de beschrijving) dan krijgt dit programma de score van 3/5 of 60%.
Beide methodes leveren vaak andere resultaten. De eerste methode dient eerder om specifiek
naar een bepaald programma te zoeken. De tweede methode levert eerder algemene resultaten
op. Op het aantal gevonden programma’s staat er natuurlijk een limiet. Eerst en vooral is er
een minimumwaarde of threshold ingesteld op de score van overeenkomst. Programma’s onder
deze waarde worden sowieso niet opgenomen. Alle zenders leveren geen enkel of een aantal
programma’s die met deze kernwoorden overeenkomen af. De EPGdata-klasse kiest hieruit de
programma’s met de hoogste score. Het aantal resultaten kan evenals de threshold ingesteld
worden. De EPGdataConfiguration-klasse regelt dit. Het resultaat is een Vector van Keyword-
SortElement-objecten. Elk object bevat een programma en een score.
Verder kan men de verschillende zenders en programma’s sorteren op een aantal manieren.
Men kan de zenders bijvoorbeeld sorteren volgens hun populariteit. De bekende Vlaamse zenders
zullen hoger in het rijtje staan dan de minder bekende zenders. De gebruiker kan deze volgorde
ook instellen in het instellingenmenu en bewaren via de configuratieserver. Binnen een zender
worden de programma’s chronologisch gesorteerd.
Men kan de programma’s ook volledig los van hun zender op type en subtype sorteren. Op die
manier kunnen gebruikers erg eenvoudig programma’s van een welbepaald genre terugvinden.
4.4.3 Model-view paradigma
De importeermodule, de EPGdata module en de grafische module werken nauw samen. De
importeermodule haalt de gegevens op en stockeert deze in de opslageenheid. Wanneer er een
4.5 Play Module 49
verandering optreedt (bv. een programma loopt ten einde en een nieuwe programma begint) dan
past de importeermodule de opslageenheid aan. De grafische module moet hiervan natuurlijk
op de hoogte gebracht worden. Aan de hand van het model-view paradigma gebeurt dit volledig
automatisch. De importeermodule is de controller, de EPGdatamodule het model en de grafische
module de view.
De EPGdata-klasse extendeert de klasse Observable. Hierdoor wordt de inhoud van deze klasse in
de gaten gehouden. De GraphicalController uit de grafische module implementeert de interface
Observer en registreert zichzelf bij de Observable. Wanneer er nu een wijziging in de data
optreedt, dan wordt automatisch de Observer hiervan op de hoogte gebracht.
4.4.4 Programmatypes en -subtypes
Deze module regelt ook de verschillende types en subtypes. Deze zijn gedefinieerd door ETSI
([11]). In de klassen ProgramType en ProgramSubType worden rijen van Strings bijgehouden
met de vertalingen in het Nederlands en het Engels van de types en subtypes respectievelijk.
Uit de content descriptor in de EIT-tabel kan men een byte bekomen. Deze byte beschrijft
de content nibbles level 1 en 2. De vier meest significante bits vormen level 1 en de vier
minst significante bits level 2. Er zijn twaalf voorgedefinieerde programma types (level 1). De
overige 0xC tot 0xE zijn voorbehouden voor toekomstig gebruik, 0xF mag de content provider
naar eigen goeddunken invullen. Een type kan men verder opsplitsen in verschillende subtypes.
Bijvoorbeeld: type sport, subtype voetbal.
De indeling van de films in verschillende subtypes is nogal vaag. Vele verschillende genres
worden samengenomen. Bv. subtype 0x2 bevat western, oorlog en avontuur. In totaal zijn er
slechts 9 verschillende genres. De indeling door IMDb daarentegen is veel beter. IMDb heeft
namelijk vijfentwintig verschillende genres en kent aan een film meerdere genres toe indien nodig.
Hierdoor is ook deze indeling overgenomen. Standaard zal dus eerst het ETSI-genre aan een film
toegekend worden en indien de gebruiker extra IMDb-informatie opvraagt, dan worden ook deze
genres eraan toegevoegd. Op die manier kan de gebruiker een veel preciezer beeld verkrijgen.
4.5 Play Module
Het afspelen van de video wordt in deze module geregeld. Indien een gebruiker een ander tv- of
radioprogramma kiest, moet de EPG natuurlijk de inhoud hiervan afspelen. Hiervoor bestaan
4.5 Play Module 50
er binnen MHP twee mogelijkheden: het Java Media Framework (JMF) en de JavaTV Service
Selection API. Beide systemen zijn volledig geımplementeerd met als bedoeling er wat mee te
experimenteren om te kijken welk systeem het best leek.
De afspeelmodule bestaat zoals alle overige modules uit een controller: de PlayController die
de interfaces PlayInterface en EPGmodule implementeert. De PlayInterface bevat de publieke
functies van de afspeelmodule.
4.5.1 Locator
Tijdens het importeren van de SI wordt er van elk programma een locator bijgehouden. Deze
locator is van de vorm:
dvb://<onID>.<tsID>.<sID>[.<ctag>[&<ctag>]][;<evID>][<path>]
De verschillende onderdelen worden als volgt gedefinieerd:
• onID
Het originele netwerk-id dat de provider of het network zelf identificeert.
• tsID
De transportstroom-id verwijst naar een transportstroom binnen de broadcast stroom.
• sID
De service-id refereert naar een bepaalde service binnen deze transportstroom.
• ctag
De component tag refereert naar een specifieke elementaire stroom.
• evID
De event-id verwijst naar een specifieke event binnen de service.
• path
Het pad naar een file verstuurd op die elementaire stroom in het broadcast bestandssys-
teem.
Elk van deze componenten wordt in hexadecimale tekens voorgesteld en enkel de eerste drie
componenten zijn verplicht.
4.5 Play Module 51
4.5.2 JMF-systeem
Het JMF-systeem werkt met Player -objecten. Dit is een klasse die ervoor zorgt dat het beeld
en geluid op het scherm verschijnt. Hiervoor wordt er niet daadwerkelijk naar een andere zender
overgeschakeld, enkel de inhoud ervan wordt weergegeven.
Een Player kan niet bestaan zonder een DataSource-object. Dit object haalt de mediage-
gevens op. Er is dus een scheiding tussen het ophalen en het weergeven van de inhoud. Per
protocol is er een specifieke DataSource beschikbaar. Uit de locator kan men aflezen welk pro-
tocol er gebruikt wordt. Bijvoorbeel in de locator dvb://1.1.6c;2247 wordt het DVB-protocol
gebruikt, in de locator http://www.ugent.be het HTTP-protocol. Na analyse van de locator
wordt de desbetreffende DataSource aangesproken om de inhoud op te halen. Dit systeem is
eenvoudig uitbreidbaar voor andere protocollen. Wanneer je je eigen protocol ontwikkelt, moet
je er enkel voor zorgen dat je ook een DataSource ter beschikking stelt om de gegevens op te
halen.
Per programma wordt er een locator bijgehouden in String-vorm. Aan de hand van deze String
wordt een MediaLocator gevormd die gebruikt wordt om de Player te initialiseren. Via de
functies start() en stop() wordt de inhoud respectievelijk afgespeeld en stopgezet.
Na wat geexperimenteer door heel wat te schakelen tussen de verschillende zenders zijn er
de volgende bemerkingen bekomen:
• Er werd inderdaad nooit effectief naar een zender overgeschakeld. Enkel de inhoud ver-
scheen op het tv-scherm. Op de display van de set-top box bleef het getal van de zender
namelijk onveranderd.
• Bij het overschakelen naar een andere zender, werd er een nieuwe Player gecreeerd, dewelke
telkens op de stack geplaatst werd. Bijgevolg verkreeg de set-top box geheugenproblemen
na heel wat te schakelen tussen de zenders. Het telkens opnieuw gebruiken van de huidige
Player bracht hier geen soelaas. Integendeel, dit werkte helemaal niet. Het dealloceren
van de resources van de huidige Player zal wellicht wel een oplossing bieden voor het
geheugenprobleem.
Een service is binnen de digitale tv-terminologie een bundeling van video en audio stromen sa-
men met SI. De gebruiker kan dus binnen een service kiezen welke stromen hij bekijkt. Zo kan
4.5 Play Module 52
men bijvoorbeeld videobeeld vanuit verschillende camerahoekpunten gezien, meesturen. Para-
fraserend kan men een zender in analoge tv vergelijken met een service binnen digitale tv.
Telkens wanneer er naar een andere zender (dus een andere service) geschakeld wordt, wordt
de huidige service en de ermee geassocieerde service context afgesloten. Hierdoor worden moge-
lijks de huidige applicaties afgesloten. Enkel applicaties die ook beschikbaar zijn in de nieuwe
service zullen blijven bestaan. In dit overschakelingsproces wordt de AIT-tabel (application
information table) geanalyseerd.
Bij het gebruik van een Player gebeurt dit niet! Er wordt namelijk niet overschakeld naar
een andere service. Er is dus geen gevaar dat de application manager je applicatie afsluit want
de AIT-tabel wordt helemaal niet geraadpleegd. Dit lijkt dus een goede oplossing. Maar het
is een egoıstische oplossing, want op die manier zal de gebruiker nooit toegang krijgen tot de
applicaties die zich enkel in de overige services bevinden.
4.5.3 JavaTV Service Selection API
JavaTV levert een API voor het overschakelen naar een andere service. Via de ServiceContext-
Factory kan de huidige ServiceContext opgevraagd worden. Door de methode select( DvbLoca-
tor[] locators) op te roepen op dit object, is het mogelijk om naar de service aangegeven door
de locator over te schakelen. Dit is dus een heel eenvoudig systeem.
Door het toevoegen van een ServiceContextListener op het ServiceContext-object kan men in-
spelen op verschillende events die gegenereerd worden, bijvoorbeeld wanneer er een verandering
van de context gebeurt, of wanneer het selecteren van een andere service mislukt is.
Tijdens het testen is er geen enkel probleem ontdekt bij het gebruik van deze API. Het heeft
natuurlijk zoals reeds eerder vermeld het grote nadeel dat de applicatie kan afgesloten worden.
Dit wordt opgelost door de applicatie mee te sturen in elke service, zoals dit nu gebeurt bij de
EPG van Telenet Digitale Televisie.
4.5.4 Keuze van gebruikt systeem
Er is besloten om gebruik te maken van de Service Selection methode. Dit leek het meest
elegant en leverde het minst problemen op. Een hybride oplossing waarbij men kiest tussen welke
methode men gebruikt, is natuurlijk ook mogelijk. Er is hier echter niet dieper op ingegaan.
Alleszins, beide methodes zijn wel degelijk voorzien. Wanneer bij het opstarten van de modules
4.6 Resource Module 53
de PlayControllerJMF gebruikt wordt in plaats van de PlayController, dan zal er doorheen de
volledige applicatie gebruik gemaakt worden van het JMF-systeem.
4.5.5 Overzicht mogelijkheden
De PlayInterface ( PlayInterfaceJMF voor JMF ) levert een overzicht van de verschillende
mogelijkheden. De belangrijkste is natuurlijk het schakelen naar een andere service. Dit kan
aan de hand van een rij locators of via een Service-object.
De mogelijkheden:
• overschakelen naar een andere service d.m.v. DvbLocator of Service-object
• opvragen van de zendernaam en -type (tv of radio) waar momenteel naar gekeken wordt
• opvragen van de huidige Service en ServiceContext
• toevoegen en verwijderen van een ServiceContextListener
• het stoppen en vernietigen van de ServiceContext
4.6 Resource Module
Een set-top box bevat een aantal systeembronnen. Aangezien deze schaars zijn, moet men er
voorzichtig mee omspringen. Xlets kunnen deze reserveren en er zo voor zorgen dat ze er ex-
clusieve toegang tot verkrijgen. Andere applicaties kunnen deze wel terug afnemen. Hierdoor is
er een goede resource management nodig. De resource management wordt gestuurd vanuit de
middleware van de set-top box. Er is dus geen resource management API aanwezig, maar wel
een resource notification API. Deze dient om een systeembron te reserveren of om de applicatie
mee te delen dat zij haar systeembronnen moet vrijgeven.
De belangrijkste interfaces uit de resource notification API zijn de ResourceClient, de Resour-
ceProxy en de ResourceServer. Een ResourceClient kan toegang tot systeembronnen aanvragen
aan de ResourceServer. Ze maakt hiervoor een ResourceProxy aan die deze toegang regelt.
De ResourceServer zal deze dan al dan niet valideren. Op die manier kan de ResourceServer
heel eenvoudig de toegang ook terug afnemen door de ResourceProxy ongeldig te verklaren. De
applicatie heeft dus op geen enkel moment rechtstreeks contact met de bron zelf, maar moet
telkens via een proxy om.
De functies uit de ResourceClient zijn :
4.6 Resource Module 54
• public boolean requestRelease(ResourceProxy proxy, Object requestData) ;
Hier wordt de ResourceClient gevraagd zijn toegang tot de systeembron van deze proxy
op te geven omdat een andere applicatie deze toegang aangevraagd heeft. De applicatie
staat vrij hierop al dan niet in te gaan door de waarde true of false terug te geven.
• public void release(ResourceProxy proxy) ;
In deze functie verwittigt de ResourceServer dat de systeembron vrijgegeven wordt. De
ResourceClient wordt hier nog de kans gegeven om een aantal zaken op te kuisen vooraleer
de systeembron definitief afgenomen wordt bij het beeindigen van deze functie.
• public void notifyRelease(ResourceProxy proxy) ;
Een oproep tot deze functie verwittigt de ResourceClient dat de ResourceProxy de toegang
tot zijn systeembron verloren heeft.
In deze module zitten algemene klassen die het beheren van de verschillende systeembronnen in
goede banen zullen leiden. Op die manier kan dit gescheiden blijven van de rest van het program-
ma. Ze bestaat uit drie grote onderdelen: de verschillende schermlagen, het terugkeerkanaal en
exclusieve toegang tot KeyEvents.
4.6.1 Intern systeem
De ResourceController is de dirigent in de systeembronnenmodule. Deze implementeert twee
interfaces, nl. ResourceControllerInterface en de welgekende EPGmodule. De ResourceControl-
lerInterface bevat algemene functies om de verschillende bronnen te initialiseren en te reserveren.
Het UML-schema is terug te vinden in D.12.
De drie grote componenten worden gerepresenteerd door de klassen ScreenLayers, Return-
Channel en ExclusiveKeyAccess. De ResourceController bevat een rij van deze klassen die elk
de ResourceInterface implementeren. De functies uit de ResourceControllerInterface worden zo
via de ResourceInterface doorgegeven aan elke component afzonderlijk. Het systeem is een-
voudig uitbreidbaar. Wil men later een klasse toevoegen die een andere systeembron beheert,
moet deze enkel de ResourceInterface implementeren en toegevoegd worden aan de rij in de
ResourceController. Automatisch zal de ResourceController ook deze initialiseren en reserveren.
De klassen ScreenLayers, ReturnChannel en ExclusiveKeyAccess implementeren tevens een spe-
cifieke interface (ScreenLayerInterface, ReturnChannelInterface en ExclusiveKeyAccessInterface
4.6 Resource Module 55
respectievelijk) die de nodige publieke functies aanbiedt. Referenties naar deze interfaces kunnen
via de ResourceController opgevraagd worden.
4.6.2 De verschillende schermlagen
Een tv-beeld bestaat uit drie verschillende lagen. De achterste laag is de achtergrondlaag.
Hierin kan ofwel een kleur ofwel een I-frame afgebeeld worden. De middelste laag waarin de
videostroom afgespeeld wordt, is de videolaag. De bovenste laag is de grafische laag. Daarin
worden de grafische componenten van een applicatie afgebeeld. Wanneer de applicatie exclusieve
toegang tot een van deze lagen wil verschaffen, moet de applicatie deze reserveren. Hiervoor
moet men per laag het desbetreffende ResourceProxy-object creeren. Deze zijn HGraphicsDevice,
HVideoDevice en HBackgroundDevice. Het reserveren ervan wordt gevraagd aan het Resour-
ceServer -object (tevens vertegenwoordigd door de klassen HGraphicsDevice, HVideoDevice en
HBackgroundDevice) via de functie reserveDevice(ResourceClient client). De verschillende la-
gen worden gebundeld tot een fysiek geheel, de HScreen. Er is slechts een HScreen-instantie per
fysieke beeldbuis mogelijk.
Het initialiseren en reserveren van de verschillende schermlagen wordt geımplementeerd in de
klasse ScreenLayers. Deze klasse bevat verder nog functies om het videoformaat en de posi-
tie ervan te wijzigen alsook een functie om een afbeelding in de achtergrond te plaatsen. Een
overzicht van deze functionaliteit wordt gebundeld in de ScreenLayerInterface.
Het initialiseren van een schermlaag gebeurt op een specifieke manier. Men maakt eerst een
”configuration template” aan. Deze wordt gebruikt om een geldige configuratie te bekomen. Aan
de template kunnen verschillende instellingen toegevoegd worden. Telkens moet men opgeven of
deze al dan niet vereist zijn of dat er al dan niet bij voorkeur aan voldaan moet worden. Daarna
wordt de best mogelijke configuratie opgevraagd die aan deze template voldoet. Wanneer het
niet mogelijk is om aan alle eis te voldoen, worden diegene die niet vereist zijn, weggelaten tot
een geldige configuratie bekomen wordt.
4.6.3 Terugkeerkanaal
Interactieve tv wordt gerealiseerd dankzij het terugkeerkanaal. Via dit interactiekanaal kunnen
applicaties gegevens sturen naar of ontvangen van een IP-netwerk. Wanneer men gebruik maakt
van een breedbandverbinding zoals ADSL bij BelgacomTV of zoals de kabel bij Telenet, dan
wordt dit niet beschouwd als een schaarse systeembron(”scarce resource”). Bijgevolg moet men
4.7 Graphical Module 56
niks reserveren.
Wanneer nu echter het terugkeerkanaal via een gewone analoge telefoonlijn verloopt en bijge-
volg er een service provider gecontacteerd moet worden, dan wordt dit wel als een schaarse bron
bekeken.
De klasse ReturnChannel neemt de taken van het opzetten, verbreken en reserveren van zo’n
verbinding op zich.
De ResourceProxy voor deze systeembron is een ConnectionRCInterface. Deze proxy wordt
opgevraagd aan de RCInterfaceManager dat als ResourceServer optreedt. De ConnectionR-
CInterface wordt geınitialiseerd via de verbindingsparameters login, paswoord en inbelnummer.
Daarna kan ze gereserveerd worden.
4.6.4 Event manager
Een applicatie kan enkel events ontvangen wanneer deze focus heeft. Voor een EPG is het handig
dat de applicatie de EPG-toets kan opvangen zelfs als ze niet zichtbaar is. Hiervoor kunnen we
natuurlijk een niet-zichtbare component op het scherm plaatsen. Maar HScenes mogen niet
overlappen en dus kunnen de andere applicaties dit stuk van het scherm niet gebruiken. Dit is
dus allesbehalve een elegante oplossing.
De org.dvb.event package levert een betere oplossing. De events worden er opgevangen
alvorens ze het AWT-eventsysteem binnentreden. Wanneer een applicatie het exclusieve recht
opeist van een toets, wordt dit bekeken als een schaarse bron.
In de klasse ExclusiveKeyAcces wordt er een UserEventRepository gecreeerd waaraan de nodige
toetsen gekoppeld worden, zoals de infotoets, de EPG-toets, . . . Aan de UserEventRepository
wordt er een UserEventListener toegevoegd, die de opgevangen UserEvents verder zal verwerken.
4.7 Graphical Module
Het grafisch gedeelte is volledig gescheiden van de rest. Op die manier kan men altijd een volledig
nieuwe user interface bouwen bovenop de kern van de applicatie. De grafische module heeft een
aantal submodules, namelijk een per scherm. Zo worden deze mooi gescheiden van elkaar.
4.7 Graphical Module 57
4.7.1 Intern systeem
De GraphicalController heeft in het grafisch systeem een enorm belangrijke functie. Deze beheert
de verschillende schermen en delegeert de opdrachten van de kern van het systeem door naar
alle schermen. Het UML-schema van deze module is terug te vinden in D.10.
De GraphicalController implementeert de interfaces RCReceiveInterface, EPGmodule en
GraphicalControllerInterface. Deze laatste levert de functies waarbij de controller de verschil-
lende schermen kan aanspreken en omgekeerd. Via de functie setModus(short modus) kan de
hoofdmodule bijvoorbeeld een bepaald scherm (mode) opstarten en zichtbaar maken. De Grap-
hicalController zorgt er steeds voor dat slechts een scherm zichtbaar is en focus heeft. Via
functies als setLanguage(int taalIndex) en setSkin(short skinIndex) wordt de GraphicalControl-
ler aangespoord om de taal en de skin in elk scherm aan te passen.
Omgekeerd, levert de GraphicalControllerInterface-interface functies die de schermklassen kun-
nen oproepen, zoals
switchToChannel(), recordProgram(), addToPlanner(), getMovieInformation(), retrieveRemin-
derList(), . . .
De GraphicalControllerInterface is een subklasse van de Observer -interface. Van zodra er een
wijziging optreedt in de opslageenheid zal deze (de Observable) via het model-view paradigma
automatisch de GraphicalController (de Observer) hiervan op de hoogte brengen via de update()
functie.
De GraphicalController bevat een collectie van schermen. De index bepaalt het type en wordt
gedefinieerd in de klasse ScreenModus. Momenteel zijn er elf verschillende modi gedefinieerd,
wat men natuurlijk nog kan uitbreiden.
• public static final short MAIN SCREEN = 0;
• public static final short VISIBLE CONTROLLER = 1;
• public static final short CURRENT PROGRAMS = 2;
• public static final short ALL PROGRAMS = 3;
• public static final short CATEGORY = 4;
• public static final short SUGGESTION = 5;
• public static final short LIVE EVENTS VOD = 6;
4.7 Graphical Module 58
• public static final short PLANNER = 7;
• public static final short SEARCH = 8;
• public static final short SETUP = 9;
• public static final short PVR = 10;
Elke schermklasse moet de ScreenInterface implementeren. Deze interface zorgt ervoor dat de
GraphicalController de nodige informatie over de schermen kan opvragen en eenvoudig bepaalde
opdrachten kan doorgeven. Elk scherm bestaat uit een hoofdcontainer die verder opgesplitst
wordt in deelcontainers. Het is de verantwoordelijkheid van de hoofdcontainer van elk scherm
om de verkregen opdracht zoals bijvoorbeeld het veranderen van de taal, door te spelen naar zijn
eigen deelcomponenten die dit, indien nodig, terug verder doorspelen naar hun deelcomponenten.
Er is dus een duidelijke hierarchie aanwezig.
De GraphicalController zelf is een subklasse van de HContainer -klasse. Deze wordt recht-
streeks toegevoegd aan de HScene. Ook hier wordt de hierarchie duidelijk doorgetrokken. Alle
hoofdcontainers van de schermen (elk hun eigen deelcontainers bevattend) worden toegevoegd
aan de container van de GraphicalController. Dankzij deze duidelijke structuur kan de controller
op een eenvoudige manier ervoor zorgen dat er op elk ogenblik slechts 1 scherm zichtbaar is.
Eerst worden alle hoofdcontainers van de schermen onzichtbaar gemaakt via de functie setAll-
VisibleFalse() en daarna wordt het gekozen scherm zichtbaar gemaakt.
Het doorgeven van de focus is een heel delicate zaak. Een container of component kan slechts
focus verkrijgen wanneer deze reeds bestaat en wanneer ze zichtbaar is. Dus wanneer men in een
constructor van een welbepaalde component diezelfde component focus probeert te geven, dan
zal dit niet gaan omdat deze component eigenlijk nog niet bestaat. De ScreenInterface bevat de
functie setFocusScreen() om een welbepaald scherm focus te geven. Dit scherm is opnieuw zelf
verantwoordelijk om de focus binnen zijn eigen deelcomponenten door te geven.
Het toevoegen van een scherm kan op een heel flexibele manier gebeuren. Er wordt een
nieuwe subpackage onder de package graphicalmodule gecreeerd. Deze zal alle klassen voor dit
nieuwe scherm bevatten. De nieuwe schermklasse implementeert de interface ScreenInterface,
bevat een referentie naar de controller en wordt toegevoegd aan de rij met schermenklassen.
Verder voegt men ook een mode toe aan de ScreenModus-klasse.Het hoofdmenu bestaat uit een
4.7 Graphical Module 59
ronddraaiend menu. Deze zal automatisch de aanwezige schermen opnemen. Meer informatie
hierover in 4.7.5 op pagina 64.
Via de ScreenLayerInterface als gegevenselement is het mogelijk om een afbeelding in de ach-
tergrond te plaatsen of om de videolaag te herschalen en te positioneren. Hiervoor is ook de
Xlet-context nodig.
4.7.2 Taal
De EPG wordt standaard in twee talen geleverd. In het hoofdmenu kan men een keuze maken
tussen Engels en Nederlands. In het instellingenmenu, kan men dit ook wijzigen. Wanneer de
gebruiker de taal verandert, moet het systeem elke component en elke container doorheen het
hele programma wijzigen. Hiervoor is een goede structuur onontbeerlijk.
Wanneer de GraphicalController de opdracht gegeven wordt de taal te veranderen, speelt
deze die opdracht door naar de hoofdcontainer van elk scherm. Het valt dan volledig binnen
de verantwoordelijkheid van de hoofdcontainer om deze opdracht opnieuw door te geven aan al
zijn deelcontainers en componenten. Dit moet iteratief gebeuren tot op het laagste niveau en
realiseert men via de functie setTaalIndex(int taalIndex).
Alle containers en componenten die tekst afbeelden op het scherm, houden deze Strings bij in
een rij. Aan de hand van de taalIndex wordt de beschrijving in de juiste taal uit de rij gehaald
en op het scherm geplaatst. In de klasse CurrentInformationScreen bijvoorbeeld vindt men
private String[][] buttonInformation={
{ ”record”,”preview off”,”radio”,”main menu”,”TV”,”preview on”},
{ ”opnemen”,”preview uit”,”radio”,”hoofdmenu”,”TV”,”preview aan”}}; terug.
Bij het eerste menuknopje wordt de tekst buttonInformation[taalIndex][0] uitgeprint. Op die
manier verkrijgt men de uitleg steeds in de juiste taal.
Uitbreiding naar meerdere talen is kinderspel. Er wordt simpelweg in elk van deze arrays
een lijst met de Strings in de nieuwe taal toegevoegd.
Bijvoorbeeld:
private String[][] buttonInformation={
{ ”record”,”preview off”,”radio”,”main menu”,”TV”,”preview on”},
{”opnemen”,”preview uit”,”radio”,”hoofdmenu”,”TV”,”preview aan”},
{ ”tourner”,”change automatique”,”radio”,”menu principal”,”Television”,”ne change pas”} };
4.7 Graphical Module 60
Wanneer nu de taalIndex op twee gesteld wordt, dan worden bijgevolg de termen in het Frans
op het scherm afgebeeld.
Een andere oplossing bestaat erin de verschillende opschriften bij te houden in configuratie-
bestanden. De applicatie gebruikt deze bestanden om de tekst in de juiste taal op het scherm af
te beelden. Door het toevoegen van configuratiebestanden kan men de uitbreiding naar meerdere
talen nog eenvoudiger verwezenlijken.
4.7.3 Skins
Om in te spelen op de laatste nieuwe trends, is het mogelijk het uitzicht van de EPG volledig
zelf aan te passen. Zo kan men de applicatie heel wat personaliseren. De gebruiker heeft de
mogelijkheid om een standaard skin te gebruiken, alsook een skin zelf samen te stellen door
verschillende kleuren te bepalen en een achtergrond in te stellen.
De klasse SkinLayout levert deze functionaliteit. Ze bevat momenteel vier skins, drie voor-
geprogrammeerde en een die volledig zelf samengesteld kan worden. Elke skin wordt eenduidig
bepaald door een achtergrondafbeelding en vier verschillende kleuren:
• bgColor : de achtergrondkleur van de open vlakken (transparante kleur)
• edgeColor : de voorgrondkleur van de tekst in de knoppen en vlakken
• bgColorF : de kleur van de knoppen wanneer deze geselecteerd zijn (focus)
• bgColorNF : de kleur van de koppen wanneer deze niet geselecteerd zijn.
Deze klasse levert de nodige functionaliteit om de verschillende kleuren en achtergrond voor de
huidige skin in te stellen en af te leveren.
Het doorspelen van de skin doorheen het volledige programma gebeurt op een gelijkaardige
manier als het doorgeven van de taal. De GraphicalController krijgt de opdracht om een bepaalde
skin in te stellen en geeft deze opdracht door aan de hoofdcontainers van alle schermen via de
functie changeSkin(). Deze spelen dit terug verder door aan hun deelcontainers en componenten.
Een hoofdcontainer bevat telkens de vier verschillende kleuren als publieke gegevenselementen
zodat de deelcontainers hier toegang tot hebben. Wanneer de skin ingesteld wordt op een
component, worden deze vier kleuren als parameter meegegeven want een component heeft
namelijk geen referentie naar de hoofdcontainer.
4.7 Graphical Module 61
Het skinsysteem is ontwikkeld nadat de applicatie voor het grootste gedeelte voltooid was.
Michiel Ide stelde voor om de EPG uit te breiden met verschillende skins. Dit was een uitdaging.
Op die manier was het mogelijk aan te tonen dat de huidige architectuur eenvoudig uitbreidbaar
is met features zoals deze. Doorheen de applicatie is enkel in alle grafische componenten de
functie changeSkin() toegevoegd en het systeem werkte. Dit laat niet weg dat de implementatie
hiervan toch wel enige tijd in beslag nam door de vele containers en componenten.
Momenteel is het niet mogelijk om de instellingen van de huidige skin op te slaan. Opslag op
de set-top box is met de huidige boxen niet mogelijk omdat hun geheugen niet blijvend is. Deze
instellingen moeten dus bijgevolg op de configuratieserver opgeslagen worden. Wegens tijdsge-
brek is dit opengelaten als een mogelijke uitbreiding voor het programma. De implementatie
hiervan werd namelijk niet als topprioriteit beschouwd.
Het gebruik van een eigen gekozen achtergrond is een verdere uitbreiding om het systeem
nog heel wat te personaliseren. De EPG levert de gebruiker de mogelijkheid om de achtergrond
volledig zelf te kiezen. Dit kan bijvoorbeeld een foto van zijn/haar vriend(in) zijn, een foto van
zijn of haar favoriete filmster, favoriete auto, noem maar op. Hiervoor moet de gebruiker in staat
gesteld worden een afbeelding door te geven. Dit kan bijvoorbeeld gebeuren via een website,
waar men zijn achtergrondafbeelding kan uploaden. Aan de hand van een identificatiecode kan
de applicatie de juiste achtergrond via het terugkeerkanaal opvragen aan de verantwoordelijke
server.
4.7.4 Vaak gebruikte componenten
HP logo
De applicatie is opgefleurd met een logo, het HP Solutions logo. Het design en de implementatie
ervan heeft David Plets verzorgd. Er zijn twee verschillende modi, elk met een eigen design.
Indien gewenst kan men de kleuren automatisch in elkaar laten overvloeien en het logo laten
bewegen.
HScrollComp
Deze klasse, afgeleid uit de klasse ScrollableText ontwikkeld door Oy, zorgt ervoor dat een
tekst van een willekeurige lengte automatisch opgedeeld wordt zodat alles mooi zichtbaar is.
Men kan doorheen de tekst lopen aan de hand van een eenvoudig scrollsysteem. De lay-out
4.7 Graphical Module 62
van de originele component werd volledig aangepast. Dank hiervoor aan David Plets voor de
implementatie ervan.
HProgressBar
Deze component vertoont hoe lang een programma reeds aan de gang is op een visueel aantrek-
kelijke manier. Er zijn twee verschillende modi: met en zonder asgegevens. Wanneer men deze
optie aanzet via de functie setAxesOn(true), dan verschijnt er links en rechts boven het balkje
de start- en eindtijd respectievelijk. Verder kan men ook de voor- en achtergrondkleur van de
component instellen.
HPolygon
Deze klasse levert componenten in de vorm van een +, een - of een driehoek. Voor deze laatste
is het ook mogelijk de orientatie in te stellen. Verder kunnen de afmetingen en de kleur volledig
zelf bepaald worden. David Plets ontwikkelde deze klasse.
HTextButtonIndexed
Deze klasse is een subklasse van de HTextButton-klasse. Ze levert een index als extra gege-
vensveld. Bij het opvangen van een KeyEvent kan men zo eenvoudig bepalen welke knop deze
genereerde. De klassen HTextButtonIndexedInfo en HTextButtonIndexedAutomatic vormen hier
subklassen van.
TitleScreen
Dit is een algemene container dat in elk scherm terugkeert. Dit schermonderdeel bevat de
huidige datum en tijdsvermelding samen met de titel van het scherm. De titel geeft men in alle
mogelijke talen als parameter in de constructor mee. Deze container kan men aanpassen volgens
een gewenste skin en/of taal. Ze is telkens bovenaanlinks op het scherm geplaatst. Indien
gewenst, is het ook mogelijk om een afbeelding als logo eraan toe te voegen.
ProgramInfoScreen
Deze container komt in de meeste schermen terug. Ze bevat telkens informatie over het geselec-
teerde programma. Deze informatie bestaat uit de naam van het programma en een beschrijving.
Deze beschrijving komt in een HScrollComp terecht zodat men doorheen de tekst kan lopen om
4.7 Graphical Module 63
deze volledig te lezen. Ze bevat meestal het genre en de korte inhoud. Opnieuw kan men de taal
en de skin naar believen aanpassen.
MovieInformationScreen
De MovieInformationScreen-klasse levert een doorzichtig venster waarbij er informatie over een
film wordt weergegeven. Deze kan natuurlijk ook simpelweg SI-informatie over een gewoon
tv-programma afbeelden. Deze tekst is in een HScrollComp geplaatst zodat men doorheen
de tekst kan lopen indien deze niet binnen het kader past. Wanneer er nog geen informatie
beschikbaar is omdat ze nog van de server opgehaald moet worden, bevindt de container zich
in de wachtstatus. Er verschijnt een melding op het scherm dat de informatie opgehaald wordt.
Indien de informatie niet beschikbaar is omdat de server bijvoorbeeld ontoegankelijk is, dan
genereert dit venster hiervoor eveneens een melding. Zoals in alle containers en componenten
kan men ook hier de taal en skin instellen.
GetBackContainer
De meeste schermen leveren de mogelijkheid om over te schakelen naar een bepaald programma
en dit te bekijken. Om de kijker tijdens het tv-kijken niet verder te storen wordt de volledige
applicatie onzichtbaar gemaakt. Deze blijft echter in de achtergrond actief. Wanneer de gebrui-
ker de applicatie terug zichtbaar wil maken, moet de applicatie luisteren naar het indrukken
van welbepaalde toetsen. Maar wanneer deze onzichtbaar is en bijgevolg geen focus heeft, kan
ze helemaal geen KeyEvents ontvangen! Hiervoor bestaat een oplossing om via UserEvents te
werken. Zie 4.6.4 voor de uitleg hieromtrent.
Om dit probleem op een heel eenvoudige manier te omzeilen is de GetBackContainer ontwik-
keld. Dit is een container die geen enkele component bevat. Wanneer deze zichtbaar gemaakt
wordt, merkt de gebruiker daar compleet niks van. Ze kan echter wel KeyEvents ontvangen.
Wanneer de gebruiker overgeschakelt naar een programma, geeft de huidige schermklasse zijn
scherm-id door aan de GraphicalController via de functie setPreviousScreen(short screenMo-
dus). Daarna wordt de GetBackContainer zichtbaar gemaakt en het huidig scherm onzichtbaar.
Door het geven van de focus aan de GetBackContainer kan deze de nodige KeyEvents opvangen.
Wanneer de gebruiker nu op de back-toets of op de blauwe toets drukt, maakt de GraphicalCon-
troller het vorig scherm of het hoofdmenu respectievelijk terug zichtbaar.
4.7 Graphical Module 64
4.7.5 Verschillende schermen
Hoofdscherm
Het hoofdscherm is het opstartscherm van de EPG. Deze levert toegang tot de verschillende
functies van de EPG. Om dit visueel aantrekkelijk te maken is hiervoor een draaiend menu ont-
wikkeld, dewelke het belangrijkste onderdeel van dit scherm vormt. Zie C.1 voor een afbeelding
hiervan.
De klasse CircularMenu zorgt voor de implementatie van dit menu. De constructor krijgt
onder andere als parameter een String-array met een korte beschrijving van alle aanwezige
schermen. Deze lijst wordt automatisch opgebouwd in de GraphicalController door de functie
getScreenInfo() op elk ScreenInterface-object op te roepen.
De bedoeling was om de opbouw van het menu volledig automatisch te laten verlopen aan de
hand van opgegeven afmetingen en het aantal schermen. Per scherm wordt er een menu-item
ontwikkeld waarbij deze items in de vorm van een cirkel komen te liggen. Het geselecteerde item
komt vooraan en is groter dan de overige. Hoe verder naar boven, hoe kleiner de menuafbeel-
dingen worden. Een item wordt geselecteerd door het ronddraaien van dit menu.
Dit bleek echter enorm complex uit te vallen, mede door het feit dat de opbouw voor een even en
oneven aantal schermen verschillend is. Wanneer men een even aantal menu-items wil afbeelden,
dan wordt er op de bovenste en dus verste rij slechts een item afgebeeld in plaats van twee voor
een oneven aantal menu-items. Het aantal niveaus, de coordinaten, de afmetingen van de af-
beeldingen, de onderlinge tussenafstanden, . . . werkelijk alles moet automatisch bepaald worden.
Op een paar details na is alles geautomatiseerd. Enkel op de x-coordinaten is er hier en daar
een manuele aanpassing doorgevoerd om het visueel beter te laten uitkomen. Dit alles is echter
slechts uitgevoerd voor een oneven aantal items. Wanneer er in de toekomst een even aantal
schermen beschikbaar zullen zijn, dan zal dit menu hier en daar wat uitgebreid moeten worden
zodat het hoogste niveau slechts 1 item afbeeldt.
Per menu-item wordt er een afbeelding weergegeven waarvan de grootte afhangt van de positie
binnen dit menu. Wanneer het item geselecteerd is, verschijnt er ook een korte beschrijving
van dit item. Elke afbeelding wordt slechts eenmaal meegestuurd over de kabel. Deze wordt
in de functie loadIcons() opgehaald en voor elk niveau herschaald volgens de eerder berekende
afmetingen. Een MediaTracker zorgt ervoor dat er gewacht wordt tot alle afbeeldingen opge-
haald en herschaald zijn vooraleer het menu af te beelden. Dit herschalen levert geen al te grote
4.7 Graphical Module 65
vertraging op, zodat het niet nodig is om alle afbeeldingen in alle nodige formaten vooraf mee
te sturen.
De besturing van het menu gebeurt via de pijltjestoetsen rechts en links. Wanneer men op de
linkertoets drukt, draait het menu wijzerzin. In het midden van het wiel verschijnt het HP
Solutions logo. Deze beweegt en de kleuren vloeien op een random manier in elkaar over. In het
hoofdscherm is het verder mogelijk om de taal in te stellen via de kleurtoetsen rood en groen.
Indien men op de gele toets drukt start een verborgen feature, namelijk het populaire spelletje
Snake (zie C.13 voor een afbeelding hiervan).
Dit menu kan men op verschillende manieren uitbreiden. De mode waarin er een even aantal
items aan het wiel worden toegevoegd is nog niet geımplementeerd. Ook op visueel vlak is het
mogelijk om het geheel nog wat op te fleuren. Zo kan het wiel realistischer gemaakt worden door
de afbeeldingen in een cirkel te laten bewegen wanneer men aan het wiel draait. Hiervoor moet
het menu natuurlijk de padcoordinaten berekenen. Dit werd echter als onbelangrijk beschouwd
en bijgevolg is dit opengelaten.
Informatieverkenner
De gebruiker heeft de opportuniteit om tijdens het tv-kijken alle tv- en radiozenders te overlopen
en om zo over te schakelen naar een andere zender. Enorm handig is de mogelijkheid om tijdens
het tv-kijken andere programma’s te laten opnemen of een herinnering hiervoor in te stellen
zonder dat de kijker ook maar iets van zijn programma mist.
Met de informatieverkenner kan men enkel het huidige en het daaropvolgend programma
opvragen en dit voor zowel de radio- als de televisiezenders. Deze kunnen ofwel samen of elk
afzonderlijk getoond worden. In dit laatste geval is er nog plaats voor een korte beschrijving.
Via de pijltjes naar links en rechts kan men de verschillende zenders overlopen. Er wordt niet
telkens automatisch geschakeld naar deze zender. De bedoeling is wel degelijk dat de gebruiker
naar z’n huidig programma kan verder kijken. Via de groene toets kan men schakelen tussen
tv en radio en via de rode toets kan men kiezen om ofwel een programma met beschrijving
ofwel twee programma’s op het scherm te plaatsen. Wanneer er slechts een programma getoond
wordt, kan de gebruiker het programma daaropvolgend opvragen met het pijltje naar omhoog
en dan terugkeren met het pijltje naar omlaag.
Indien men op de ok-toets drukt, schakelt de EPG over naar het gekozen programma indien
4.7 Graphical Module 66
deze zich op dit ogenblik afspeelt, anders wordt er gewoon naar die zender overgeschakeld. Via
de blauwe toets kan men dit menu onzichtbaar maken om het tv-kijken verder niet te verstoren.
Via de gele toets is het mogelijk om het extra menu op te roepen. Er verschijnt een venstertje
met vier verschillende mogelijkheden die men aanstuurt via de kleurtoetsen. Deze zijn: kiezen
van een programma, het opnemen ervan, een herinnering instellen voor dit programma of het
venstertje terug sluiten. C.2 toont een afbeelding van de informatieverkenner met dit extra
menuutje opgelicht.
Wanneer men de volledige informatie over een programma wilt, kan men deze opvragen via de
infotoets. Er verschijnt een doorzichtig venster in het midden van het scherm dat informatie
zoals genre en beschrijving levert. Wanneer er extra informatie beschikbaar is zoals bij een film
wordt deze automatisch op de desbetreffende server opgehaald en op het scherm geplaatst.
De package graphicalmodule.navigatorscreen bestaat uit drie klassen. De hoofdcontainer is
de klasse NavigatorScreen. Deze heeft drie deelcontainers: de onderste balk SimpleNavigator, het
menuvenstertje ColorChooseMenu en het informatievenster MovieInformationScreen, dewelke
zich in de hoofdpackage graphicalmodule bevindt.
De SimpleNavigator -klasse verkrijgt telkens focus. Deze ontvangt en verwerkt bijgevolg de
verschillende KeyEvents. De EPGdatamodule levert een referentie naar een Vector met alle
huidige programma’s en via de pijltjestoetsen kan men zo de verschillende zenders eenvoudig
overlopen. Wanneer men een actie op een bepaald programma uitvoert zoals het opnemen
ervan, wordt deze actie doorgegeven aan de NavigatorScreen die dit verder doorgeeft aan de
GraphicalController zodat het uiteindelijk in de hoofdmodule terecht komt.
De NavigatorScreen wordt telkens op de hoogte gehouden in welke fase het importeren zich
bevindt en zal de SimpleNavigator naargelang deze fase voorzien van de nodige gegevens, dewelke
hij ophaalt via een referentie naar de EPGdataInterface. Dit leverde de grootste moeilijkheden.
De knoppen moeten immers naargelang de reeds voorhanden mogelijkheden al dan niet zichtbaar
zijn. Wanneer bijvoorbeeld de radioinformatie nog niet geımporteerd is, zal de tekst bij de groene
knop niet zichtbaar zijn. En indien enkel voor de tv-zenders beide programma’s geımporteerd
zijn, zal de uitleg bij de rode knop enkel voor de tv-zenders en niet voor de radiozenders zichtbaar
zijn. Bij het indrukken van een toets moet er telkens via booleans nagegaan worden welke
informatie er reeds beschikbaar is en welke informatie er momenteel op het scherm zichtbaar is.
Afhankelijk daarvan wordt de desbetreffende actie uitgevoerd.
4.7 Graphical Module 67
De beschrijving bij het programma wordt geplaatst in een HStaticText waarop een DVBText-
LayoutManager losgelaten wordt. Er zijn slechts twee regels tekst beschikbaar. Indien dit onvol-
doende is, kan de volledige tekst in het MovieInformationScreen-gedeelte weergegeven worden
door op de infotoets te drukken. Wanneer men een programma opneemt, verschijnt er een rood
bolletje op de informatieverkenner zodat deze de gebruiker hiervan op de hoogte brengt.
Huidig programmaoverzicht
Alle programma’s die bezig zijn wanneer men de EPG opstart, verschijnen in dit scherm. Op
die manier krijgt de gebruiker snel een overzicht wat hij of zij op dit moment kan bekijken. Deze
programma’s zijn gesorteerd naar bekendheid van de zenders. De typisch veel bekeken zenders
zoals een en vtm zullen hier bovenaan staan.
De hoofdcontainer is de klasse CurrentScreen. Deze bevat meerdere deelcontainers, zoals
de TitleScreen, ProgramInfoScreen en CurrentInformationScreen. Deze laatste klasse bevat de
legende die een overzicht biedt van de verschillende mogelijkheden.
Naargelang het aantal zenders maakt de CurrentScreen-klasse dynamisch knoppen aan van het
objecttype HTextButtonIndexedInfo. Deze klasse is een subklasse van de HTextButton-klasse.
Ze bevat als extra gegevensvelden een index en een boolean die aangeeft indien men al dan niet
extra informatie kan opvragen. Dit wordt visueel voorgesteld door een i op het einde van de
knop te plaatsen.
De generatie van de knoppen gebeurt volledig automatisch aan de hand van het aantal knoppen
en de de vrije plaats waar ze terecht komen. De knoppen worden verdeeld in pagina’s. De
gebruiker kan doorheen deze pagina’s bladeren aan de hand van de pijltjestoetsen links en
rechts. Driehoekjes, voorgesteld door de klasse HPolygon geven aan in welke richting men kan
bladeren. Dit gaat heel wat sneller dan alle knoppen te moeten overlopen en biedt ook een beter
overzicht aan.
De gebruikelijke acties zoals het overschakelen naar dit programma of het opnemen ervan
zijn voorzien. Via de gele toets kan men schakelen tussen televisie en radio. Wanneer men een
zender selecteert, verschijnt de informatie in de ProgramInfoScreen en wordt de HProgressBar
in de legende automatisch aangepast. Het toevoegen van een HFocusListener aan deze knoppen
zorgt ervoor dat de applicatie op de hoogte gebracht wordt indien een knop focus verkrijgt of
verliest via de functies focusGained(FocusEvent e) en FocusLost(FocusEvent e) respectievelijk.
4.7 Graphical Module 68
Aan de hand van de index, kan men opvragen welke knop er juist geselecteerd is.
Indien er extra informatie voorzien is, kan men deze opvragen via de infotoets. Deze informatie
verschijnt opnieuw in de ProgramInfoScreen-container. Via de kanaal omhoog- en omlaagtoetsen
kan men doorheen deze informatie lopen. C.3 toont een foto van dit scherm waarbij er extra
filminformatie opgevraagd is.
Rechtsboven verschijnt een herschaalde versie van het videobeeld, dat het huidig programma
bevat. Via de groene toets kan men de preview-mode aan of uit zetten. In deze mode zal het
videobeeld automatisch overschakelen naar de zender die momenteel geselecteerd is. Op die
manier kan men telkens zien hoe het programma eruit ziet. Dit overschakelen zorgt wel telkens
voor een minimale vertraging. Het terugkeren naar het hoofdmenu gebeurt zoals overal met de
blauwe toets of via de back-toets.
Het gebruik van de ok-toets op een HTextButton of een afgeleide klasse hiervan leverde
een klein probleempje op. Deze wordt namelijk niet opgevangen door het toevoegen van een
KeyListener. Voor de ok-toets is er namelijk een HActionListener nodig. Het toevoegen van
deze klasse als een private innerclass lost het probleem op een elegante manier op.
Volledig televisieoverzicht
Dit scherm levert zoals de naam doet vermoeden, een overzicht van alle zenders met al hun
programma’s. Deze worden gesorteerd per zender. De volgorde van de zenders wordt weerom
bepaald door hun populariteit. Hier kan men zoals in een tv-gids vooruitblikken naar de pro-
gramma’s die zich op een later tijdstip zullen afspelen. Zie C.4 voor een afbeelding hiervan. Het
UML-schema van deze subpackage is terug te vinden in D.11.
Het scherm is opgebouwd uit een aantal deelcontainers. De TitleScreen levert opnieuw de
titel en de datum samen met het HP-logo. De ProgramInfoScreen levert de informatie over het
geselecteerde programma. Wanneer er extra filminformatie opgevraagd wordt, verschijnt ook
deze in dit gedeelte van het scherm. Via de kanaal omhoog- en omlaagtoetsen kan men opnieuw
doorheen de tekst lopen. De FullOverviewInformationScreen-klasse levert de legende. Deze is
afhankelijk van waar de focus zich bevindt. Dit wordt verder in de tekst duidelijk. Rechtsboven
verschijnt opnieuw het videobeeld.
De klasse AllProgramMenu levert het overzicht met de programma’s. Deze bestaat uit een
StaticChannelMenu en per zender een StaticProgramMenu. De StaticChannelMenu bevat een
4.7 Graphical Module 69
rij van HTextButtonIndexed -objecten, waarmee men alle zenders kan overlopen via de pijltjes
omhoog en omlaag. Het bladeren doorheen de verschillende zenders gebeurt opnieuw aan de
hand van pagina’s. Via de rode en de groene toets kan men naar een volgende en vorige pagina
respectievelijk overgaan. Dit in tegenstelling tot de overige schermen waar de pijltjes naar links
en rechts deze functionaliteit bieden. Hier dienen deze pijltjes echter om te schakelen tussen
het zender- en het programmamenu. Het al dan niet oplichten van de tekst ”volgende pagina”
en ”vorige pagina” in de legende geeft de richtingen aan naar dewelke de gebruiker kan blade-
ren. Het genereren van de knoppen afhankelijk van het aantal zenders en de beschikbare plaats
gebeurt evenals het opdelen in pagina’s volledig automatisch en op dezelfde manier als in alle
overige schermen. Via de gele toets kan men opnieuw schakelen tussen radio- en televisiepro-
gramma’s.
Bij het overlopen van de zenders toont het programmamenu telkens de bijhorende programma’s.
Indien men via de pijltjestoets naar links naar het programmamenu overgaat, dan biedt de le-
gende de nodige functionaliteit om over te schakelen naar het gekozen programma, om deze op
te nemen of om een herinnering ervoor in te stellen. Het StaticProgramMenu maakt opnieuw
gebruik van de HTextButtonIndexedInfo-knoppen. Wanneer er extra informatie beschikbaar is,
aangegeven door het oplichtend i’tje op de knop, kan men deze via de infotoets opvragen.
Bij het schakelen tussen het zender- en het programmamenu wordt de focus telkens doorgegeven.
Het menu is op die manier zelf verantwoordelijk om de nodige KeyEvents op te vangen en te
verwerken. De AllProgramMenu-klasse verwittigt wel telkens de hoofdcontainer FullOverviewS-
creen wie er focus heeft. Hierdoor kan deze de legende hieraan aanpassen.
Herinneringenoverzicht
Dit scherm houdt een overzicht van de ingestelde herinneringen bij. Ze bevat zoals alle overige
schermen een titelscherm, een programmainformatiescherm en een legende. Naar gelang het
aantal herinneringen wordt er dynamisch een aantal knoppen aangemaakt. Deze bevatten de
naam van het programma en een rood kruisje of een groen vinkje indien er al dan niet automa-
tisch overgeschakeld wordt naar dit programma wanneer het begint. Zie C.5 voor een afbeelding
van dit scherm.
De legende geeft een overzicht van de mogelijkheden. Zo kan men herinneringen verwijderen,
instellen indien deze al dan niet automatisch moeten starten of het programma laten opnemen.
Via de pijltjes naar links en rechts kan men naar goede gewoonte bladeren tussen de verschillende
4.7 Graphical Module 70
pagina’s met herinneringen. Door op de ok-toets te drukken schakelt men over naar de zender
van het geselecteerde programma.
Telkens wanneer men dit scherm opstart en het dus focus verkrijgt, haalt het de lijst met
herinneringen op en genereert het een menu met knoppen hiervoor. Er zijn speciale knoppen
hiervoor ontwikkeld, de HTextButtonIndexedAutomatic-knoppen. Deze hebben naast hun index
een boolean automatic en infoOn als extra gegevensvelden. Wanneer de boolean automatic op
true staat verschijnt er een groen vinkje op het einde van de knop en wanneer deze op false staat
een rood kruisje. De boolean infoOn bepaalt of er al dan niet een i op de knop verschijnt om
aan te tonen dat men extra informatie kan opvragen.
Het verwijderen van een knop leverde een eigenaardige fout op. Wanneer er een knop in
de keyPressed() functie verwijderd werd, dan werd deze index toegekend aan de knop eron-
der. Blijkbaar genereerde de knop eronder, door het opschuiven van die knoppen, onmiddellijk
opnieuw een zelfde event waardoor er telkens twee knoppen per keer verwijderd werden. Het
invoeren van de boolean notAgain zorgde voor de oplossing.
Instellingenmenu
De EPG bevat een aantal instellingen. Het opvragen en de opslag hiervan wordt geregeld door de
hoofdmodule. Maar de gebruiker moet deze natuurlijk kunnen ingeven. Hiervoor is een scherm
ontwikkeld die dat bewerkstelligt, geımplementeerd in de klasse SetupScreen.
Indien men de instellingen wil wijzigen, bekomt men een scherm waarbij men de keuze heeft
tussen de vier grote onderdelen:
• taal veranderen
• uitzicht veranderen
• volgorde van de zenders aanpassen
• terugkeerkanaalparameters ingeven
SetupLanguageScreen De belangrijkste instelling is natuurlijk de taal. Er zijn zoals reeds
eerder vermeld, momenteel twee talen beschikbaar, namelijk het Nederlands en het Engels. Om
dit visueel voor te stellen staat er naast een rood en groen bolletje een Belgische en een Engelse
vlag respectievelijk. De implementatie hiervan is terug te vinden in de SetupLanguageScreen-
klasse.
4.7 Graphical Module 71
SetupSkinScreen Daarnaast biedt de EPG ook de mogelijkheid om het uitzicht ervan volledig
te personaliseren. De onderliggende implementatie hiervan gebeurt in de klasse SkinLayout (zie
4.7.3). De klasse SetupSkinScreen daarentegen verzorgt het grafisch gedeelte.
De gebruiker wordt de mogelijkheid geboden om ofwel een bestaande skin te kiezen, ofwel er
een zelf samen te stellen. Via de rode toets bladert men doorheen de verschillende mogelijke
skins. Deze worden volledig automatisch en onmiddellijk tijdens het bladeren ingesteld, zodat
men direct het resultaat ziet.
Indien men de skin volledig zelf wil samenstellen, drukt men op de groene toets. De eerste
kleurenpalet wordt geselecteerd. Via de pijltjestoetsen kiest men het gewenste kleur en bevestigt
men door op de ok-toets te drukken. De gekozen kleur verschijnt als achtergrond bij de tekst
boven het palet en men gaat over naar het volgende kleurenpalet. Dit moet men herhalen voor
de vier kleuren.
Ook de achtergrond kan men zelf kiezen. Door op de gele toets te drukken doorloopt men de
mogelijke achtergrondafbeeldingen. Een afbeelding van dit scherm is terug te vinden in C.12.
Voor het selecteren van een kleur is er een nieuwe component ontwikkeld: de HColorPalette.
Deze component is opgebouwd uit een matrix van zestien HArrayTextButton-objecten, ingedeeld
in vier rijen en vier kolommen. De HArrayTextButton is een subklasse van de HTextButton de-
welke navigeerbaar is. De pijltjestoetsen worden via de functies setMove() en setFocusTraversal()
naargelang de positie van de knop ingesteld om de verschillende kleuren te overlopen. Elke knop
in de matrix heeft namelijk een specifieke achtergrondkleur. Wanneer de gebruiker op de ok-toets
drukt, gaat men aan de hand van de rij- en kolomcoordinaat de drie kleurcomponenten hiermee
corresponderend opvragen uit de drie kleurcomponentenmatrixen, er een kleur mee vormen en
deze doorgeven aan de SetupSkinScreen-klasse.
SetupTVRadioSeqScreen De verschillende zenders, zowel radio als televisie, verschijnen in
een welbepaalde volgorde op het scherm. Het is natuurlijk belangrijk voor de gebruiker dat
zijn favoriete zenders zich vooraan bevinden. In de EPG wordt de volgorde van de populaire
vlaamse zenders, zoals een, vtm, canvas, ketnet, VT4, Ka2, . . . hard gecodeerd en wordt ervoor
gezorgd dat deze telkens vooraan in de lijst komen. De gebruiker moet natuurlijk in staat
zijn deze volgorde aan te passen, wat dit scherm mogelijk maakt. Het resultaat wordt daarna
doorgegeven aan de hoofdmodule die ze bewaart op de configuratieserver.
Deze klasse is omwille van tijdsgebrek niet geımplementeerd. Op het scherm verschijnt de
4.7 Graphical Module 72
boodschap dat deze feature enkel in een toekomstige versie beschikbaar zal zijn.
SetupRCdataScreen Wanneer het terugkeerkanaal niet verloopt over een permanent ver-
binding, moet deze verbinding opgezet worden. Hiervoor is een inbelnummer, een login en een
paswoord nodig. Deze gegevens kan de gebruiker in dit scherm ingeven. Verder kan men er ook
het gebruik van het interactiekanaal uitschakelen voor bepaalde doeleinden zoals het loggen van
de gebruikersacties, mocht men hiermee problemen hebben.
Opnieuw wegens tijdsgebrek is ook dit scherm niet geımplementeerd en verschijnt er dezelfde
boodschap als hierboven.
Verdere uitbreidingen De volledige schermresolutie bedraagt 720 x 576 pixels. Maar een
gedeelte hiervan valt buiten het zichtbaar gedeelte van het fysieke beeldscherm. Men moet dus
een veilige zone inbouwen. Helaas is dit verschillend van televisietoestel tot televisietoestel.
Indien men de veilige zone te groot maakt, verliest men een te groot gedeelte van het scherm.
En indien deze te klein is, bestaat de kans erin dat er een deel van de applicatie buiten het
zichtbaar gedeelte valt. Een oplossing hiervoor is de gebruiker dit dynamisch te laten instellen.
Deze hoeft slechts eenmaal de moeite te doen om een rechthoek met de pijltjestoetsen telkens te
laten vergroten tot deze nog juist zichtbaar is. Op die manier kan de applicatie zich aanpassen
aan de afmetingen van het werkelijk zichtbaar gedeelte van de televisie. Deze instellingen kunnen
opnieuw op de configuratieserver of in de toekomst in het blijvend geheugen opgeslagen worden.
Suggestieoverzicht
Dankzij het zelflerend systeem heeft de EPG de mogelijkheid om de gebruiker suggesties te
leveren. In het begin zijn er te weinig gegevens voorhanden om accurate aanbevelingen te
leveren. Wanneer de gebruiker dit wenst, kan hij dit opstartproces versnellen door zelf wat hij
al dan niet graag ziet in te geven. Aangezien de EPG met een familieprofiel werkt, moet deze
ook weten weten wanneer de gebruiker meestal naar televisie kijkt.
Het SuggestionScreen bevat het SuggestionStartMenu dat twee mogelijkheden bevat.
Ingeven initiele suggestievoorkeuren Via de rode toets gaat men over naar het Watch-
PreferencesScreen. Deze klasse levert de gebruiker de mogelijkheid om zijn voorkeuren in te
geven. Dit proces is helemaal niet verplicht. Voor elk tijdslot en voor elk genre moet er een
getal tussen 1 en 5 ingegeven worden. Bijgevolg duurt dit proces toch wel enkele minuten.
4.7 Graphical Module 73
Wanneer het gaat over de kans dat de gebruiker in een welbepaald tijdsslot naar tv kijkt, dan
stelt de waarde 1 helemaal geen kans voor, de waarde 3 neutraal en de waarde 5 een heel grote
kans. Indien de gebruiker z’n waardering over een bepaald genre gevraagd wordt, dan bete-
kent de waarde 1 dat de gebruiker dit programma helemaal niet graag ziet en de waarde 5 dat
het zijn of haar lievelingsprogramma is. Om het visueel wat aantrekkelijk te maken, zijn er
de componenten CircularScrollComponent en CircularFillScrollComponent ontwikkeld. Enkel
deze laatste wordt momenteel gebruikt. De afbeelding in C.10 toont dit scherm samen met deze
laatste component.
Deze componenten bevatten zoals te zien is op de foto in C.10, een grote bol in het midden
die de momenteel gekozen waarde bevat en 5 kleinere bolletjes ermee verbonden in de vorm
van een ster. Naargelang de gebruikte component en de gekozen waarde worden deze bolletjes
opgevuld. Via de pijltjestoetsen kan de gebruiker de juiste waarde kiezen. Bij de CircularScroll-
Component wordt enkel het bolletje passend bij een getal gekleurd. Bijvoorbeeld, wanneer de
waarde 2 gekozen wordt, dan kleurt enkel het tweede kleine bolletje op. Bij de CircularFillS-
crollComponent echter, worden er evenveel bolletjes gekleurd als het getal aangeeft. Wanneer
er bijvoorbeeld de waarde 2 gekozen wordt, dan zal het eerste en het tweede bolletje gekleurd
zijn. De keuze bevestigt de gebruiker via de ok-toets.
Om het ingeven van de voorkeuren te versnellen, kan men ook gewoonweg de keuze ingeven via
de cijfertoetsen van de afstandsbediening. Via de rode toets kan de gebruiker terugkeren naar
eerder ingegegeven waarden en via de back-toets wordt er terug naar het SuggestionStartMenu
gekeerd. Zolang de applicatie niet afgesloten wordt, zullen de reeds ingegeven waarden niet
verloren gaan.
Wanneer alle voorkeuren ingegeven zijn, wordt de gebruiker een bevestiging gevraagd om deze
gegevens op te slaan. Indien hij of zij hierop positief antwoordt, worden de gegevens gebundeld
in een XML-bestand en verstuurd naar de server.
Opvragen aanbevelingen Aan de hand van de data verkregen van de user suggestion ser-
ver en de resultaten aangereikt door de aanbevelingsalgoritmes, biedt de EPG de gebruiker een
aantal suggesties aan. Via de groene toets in het hoofdmenu, bekomt de gebruiker deze aanbeve-
lingen. Ze worden gesorteerd zodanig dat de programma’s dat de gebruiker wellicht het liefst zal
zien, bovenaan komen te staan. Deze waardering wordt in procent uitgedrukt. De legende toont
opnieuw de reeds gekende mogelijkheden: het bekijken of het opnemen van het geselecteerde
4.7 Graphical Module 74
programma of een herinnering hiervoor instellen. Verder wordt er opnieuw gebladerd tussen de
verschillende pagina’s via de pijltjes toetsen naar links en rechts en verschijnt de informatie over
het programma telkens onderaan.
Zoekscherm
De gebruiker kan de volledige tv-gids doorzoeken naar een welbepaald programma. Hiervoor
worden de zoekfuncties uit de opslageenheid gebruikt. Het zoekscherm is een heel handig hulp-
middel wanneer men weet heeft van een bepaald programma of van een film, maar men heeft
er geen flauw benul van op welke zender deze uitgezonden wordt. Of indien men algemeen een
aantal programma’s wil zoeken die voldoen aan de ingegeven kernwoorden.
Het zoekscherm start met een gedeelte waar de gebruiker via de het SMS-systeem een aantal
kernwoorden kan opgeven. Voor het inputgedeelte wordt gebruik gemaakt van de klasse HMul-
tilineEntry. Na op de ok-toets gedrukt te hebben, kan men de kernwoorden ingeven. Voor het
wissen van een karakter gebruikt men de back-toets. Indien men klaar is met het ingeven, gaat
men uit dit kader door op de exit-toets te drukken. Door op de gele toets te drukken, kan men
gemakkelijk een specifiek genre toevoegen als kernwoord. Er verschijnt een menu met bovenaan
het programmatype en eronder de subtypes die in pagina’s verdeeld zijn. Men kan via de pijl-
tjestoetsen de types en subtypes overlopen en kiest er een uit door op de ok-toets te drukken.
Deze wordt dan als kernwoord toegevoegd. Ditzelfde menu is ook in het categorieoverzicht terug
te vinden, zie C.8 voor de afbeelding ervan.
Er zijn twee verschillende methodes voorhanden, zoals besproken in 4.4.2. Men kan tussen
deze methodes wisselen via de groene toets. Nadat men alles goed ingegeven heeft, drukt men
op de rode toets om de zoekresultaten op te halen.
De zoekresultaten worden gesorteerd volgens het aantal procent overeenkomst. Verder is dit
scherm op een gelijkaardige manier opgebouwd als de resultaten op het suggestiescherm. Via
de back-toets kan men terugkeren om nieuwe kernwoorden in te geven. Een afbeelding van dit
scherm is terug te vinden in C.11.
Categorieoverzicht
In het categorieoverzicht is het mogelijk programma’s van een welbepaald genre op te vragen.
Men start met een menu waarbij men het juiste genre selecteert door eerst het type en daarna het
4.7 Graphical Module 75
subtype te kiezen. Via de ok-toets bevestigt men z’n keuze. Aan de opslageenheid worden alle
programma’s opgevraagd die voldoen aan dit genre. Naargelang het aantal resultaten worden
er automatisch knoppen gecreeerd en ingedeeld in pagina’s op de reeds besproken manier.
De legende geeft de mogelijkheden aan. Deze zijn zoals altijd: overschakelen, opnemen, een
herinnering instellen of terugkeren naar het hoofdmenu. Via de back-toets is het mogelijk
terug te keren naar het menuutje om het genre te selecteren. Verder is dit scherm op een heel
gelijkaardige manier opgebouwd als de overige schermen. C.8 en C.9 leveren afbeeldingen van
respectievelijk het input-gedeelte en de resultaten.
Virtuele videotheek
De EPG levert de mogelijkheid om live events of films aan te kopen en deze te bekijken. De
mogelijke titels worden geleverd door de VoD-server. Er wordt een duidelijke opsplitsing tussen
films en live events gemaakt. De gebruiker kan via de groene toets de VoD-items opvragen
en via de gele toets de live events. Elk item bevat een titel, genre, beschrijving en prijs, de-
welke onderaan de pagina verschijnen. Behalve voor de beschrijving wordt er telkens hiervoor
een HStaticText-component gebruikt, voor de beschrijving echter een HScrollComp. Opnieuw
kan men via de kanaaltoetsen omhoog en omlaag door deze informatie lopen. C.6 levert een
afbeelding van dit scherm.
Tijdens het opstarten van de EPG worden de VoD- en LE-gegevens opgehaald van de VoD-
server. De server levert voor elk onderdeel een XML-bestand. Het parsen van deze XML-
bestanden gebeurt in de importeermodule, meer bepaald in de klassen ImportVOD en ImportLi-
veEvents naargelang het type. Daarna worden deze gegevens opgeslagen in de EPGdata module.
Voor een uitgebreidere uitleg, zie 4.3.9. De VodScreen-klasse haalt de gegevens uit de opslageen-
heid en genereert automatisch knoppen, dewelke zoals gewoonlijk in pagina’s verdeeld worden.
Door op de rode toets of de ok-toets te drukken bestelt men een item. De EPG vraagt de
gebruiker om een bevestiging door de component ConfirmationPopUp zichtbaar te maken. Via
de ok-toets kan men bevestigen, via de back-toets of de blauwe toets keert de gebruiker terug
naar het overzichtsscherm van de virtuele videotheek. Indien hij of zij effectief de aanvraag heeft
doorgevoerd, dan wordt er een verbinding met de VoD-server opgezet om de IP2DVB-gateway1
aan te sturen en de gevraagde film beschikbaar te maken. Er verschijnt een melding dat men
even geduld moet hebben. De gateway levert de VoD-server de nodige locator en stuurt deze1ontwikkeld door Kristof Demeyere
4.7 Graphical Module 76
door naar de applicatie zelf. Deze locator wordt opnieuw in XML-formaat (zie 4.3.4 en A.4.2)
verstuurd. Het parsen hiervan gebeurt echter in de VodScreen-klasse zelf.
Van zodra de locator ontvangen is, schakelt de EPG over naar het opgevraagde item. Deze wordt
vertoond in de VODPlayScreen. Dit scherm bevat twee componenten, namelijk VODKeysCom-
ponent en VODTitleComponent. De eerste is een menubalk die men oproept via het indrukken
van een willekeurige toets en die telkens automatisch na vijf seconden terug verdwijnt. Deze
menubalk bestaat niet uit een aantal knoppen, maar geeft slechts visueel de mogelijkheden weer.
Deze zijn, naast het terugkeren naar het vorig venster, het afspelen, het pauzeren, het stoppen
en het snel vooruit en achteruitspoelen van het item. Deze acties worden verricht via de toetsen
van de afstandsbediening. De tweede component geeft linksboven de titel van het item aan.
Indien de gebruiker op de play-, pause-, stop-, FFW- of FRW-toets drukt, dan wordt deze actie
doorgegeven aan de VoD-server, die de gateway aanstuurt om de desbetreffende actie uit te voe-
ren. Momenteel kan deze gateway enkel play, pause en stop aan. Indien men op de pauze-toets
drukt, wordt het beeld spijtiggenoeg niet vastgehouden maar kleurt het zwart. Indien men erna
op de play-toets drukt, speelt de video terug verder af. De film wordt opnieuw op het startpunt
gezet door het indrukken van de stop-toets.
Ook hier is het mogelijk om extra informatie over een film op te vragen. Indien de gebruiker
deze informatie wenst, wordt er eerst nagegaan of deze al opgehaald is en bijgevolg zich reeds in
de opslageenheid bevindt. Wanneer dit het geval is, wordt er een nieuw MovieInformationScreen
opgestart met de filmgegevens. Zo niet, geeft deze klasse de client connection module de opdracht
de filminformatie op te vragen. Ondertussen verschijnt er een nieuw MovieInformationScreen-
venster met de melding dat de gegevens van de server gehaald worden. De RequestProcessor
verkrijgt het antwoord van de movie information server, parst het en levert een Movie-object
terug aan de VodScreen-klasse. Die geeft deze gegevens door aan de MovieInformationScreen-
klasse, die ze afbeeldt. Een afbeelding van dit scherm is terug te vinden in C.7.
De filminformatie is opgebouwd als een grote String met opmaak, getoond in een HScrollComp.
Wanneer men later de movie information server uitbreidt zodat ze nog meer informatie levert,
wordt dit eenvoudigweg opgevangen door die extra informatie gewoon aan die String toe te
voegen. Via de pijltjes omhoog en omlaag kan men scrollen doorheen de gegevens. Via de
back-toets keert men terug naar het overzichtscherm.
4.8 User Suggestion Module 77
4.8 User Suggestion Module
4.8.1 Aanbevelingsalgoritmes
Soorten
Er is momenteel reeds heel wat onderzoek naar personalisatie van applicaties verricht. Perso-
nalisatie betekent hier dat het programma inhoud aangepast aan de gebruiker levert. Hiervoor
moet deze applicatie natuurlijk gegevens over de gebruiker verzamelen. Aan de hand daarvan
wordt een profiel opgesteld. Op basis van dit profiel levert de applicatie gebruikersspecifieke
informatie. Indien men zelf de nodige informatie ingeeft, dan spreekt men van expliciete syste-
men. Ze verwerken de gegevens die hen aangeleverd worden. Wanneer deze gegevens puur op
basis van een leerproces worden bekomen, dan spreekt men van impliciete systemen. Deze syste-
men hebben als groot nadeel dat ze eerst voldoende informatie moeten verzamelen om accurate
resultaten te bekomen. Dit staat beter bekend onder de term ”koude-startprobleem”(cold-start
problem).
Toegepast op een EPG, betekent dit dat men de kijker op basis van hun profiel aanbevelingen
aanreikt. Hierbij kan men een aantal mogelijke systemen hanteren. Volgens [4] zijn er drie
soorten gebruikers:
• doe-het-voor-mij gebruikers
Deze gebruikers wensen een volledig automatisch systeem waarbij ze zelf niks hoeven te
doen. Een impliciet systeem is hier uitermate geschikt. Ze registreert en analyseert het
kijkgedrag en levert op basis hiervan aanbevelingen. De kijker hoeft enkel tv te kijken.
• laten-we-het-samen-doen gebruikers
Deze gebruikers willen het systeem wel helpen, maar hebben geen zin om er teveel tijd aan
te besteden. Dit kan gebeuren onder de vorm van feedback. De kijker heeft de mogelijkheid
om bijvoorbeeld een score in te geven nadat hij een programma bekeken heeft.
• ik-doe-het-zelf gebruikers
In deze laatste groep wil men hun eigen profiel volledig zelf samenstellen zodat het on-
middellijk goede en betrouwbare resultaten levert zonder een lange leertijd.. Dit vergt
natuurlijk wat inspanningen.
Daarnaast bestaan er ook algoritmes die voorgedefinieerde stereotypen bevatten (zie vb.
4.8 User Suggestion Module 78
[14] en [19]). Deze aanpak is gebaseerd op de vaststelling dat vaak mensen opgesplitst kun-
nen worden in groepen die dezelfde kenmerken vertonen. Via vraag en antwoord bepaalt de
applicatie onder welk profiel de kijker valt opdat hij goede suggesties kan aanbieden. Deze
vragen betreffen je leeftijd, je geslacht, je burgerlijke stand, je financiele toestand, je graad
van geschooldheid, . . . Iedereen opdelen in lades is echter onmogelijk. Er wordt nagegaan welke
combinatie van profielen het best bij je past. Aan de hand van dit systeem beweert men het
koude-startprobleem te kunnen verhelpen. De gebruiker moet immers het zelflerend systeem
slechts een minimum aan informatie verschaffen.
Zoals in de meeste gevallen, levert ook hier het gebruik van hybride systemen een ware ver-
betering. In [5] bespreekt men een architectuur waarbij men verschillende soorten algoritmes
bundelt om op die manier de voordelen te combineren tot een goed functionerend geheel. Dit
gebeurt op een statische manier. Telkens leveren de drie eenheden (impliciet, expliciet en ste-
reotypisch) een bijdrage tot het leveren van de suggesties. In [26] gaat men hierin nog een stuk
verder. Ze combineren de verschillende eenheden op een dynamische en intelligente manier. Drie
factoren bepalen de wijze waarop de verschillende eenheden samenwerken:
• gebruiker
Wanneer een gebruiker nieuw is, dan is er weinig informatie beschikbaar over hem of haar.
Bijgevolg mogen de algoritmes die vooral gebruik maken van specifieke kennis over deze
persoon in het begin niet al te zwaar doorwegen.
• metadata
De hoeveelheid beschikbare metadata bepaalt in grote mate de geschiktheid van inhouds-
gebaseerde algoritmes.
• systeem
Sommige technieken hebben nood aan actieve interactie, beschikbare metadata, initiele
opstartgegevens, . . . Deze zijn niet altijd in dezelfde mate beschikbaar. Afhankelijk hiervan
moet opnieuw het juiste evenwicht tussen de verschillende algoritmes gevonden worden.
Deze EPG bundelt een aantal verschillende soorten algoritmes. Deze leveren elk apart een
aantal suggesties. Op basis van hun eigen schatting naar de betrouwbaarheid (zie 4.8.2) van
hun resultaten krijgen de ene aanbevelingen voorrang op de andere. Op die manier bekomen
we een lichte vorm van dynamische samenwerking. De EPG richt vooral zijn pijlen op het
4.8 User Suggestion Module 79
zelflerend aspect. Televisie kijken is en blijft immers een passief gebeuren. Ze laat daarentegen
wel toe het leerproces te versnellen door een volledig uitgewerkt profiel in te stellen. Maar ze
laat de gebruiker hier volledig in vrij. Het opstellen van dit profiel kan op elk ogenblik gebeuren.
Men hoeft deze gegevens niet per se in het begin in te voeren. Het systeem houdt automatisch
rekening met de eerder opgeslagen en verwerkte informatie.
Meerdere gebruikers
Het tv-kijken is meestal een familiegebeuren. Het suggestiesysteem moet dus voor elk lid van
het gezin goede aanbevelingen produceren. Ze moet dus als het ware de kijker identificeren om
zijn of haar favoriete programma’s te zoeken zonder dat hij of zij zich moet aanmelden. Men
zou dit aanmeldingsproces immers te vaak als een last zien. En wie moet er zich aanmelden
wanneer men met meerdere personen naar tv kijkt?
Het Family Interactive TV systeem (FIT, zie [14]) probeert deze doelstellingen in de mate
van het mogelijke te realiseren. FIT bouwt een aantal groepen van stereotypes. Hiervoor moet
de gebruiker drie stappen doorlopen:
• het bepalen van de stereotype door het ingeven van je leeftijd en je job
• een score aan elk genre geven
• per tijdsslot ingeven wat de kans is dat je op dat moment tv kijkt
Aan de hand van de huidig bekeken programma’s bepaalt FIT wie er naar tv kijkt, kiest de
juiste groep en levert aan de hand daarvan de suggesties.
Het zelflerend aspect is hier herleid tot het verwerken van feedback. Het algoritme levert een
aantal suggesties en zet de drie belangrijkste bovenaan. Naargelang de keuze, wordt positieve
of negatieve feedback terug verwerkt in het relevant profiel.
In dit artikel linkt men de tijd aan een gebruiker en de gebruiker aan een aantal genres. Maar
eenzelfde persoon zal ook een verschillend gedrag vertonen naargelang het tijdstip. In de vroege
avond zal men bijvoorbeeld liever naar een nieuwsmagazine kijken en in de late avond naar een
film. In deze EPG worden genres rechtstreeks gelinkt aan tijdssloten. In de late middag zullen
wellicht eerder de kinderen naar kinder-en jeugdprogramma’s kijken en in de late avond gaan de
volwassenen hoogstwaarschijnlijk naar een film kijken. Het registreren en analyseren van welke
genres men op welke tijdsstippen bekijkt is dus voldoende. In het huidig systeem is er enkel
4.8 User Suggestion Module 80
onderscheid tussen een weekdag en het weekend gemaakt. Een dag wordt verder opgesplitst in
tien tijdssloten.
4.8.2 Metadata
Een zelflerend systeem registreert de acties van de gebruikers, verwerkt ze en onthoudt ze. Maar
welke metadata moet er verzameld worden? En hoe moet deze bewaard worden?
Er zijn twee soorten programma’s die het systeem in rekening moet brengen. Enerzijds heb
je deze die men op een heel regelmatige basis bekijkt en die dus goed gekend zijn. Anderzijds
heb je de ongekende programma’s waarvan het suggestiesysteem vermoedt dat men deze wel
zou smaken omdat ze gelijkaardig aan de veel bekeken programma’s zijn (zie [25]). Om ook
deze laatste groep op te nemen, is het belangrijk dat het systeem bijhoudt welke genres er op
welke tijdstippen vaak bekeken worden. Een genre is natuurlijk nogal breed. In [25] geven de
auteurs een methode aan om specifieke metadata te verzamelen over de bekeken programma’s.
Ze verwijderen alle betekenisloze woorden zoals de, van, over, in, . . . uit de beschrijving en geven
elk van de overblijvende woorden een gewicht naargelang hun belangrijkheid. Op die manier
bekomt men na een tijdje per genre een lijst van woorden die een positief en die een negatief
effect hebben. Het algoritme toetst de beschrijving van een programma aan beide lijsten met
woorden om hieruit te besluiten of de gebruiker dit programma al dan niet graag zal zien.
De gegevens die men verzamelt kan men op verschillende manieren bewaren. Men kan
bijvoorbeeld alle historische gegevens bijhouden (globaal), of men kan bijvoorbeeld enkel de re-
gistraties van maximum zeven dagen oud in rekening brengen (dynamisch). In dit laatste geval
is het mogelijk snel in te spelen op een wijziging in het kijkgedrag. Wanneer men immers maan-
denlang vooral naar komedies kijkt, en opeens de romantische film ontdekt, zal deze laatste in
de globale tabellen van de databank helemaal niet voldoende doorwegen om ook aanbevelingen
op te leveren. Dankzij de dynamische opgeslagen gegevens echter wel.
Beide mogelijkheden zijn voorzien in het suggestiesysteem van deze EPG. Het dynamisch ge-
deelte is echter wegens tijdsgebrek langs de serverzijde niet volledig uitgewerkt.
Een aanbeveling in [5] bevat telkens een waarde die aangeeft hoe graag de gebruiker dit
programma wellicht zal zien en hoe zeker het algoritme van zijn beslissing is. Dankzij deze laatste
waarde kunnen de verschillende algoritmes op een dynamische manier samenwerken. Indien een
algoritme niet de nodige gegevens bevat en bijgevolg helemaal niet zeker van zijn keuzes is, kan
4.8 User Suggestion Module 81
hij dit gemakkelijk aangeven zodat zijn verdiensten niet in rekening worden gebracht.
Dit idee werd volledig overgenomen.
Films hebben specifieke gegevens zoals acteurs, actrices en de regisseur. [27] beweert dat een
acteur of actrice meestal een gelijkaardige rol speelt in een film, zodat de cast een belangrijke
indicatie levert of men de film al dan niet graag zal zien. Beschouw bijvoorbeeld de acteurs Tom
Cruise en Tom Hanks. Beide zijn enorm gerenomeerde acteurs en bijgevolg echte publiekstrek-
kers. Ze komen eerder over als een karakter dan als een persoon. Tom Cruise speelt altijd ”de
besten”. Hij is de beste spion in Mission Impossible, de beste gevechtspiloot in Top Gun, de
beste barman in Cocktail, . . . Tom Hanks speelt telkens ”een doodnormaal persoon dat buitenge-
wone dingen meemaakt”. Hij speelt een normale jongen die verliefd wordt op een zeemeermin in
Splash, een gewone gevangenisbewaker die getuige is van mirakels in The Green Mile, een gewo-
ne jongen van een lager intelligentieniveau die een ongelofelijk leven leidt in Forest Gump, . . .
Het suggestiesysteem uit deze EPG neemt bijgevolg ook de cast en de regisseur in rekening.
Deze informatie is echter tijdsonafhankelijk en wordt dus algemeen opgeslagen.
4.8.3 Intern systeem
Architectuur
Het suggestiesysteem bestaat uit drie grote delen. Deze worden aangestuurd door de UserSug-
gestionController. Deze controller implementeert de UserSuggestionInterface die de publieke
functies gericht naar de hoofdmodule levert. Deze functies zijn: het opvragen van de aanbe-
velingen, het registreren van de suggestievoorkeuren en het registreren van een gebruikersactie.
De architectuur van deze module is grotendeels gebaseerd op [2]. Ze is echter aangepast aan
de noden van deze EPG. Het schema in D.9 biedt een vereenvoudigd overzicht, terwijl D.8 het
volledig UML-schema weergeeft.
Registratie De registratiesubmodule ontvangt gebruikersacties en het ingegeven gebruikers-
profiel. Dit profiel kan zonder meer doorgegeven worden aan de LogSystem-klasse die ze omzet
naar een XML-bestand en naar de server verstuurt. Het profiel bestaat hoofdzakelijk uit twee
onderdelen:
• per dag en per tijdsslot de kans dat de gebruiker op dat moment tv kijkt
• per genre een score dat de waardering voor dit genre bepaalt
4.8 User Suggestion Module 82
De overige gegevens worden via het zelflerend systeem bekomen.
De gebruikersacties worden toegevoegd aan een lijst. Daarna onderzoekt de UserActionsCollec-
tor -klasse of er meerdere gebruikersacties kunnen gecombineerd worden.
Bijvoorbeeld, wanneer iemand naar een programma begint te kijken, dan wordt dit geregistreerd.
Wanneer hij of zij nog voor het eind van het programma overschakelt naar een andere zender
wordt dit opnieuw geregistreerd. Men mag deze twee acties echter nog niet onmiddellijk verwer-
ken, want het programma is nog niet ten einde. Misschien wordt er enkel overgeschakeld omdat
er bijvoorbeeld reclame is. Zodoende mag men nog niet de conclusie trekken dat de gebruiker
het programma niet volledig tot het einde heeft bekeken. Er is dus nood aan een complex proces
dat alles mooi bijhoudt en verwerkt tot effectieve waarnemingen met de duur dat een gebruiker
naar een programma keek. Dat proces moet rekening houden met mogelijke reclameblokken
waarin men meestal er lustig op door zapt.
Een verwerkte gebruikersactie bevat
• de programmagegevens: programmanaam, zender en genre
• de relatieve tijdsduur (0-1) die aangeeft hoelang de gebruiker naar het programma keek
• een tijdsstempel
• hoe de gebruiker het programma gekozen heeft, bv. als suggestie verkregen
• hoe graag hij of zij dit programma zag
Deze verwerkte waarnemingen worden opnieuw doorgegeven aan de LogSystem-klasse die ze
omzet naar XML en naar de server stuurt voor verdere verwerking.
Opslageenheid Deze module heeft ook een eigen mini-opslageenheid vertegenwoordigd door
de klasse USData. De UserSuggestionController vraagt de gegevens op aan de databank en vult
de opslageenheid met de verkregen informatie. Deze beschikt over de mogelijkheid om ofwel alle
gegevens of om enkel een aantal specifieke gegevens op te vragen. Naar gelang de capaciteit van
de set-top box is het misschien niet altijd aangewezen om alle gegevens in een keer op te vragen
en te verwerken. Het XML-bestand kan immers nogal groot uitvallen (zie A.3.4). Deze specifieke
aanvraag wordt aan de hand van een XML-bestand (zie A.3.3) doorgegeven aan de server. Per
item kan men aangeven of men al dan niet alle informatie erover wenst te verkrijgen. Men kan
bijvoorbeeld zoals in A.3.3 aangeven dat men niet alle informatie over de subtypes van het type
4.8 User Suggestion Module 83
12 wilt kennen, maar enkel over de subtypes 0, 1 en 2. De huidige algoritmes gebruiken enkel
de gegevens uit het huidig tijdsslot. Bijgevolg moet het systeem enkel deze gegevens opvragen.
Dit levert een enorme reductie (tot twintig maal!) aan gegevens die getransporteerd en verwerkt
moeten worden. Het parsen van de ontvangen gegevens gebeurt in de client connection module
die een USDataObject aflevert.
De USData-klasse bevat ook een verwijzing naar de EPGdata module opdat de algoritmes ook
toegang hebben tot de beschikbare programma’s.
Aanbevelingen Het hoofddoel van het suggestiesysteem is natuurlijk het afleveren van een
aantal aanbevelingen. De RecommenderCollector -klasse bevat hiervoor een aantal verschillende
algoritmes en stuurt deze aan. Elk van deze algoritmes heeft een referentie naar de USData-
klasse om alle nodige informatie te bekomen. De algoritmes worden gebundeld in de subpackage
USalgorithms. Elk algoritme implementeert de klasse USRecommenderAlgorithmInterface. Op
die manier kan men simpelweg algoritmes toevoegen. Ze moeten enkel de functies uit deze
interface implementeren, waarvan eigenlijk enkel de eerste van belang is:
• public Recommendation[] startAlgorithm();
• public short getAlgorithmNumber();
De klasse Recommendation bevat naast een programma ook een waarde die de vermoedelijke
appreciatie van de kijker aangeeft (likeliness) en een waarde die weergeeft hoe zeker het algoritme
van zijn keuze is (confidence). Indien meerdere algoritmes een zelfde programma aanraden,
verwijdert deze klasse de duplikaten en behoudt de meest betrouwbare. Daarna worden alle
aanbevelingen gesorteerd volgens de vermoedelijke appreciatie van de kijker.
Kiesalgoritmes
Hybride systemen met verschillende soorten algoritmes leveren betere resultaten dan systemen
met slechts een soort algoritme. Hierdoor is de uitbreidbaarheid van dit systeem enorm belang-
rijk. Dit wordt zoals hierboven aangegeven, gerealiseerd dankzij de interne architectuur en de
USRecommenderAlgorithmInterface. Momenteel is er slechts een algoritme geımplementeerd.
Deze illustreert de werking van deze module.
USAFavSubtypes Dit algoritme vraagt eerst de twee meest bekeken programmatypes in het
huidig tijdsslot op. Per gekozen type bepaalt het de twee populairste subtypes. Zo bekomt men
4.8 User Suggestion Module 84
vier combinaties. Men neemt de twee beste en zoekt de programma’s die aan dit genre voldoen.
Wanneer de opslageenheid er in totaal minder dan 10 gevonden heeft, zoekt hij verder naar de
overige twee combinaties. Per aanbeveling wordt via specifieke functies de betrouwbaarheid en
de appreciatie bepaald en de resultaten gebundeld tot een rij van Recommendation-objecten.
Dit is een simpel, maar efficient algoritme dat goede resultaten blijkt op te leveren.
BESPREKING VERSCHILLENDE SERVERS 85
Hoofdstuk 5
Bespreking verschillende servers
5.1 Movie Information Server
Een EPG moet de gebruiker zoveel mogelijk informatie leveren over de beschikbare program-
ma’s. Films zijn hier een dankbaar voorbeeld van. De metadata van films kan namelijk zeer
uitgebreid worden. Om de gebruikers deze informatie te leveren, is er een movie information
server ontwikkeld.
De grootste filmdatabank ter wereld is IMDb (Internet Movie Database [15]). Deze databank
is gestart in 1990 door filmfanaten die filmgegevens bijhielden. Acht jaar lang kende deze
databank een exponentiele groei, mede dankzij de opkomende technologische mogelijkheden.
Om alles te kunnen blijven betalen, zochten ze bij IMDb naar een bedrijf die hen financieel wou
helpen, maar die hen nog steeds toeliet om hun diensten gratis op het internet aan te bieden.
Amazon.com verscheen als reddende engel. Amazon.com zag IMDb als een handige bron om
hun verkoop van dvd’s bij te staan met de informatie uit IMDb.
IMDb stelt hun databank gratis ter beschikking voor niet-commerciele toepassingen. Hierbij
is het gebruik ook beperkt tot de tekstbestanden die ze via FTP aanbieden. Ze leveren software
voor UNIX, AMIGA, OS/2, Acorn en Windows om de databank te genereren uit die tekstbe-
standen en ze te doorzoeken. De broncode voor het UNIX-gebaseerd systeem wordt bovendien
vrijgegeven. Mijn keuze als informatiebron voor mijn movie information server was dus snel
gemaakt. . .
5.1 Movie Information Server 86
5.1.1 Inhoud
De IMDb-databank bevat alle films van 1891 tot nu. Momenteel bevat deze meer dan 780.000
titels, meer dan 2 miljoen cast- en medewerkersgegevens en noem maar op.
Belangrijk is dat men per film een score kan ingeven. Op die manier kan een gebruiker eenvoudig
te weten komen hoe goed een film is. De databank bevat momenteel bijna 55 miljoen stemmen
van meer dan 2 miljoen verschillende personen. Deze scores kunnen dus als representatief be-
stempeld worden1.
5.1.2 Werking & mogelijkheden
Systeem
De movie information server is geschreven in de programmeertaal C en draait op een UNIX-
gebaseerd besturingssysteem. Op die manier was het mogelijk de bestaande command line
software uit te breiden naar een serversysteem. Het systeem bestaat uit 3 delen: de server zelf,
een connectie tussen de server en de databank en het DBMS (database management system) dat
de bestanden doorzoekt naar de juiste gegevens. Dit laatste werd ontwikkeld door IMDb. De
server zelf en de connectie tussen beide zijn door mij ontwikkeld. De huidige server kan bijgevolg
ook niet alle gegevens leveren die de databank bevat. Het is enkel bedoeld om aan te tonen wat
de mogelijkheden zijn. Het ontbreekt mij de tijd om een uiterst performante en stabiele server
te ontwikkelen die alle gegevens uit de databank kan converteren naar een XML-bestand om
deze over het internet te versturen.
De gegevens worden opgevraagd via het RCRP (Return Channel Request Protocol, zie 4.2.1).
De payload bevat enkel de naam van de titel en het jaartal tussen haakjes. Dit jaartal is vereist
omdat er enorm veel heruitgaves zijn. Voor de content providers mag het geen onoverkomelijk
iets zijn om dit jaartal telkens mee te sturen.
Het antwoord van de server wordt in een XML-bestand gegoten. (zie bijlage A.1)
De huidige server levert de volgende gegevens :
• Titel
• Jaar van uitgave
• Genres1zie http://www.imdb.com/database statistics
5.1 Movie Information Server 87
• De gebruikerswaardering en distributiegegevens hiervan
• Regisseur
• Volledige cast
– Naam van de acteur/actrice
– Naam van het personage in de film
• Kort inhoud
Data
De databank bestaat dus eigenlijk uit bestanden die onleesbare bytegegevens bevatten. Deze
worden automatisch gegenereerd uit de tekstbestanden die men van de FTP-server kan downlo-
aden. Het zou natuurlijk veel eleganter en performanter zijn om met een echt databanksysteem
te werken waarin de gegevens in tabellen opgeslagen zitten. Maar de gebruikersvoorwaarden
(Content Licensing) van IMDb laten dit niet toe. Op het internet zijn er wel degelijk zelf ge-
maakte tools te vinden die deze bestanden omzetten naar gegevens in bijvoorbeeld een MySQL-
databank.2 Maar deze hebben twee grote nadelen. Ten eerste duurt het genereren van deze data
lang. Men spreekt hier gemakkelijk over een paar uur. Maar het grootste nadeel is dat men
deze databank niet automatisch up-to-date kan houden. Dit in tegenstelling tot het systeem
met bestanden dat IMDb aanbiedt. Bijgevolg zou men deze databank telkens volledig moeten
downloaden en erna ze volledig opnieuw converteren.
Het systeem van IMDb zorgt ervoor dat men de databank automatisch up-to-date kan houden
zonder opnieuw de volledige databank te moeten downloaden en genereren. Er wordt gewerkt
met diff-bestanden. Deze worden volledig automatisch via FTP gedownload en verwerkt.
Cache
Het DBMS heeft een soort van interne cache waardoor het opvragen van reeds opgevraagde film-
informatie, enorm snel verloopt. Zelf heb ik een externe softwarematige cache eraan toegevoegd.
Telkens wordt de aanvraag en het antwoord ervan opgeslagen. Deze gegevens zijn toch statisch.
Op die manier moet de server nooit tweemaal voor dezelfde filmgegevens een verbinding met
de databank opstellen. Momenteel ondersteunt de Xlet-applicatie nog niet de functionaliteit2bv. http://www.jmdb.de/index.html
5.1 Movie Information Server 88
om gegevens over gelijk welke film op te vragen. Bijgevolg zullen de Xlets momenteel telkens
dezelfde films opvragen, namelijk de films die deze dag op tv te zien zijn. De externe cache kan
dus de prestaties van het systeem heel veel verbeteren en het heel wat schaalbaarder maken.
Wanneer ik deze server thuis op mijn eigen computer draai (Knoppix besturingssysteem)
werkt alles perfect. Eerlijkheidshalve moet ik eraan toevoegen dat eenmaal de server geınstalleerd
werd op de computer in het testlabo(Ubuntu besturingssysteem), het cachegedeelte soms raar
deed. Deze gaf af en toe verkeerde informatie terug. Ik kon echter geen fout terugvinden in de
code en heb de versie in het testlabo laten werken zonder externe cache om er zeker van te zijn
dat deze altijd de juiste informatie teruggeeft.
5.1.3 Installatie
De databankbestanden kunnen via FTP opgehaald worden :
• ftp.fu-berlin.de (Duitsland)
• ftp.funet.fi (Finland)
• ftp.sunet.se (Zweden)
Na decompressie worden de list-files geplaatst in het mapje ”lists”.
Via het commando ”make databases” wordt de volledige databank gegenereerd.
Via het commando ”make install” wordt het volledige systeem geınstalleerd.
Om de server mee te integreren zijn de volgende commando’s nodig:
• gcc -c msFunctions.c -o msFunctions.o
• gcc -c movieServer.c -o movieServer.o
• gcc -O -o movieServer movieServer.o msFunctions.o dbutils.o titlesearch.o years.o bio-
graphies.o aka.o ratings.o trivia.o plot.o titleinfo.o literature.o castcomp.o movielinks.o
business.o laserdisc.o log.o
De server wordt nu opgestart via het commando ”./movieServer”
5.2 AEPG server 89
5.1.4 Uitbreidingen
Momenteel is het enkel mogelijk om de basisinformatie op te halen. De databank bevat
echter nog veel meer informatie, namelijk biografieen, weetjes, grappige uitspraken, . . .Men
kan de server uitbreiden om ook deze informatie te leveren.
Aan de Xlet-zijde kan men ook de mogelijkheid aanbieden om informatie van een zelf in te
geven film op te vragen. De server kan hier extra interactiviteit bieden door de verschillende
juiste mogelijkheden door te geven indien de gebruiker de titel verkeerd spelde of indien
er meerdere heruitgaves waren.
5.2 AEPG server
De ”Advanced Electronic Program Guide server” dient als opslagmedium voor de gebrui-
kersgegevens die voor een langere tijd dan de levensduur van de applicatie bewaard moeten
worden. De huidige set-top boxen in het testlabo bevatten immers geen permanent geheu-
gen. De server identificeert de abonnee aan de hand van zijn IP-adres. We veronderstellen
stilzwijgend dat de provider eenduidig kan bepalen welk IP-adres bij welke gebruiker be-
hoort. Deze gegevens kan men onderverdelen in twee grote delen: de configuratiegegevens
en de gegevens die dienen om de gebruiker een aantal aanbevelingen te leveren.
Deze server is een multi-threaded server die het RCRP (zie 4.2.1) ondersteunt. Per aan-
vraag wordt er een thread opgestart die het protocol analyseert. Aan de hand van het
type zal die thread ofwel de configuratie-eenheid ofwel de suggestie-eenheid aansturen om
de aanvraag te verwerken. Indien de server een antwoord moet versturen naar de client,
leveren de ophaaleenheden een byte-array, dewelke het antwoord in XML-formaat bevat.
Dit wordt vervolgens terug naar de Xlet verstuurd.
5.2.1 Databank
De AEPG server gebruikt PointBase als databank omdat het J2EE-pakket deze standaard
meelevert. Er worden hier dus zeker geen compatibiliteitsproblemen verwacht. De klasse
DBMS vormt de verbindingsbrug tussen de server en de databank. Ze wordt geınitialiseerd
aan de hand van de naam van de databank, de login en het paswoord. Ze zorgt voor het
opzetten en het verbreken van de connectie en het uitvoeren van een SQL-statement.
5.2 AEPG server 90
Hierbij maakt deze klasse een onderscheid tussen het ophalen van informatie waar de
functie een ResultSet teruggeeft en het aanpassen van welbepaalde gegevens.
De databank bevat momenteel dertien tabellen (zie bijlage B voor een overzicht). De tabel
USERIDTABLE zet het IP-adres om naar een gebruikers-id. Aan de hand van die id kan
men de gebruikersspecifieke gegevens opvragen.
Het configuratiegedeelte bevat de volgende tabellen:
– LANGUAGETABLE levert de voorkeurstaal
– RCTABLE levert de terugkeerkanaalparameters
– SERVERIDTABLE zet de naam van een server om in zijn server-id
– SERVERSTABLE levert het IP-adres en poortnummer van een server
– CHANNELTABLE zet de naam van een zender om in zijn zender-id
– TVSEQTABLE levert de volgorde van de tv-zenders
– RADIOSEQTABLE levert de volgorde van de radiozenders
Het suggestiegedeelte bevat de tabellen:
– PROGRAMTYPEGLOBALTABLE levert voor elk type per dag en per tijdslot de
waardering ervan
– PROGRAMSUBTYPEGLOBALTABLE levert voor elk subtype binnen elk type per
dag en per tijdslot de waardering ervan
– CHANNELGLOBALTABLE levert voor elke zender per dag en per tijdslot de waar-
dering ervan
– CASTTABLE levert de globale waardering voor een acteur of actrice
– DIRECTORTABLE levert de globale waardering voor een regisseur.
Men kan de databank verder uitbreiden met dynamische tabellen die de gegevens van
bijvoorbeeld de laatste zeven dagen voortschrijdend bijhouden. Op die manier kunnen
de algoritmes ook inspelen op de meest recente trends binnen het tv-kijken. Wanneer de
gebruiker opeens afwijkt van zijn typisch stramien, zal dit niet onmiddellijk af te leiden
vallen uit de globale gegevens. De dynamische tabellen houden echter geen rekening met
het verre verleden en onthouden slechts wat de abonnee in het nabije verleden bekeek.
5.2 AEPG server 91
5.2.2 Configuration server
Het subtype bepaalt welke informatie de ConfigRetriever -klasse moet leveren. Hiervoor
zijn specifieke SQL-statements voorzien. Men zet een verbinding met de databank op
aan de hand van de DBMS -klasse en voert de nodige SQL-statements uit. De verkregen
gegevens worden verwerkt, in XML-formaat gegoten en teruggegeven aan de server die ze
terugstuurt naar de Xlet.
5.2.3 User suggestion server
De UsersuggRetriever -klasse verwerkt de aanvragen voor het suggestiegedeelte. Er zijn
globaal gezien twee verschillende soorten aanvragen: het registreren van gegevens en het
ophalen ervan.
Registreren van suggestiegegevens
De server krijgt de opdracht om gebruikersacties of suggestievoorkeuren te bewaren. Deze
gegevens worden in specifieke XML-formaten geleverd, zie bijlages A.3.1 en A.3.2 respec-
tievelijk. Een bespreking van deze formaten is terug te vinden in 4.8.3. Het bestand wordt
geparset en de bekomen gegevens worden via de nodige SQL-commando’s in de databank
bewaard.
Ophalen nodige gegevens
De EPG kan alle opgeslagen gegevens uit de databank opvragen om op basis hiervan een
aantal suggesties te leveren. Het XML-bestand hiervan bleek nogal groot uit te vallen.
Daarom heeft de applicatie ook de mogelijkheid enkel de informatie van een welbepaald
tijdslot en dag op te vragen. De aanbevelingsalgoritmes hebben immers enkel deze gegevens
nodig om binnen het huidig tijdslot resultaten te bekomen. Dit zorgt voor een grote
reductie van de nodige gegevens die de server moet transporteren en die de applicatie
moet verwerken.
Bij een specifieke aanvraag stuurt de applicatie een XML-bestand dat een beschrijving
van de gewenste informatie weergeeft (zie bijlage A.3.3). Deze aanvraag wordt geparset
en verwerkt. Volledig automatisch bouwt de server een aantal SQL-commando’s op om de
5.3 VoD server 92
nodige informatie uit de databank op te vragen. De bekomen informatie wordt opnieuw
gebundeld tot een XML-bestand (zie bijlage A.3.4) en verstuurd over het netwerk naar de
applicatie.
5.3 VoD server
Deze server werd reeds besproken in 4.3.4 op pagina 39.
BESLUIT 93
Hoofdstuk 6
Besluit
6.1 Algemeen besluit
De EPG biedt talrijke functies opdat men op een gebruiksvriendelijke wijze de verschillen-
de programma’s op tv kan doorzoeken. Het hoofdmenu levert op een visueel aantrekkelijke
manier toegang tot de verschillende mogelijkheden. Dankzij de informatieverkenner kan
men alle mogelijke zenders overlopen, herinneringen en opnames instellen zonder ook maar
een seconde van je programma te missen. De mogelijkheid bestaat om alle huidige pro-
gramma’s op te vragen, zodat men onmiddellijk zicht heeft op wat er op dit ogenblik op tv
te bekijken valt. Een volledig overzicht is natuurlijk ook beschikbaar. Via het categorie-
scherm is het mogelijk om programma’s van een bepaald genre te zoeken. Het zoekscherm
biedt de mogelijkheid het volledig tv-overzicht te doorzoeken op kernwoorden. Dankzij
een handig menuutje kan men genres aan de kernwoorden toevoegen zonder ze te moeten
intypen.
De EPG is niet passief maar actief, met als belangrijkste factor het zelflerend aspect. De
EPG vormt een familieprofiel van de gebruikers zodat het suggestiesysteem hen een aantal
aanbevelingen kan aanreiken. De gebruiker hoeft bijgevolg niet meer zelf te zoeken. De
EPG zoekt voor hen! Dit systeem vereist natuurlijk een zekere leertijd. Indien de gebruiker
dit wenst, kan hij vooraf zijn voorkeuren ingeven om dit leerproces heel wat te versnellen.
Hij blijft hierin echter vrij. De verwerkte informatie evenals de configuratiegegevens worden
op een externe server opgeslagen aangezien de set-top boxen in het testlabo niet over een
permanent geheugen beschikken.
6.1 Algemeen besluit 94
Momenteel is er slechts een suggestiealgoritme geımplementeerd. Dit eenvoudig algoritme
bepaalt de meest bekeken genres op het tijdstip van aanvraag en zoekt programma’s die
hieraan voldoen. Dit blijkt goede en betrouwbare resultaten op te leveren.
De kern van het suggestiesysteem integreren in de volledige architectuur primeerde op
het ontwikkelen van talrijke algoritmes. Het systeem is zodanig ontworpen dat men heel
gemakkelijk nieuwere en wellicht gesofisticeerdere algoritmes kan inpluggen, wat enorm
handig is voor iemand die zich voltijds bezighoudt met deze materie. Hij hoeft zich immers
geen zorgen meer te maken over het onderliggend systeem.
De VoD-server levert talrijke films en live events die men kan bekijken. Een overzicht hier-
van vindt men in de virtuele videotheek. Na het bestellen van een item, wordt deze op de
broadcast stroom geplaatst zodat de gebruiker er toegang tot krijgt. De besturingsfuncties
zoals afspelen, pauze, stop, vooruit-en achteruitspoelen zijn eveneens voorzien.
De movie information server stelt de volledige IMDb-filmdatabank ter beschikking. Ze stelt
de gebruikers in staat extra filminformatie op te vragen zoals onder andere de regisseur,
de acteurs en actrices en een gebruikerswaardering. Aan de hand van dit laatste kan men
de kwaliteit van de film wat inschatten, al blijft dit natuurlijk een subjectieve mening. De
databank bevat veel meer informatie dan de huidige server kan leveren. Bijgevolg is het
mogelijk deze nog heel wat verder uit te bouwen.
Aan de onderliggende interne systemen is het meest aandacht besteed. Zonder goede basis
is het moeilijk verder te bouwen aan een degelijke en betrouwbare applicatie. De func-
tionaliteiten werden gebundeld in verschillende modules, elk met hun specifieke taak en
verantwoordelijkheid. Het grafisch gedeelte staat hierdoor volledig los van de rest. Bijge-
volg is het geen enkel probleem om een compleet nieuwe grafische module te ontwikkelen en
dus het volledig uitzicht te vernieuwen. De modules zijn onafhankelijke eenheden die men
zelfs gemakkelijk in een volledig ander systeem kan pluggen. Het feit dat Kevin Hoekman
en David Plets een weliswaar vereenvoudigde versie van mijn importeer- en afspeelmodule
in hun systeem ingevoegd hebben is hier het grootste bewijs van.
De module die het terugkeerkanaal verzorgt levert een echte meerwaarde. Ze zorgt ervoor
dat geen enkel andere module zich ook maar iets van de werking van dit interactieka-
naal moet aantrekken. Dit systeem bevat bovendien een priority scheduler. Belangrijke
aanvragen zullen hierdoor steeds voorrang krijgen.
6.2 Algemene uitbreidingen en integraties 95
6.2 Algemene uitbreidingen en integraties
PVR
Zoals reeds eerder vermeld is de opnamefunctionaliteit niet verder uitgewerkt wegens het
ontbreken van de nodige hardware. De mogelijkheid tot opname is echter doorheen de hele
applicatie voorzien. Deze aanvraag stopt in de hoofdmodule. Van daaruit is het mogelijk
om deze door te geven aan de te ontwikkelen PVR-module.
Extra informatie & weetjes
Deze EPG heeft de mogelijkheid om zoals ook de tv-boekjes de laatste nieuwe weetjes over
de beroemdheden aan te bieden. Of om ook extra informatie bij specifieke programma’s
zoals Big Brother, Idool e.d. te verschaffen. Ze vervangt op die manier teletekst een beetje.
Om dit te realiseren moet men enkel een nieuw scherm voorzien die de inhoud grafisch
weergeeft, samen met een importeerplug-in die deze inhoud ophaalt van een specifieke
server. Beide kunnen opnieuw eenvoudigweg ingeplugd worden.
Filmdatabank
De movie information server levert de gebruiker extra informatie bij films. De EPG be-
schikt momenteel echter niet over de mogelijkheid om de volledige databank te doorzoeken
en willekeurige informatie op te vragen. Men kan dus nog een scherm ontwikkelen waarbij
men bijvoorbeeld de biografie van een bepaalde acteur of actrice of alle mogelijke infor-
matie over een willekeurige film kan opvragen. De server zelf is momenteel enkel in staat
om de basisinformatie aan te bieden. Men moet deze dus wat uitbreiden zodat hij ook
interactief de overige gegevens kan leveren. Indien de gebruiker namelijk geen exacte titel
ingeeft of er zijn meerdere mogelijkheden die eraan voldoen, dan moet de server de moge-
lijke overeenkomsten leveren waaruit de gebruiker kan kiezen om de informatie ervan op
te vragen.
IP2DVB gateway
Deze gateway, ontwikkeld door Kristof Demeyere, wordt reeds gebruikt door de VoD-
server. De gateway plaatst de nodige films op de broadcast stream en levert de juiste
6.2 Algemene uitbreidingen en integraties 96
locators aan de VoD-server die ze verder doorgeeft aan de juiste applicatie.
Sportportaal
David Plets ontwikkelde een applicatie die de sportliefhebber verwent met alle mogelijke
informatie die hij maar kan bedenken. Dankzij zijn informatiebalken is het mogelijk de
gebruiker op de hoogte te houden van de lopende wedstrijden terwijl hij naar andere
programma’s kijkt. Het instellen en aansturen van deze informatiebalken zou men vanuit
de EPG kunnen regelen. We kunnen hier nog verder in gaan door beide applicaties volledig
aan elkaar te koppelen. Wanneer men informatie over de wedstrijden, de spelers, het
klassement enzovoorts wil, dan kan hij vanuit de EPG het sportportaal opstarten.
eID
De integratie van de elektronische identiteitskaart (eID1) biedt mogelijkheden bij het be-
stellen van VoD-items. Ze zorgt voor een veilige en eenvoudige identificatie van de gebrui-
ker.
Elke gebruiker kan zijn eigen taal, skin en volgorde van de zenders bepalen. Dankzij de
eID is het mogelijk een gebruiker binnen het gezin te identificeren om op die manier au-
tomatisch zijn instellingen in te laden. Dit mag echter zeker geen verplichting zijn want
velen zullen dit als een onnodige last beschouwen.
Ook binnen het zelflerend systeem ontstaan er nieuwe opportuniteiten dankzij de identi-
ficatie via de eID. Indien men bereid zou zijn om telkens in te loggen via zijn eID, kan
de EPG gebruikersspecifieke acties registeren en verwerken. Het opstellen van het fami-
lieprofiel wordt hierdoor overbodig. Het lijkt me echter weinig waarschijnlijk dat mensen
bereid zullen zijn telkens ze de televisie aansteken, eerst in te loggen via hun eID. En in
de meeste gevallen kijken er meerdere personen tegelijkertijd naar tv. Wie moet er dan
inloggen. . .
Instant messenger
Tv-kijken is een sociaal gebeuren. Vooral bij programma’s als voetbalwedstrijden, zang-
wedstrijden en dergelijke kijkt men liever samen met vrienden en kenissen dan alleen. Een1De thesis van Joost Cammaert handelt over de integratie van de eID binnen het MHP-platform.
6.2 Algemene uitbreidingen en integraties 97
instant messenger2 kan dit gevoel wat nabootsen door korte tekstberichtjes zoals ”Heb je
die goal gezien! Prachtig he!”of ”Amai, die kan echt niet zingen.” uit te wisselen tijdens
het tv-kijken. Via afbeeldingen die een bepaald gevoel uitbeelden (emoticons) kan men
ook zijn of haar mening uiten. Bij een zangwedstrijd is het bijvoorbeeld via emoticons
mogelijk per deelnemer je mening visueel weer te geven. Deze mogelijkheden toevoegen
aan de EPG zal vooral bij de jongeren aanslaan.
Men kan hierin zelfs nog verder gaan. Men plaatst een apparaat bij de tv dat een luid-
spreker en micro bevat. Via VoIP-verbindingen (Voice over IP) staat men in contact met
een aantal andere personen. Op die manier kan men live gewoon onderling communiceren
en je mening uiten over hetgeen zich op tv afspeelt.
Men kan de gebruiker ook de mogelijkheid bieden een lijstje samen te stellen met zijn of
haar favoriete programma’s en dit lijstje beschikbaar te maken voor zijn of haar contact-
personen.
2Kevin Hoekman ontwikkelde voor zijn thesis een instant messenger voor het MHP-platform
XML-BESTANDEN 98
Bijlage A
XML-bestanden
A.1 Filminformatie
<?xml version=”1.0” encoding=”UTF-8”?>
<movie>
<title>EuroTrip</title>
<genres>
<genre>Comedy</genre>
<genre>Adventure</genre>
</genres>
<year>2004</year>
<userrating>
<distribution>0000012101</distribution>
<rating>6.1</rating>
</userrating>
<director>Jeff Schaffer</director>
<cast>
<castmember>
<realname>Scott Mechlowicz</realname>
<moviename>Scott Thomas</moviename>
</castmember>
<castmember>
A.1 Filminformatie 99
<realname>Jacob Pitts</realname>
<moviename>Cooper Harris</moviename>
</castmember>
<castmember>
<realname>Kristin Kreuk</realname>
<moviename>Fiona</moviename>
</castmember>
<castmember>
<realname>Cathy Meils</realname>
<moviename>Mrs. Thomas</moviename>
</castmember>
<castmember>
<realname>Nial Iskhakov</realname>
<moviename>Bert</moviename>
</castmember>
<castmember>
<realname>Michelle Trachtenberg</realname>
<moviename>Jenny</moviename>
</castmember>
<castmember>
<realname>Travis Wester</realname>
<moviename>Jamie</moviename>
</castmember>
<castmember>
<realname>Matt Damon</realname>
<moviename>Donny</moviename>
</castmember>
<castmember>
<realname>Jessica Boehrs</realname>
<moviename>Mieke</moviename>
</castmember>
<castmember>
A.2 Configuratiegegevens 100
<realname>Fred Armisen</realname>
<moviename>Creepy Italian Guy</moviename>
</castmember>
</cast>
<plot>
When Scotty’s German online pen pal suggests they meet, he initially freaks out.
But then he discovers that she’s gorgeous, and heads out with three friends after
graduationto meet her. As they travel across Europe, the four friends have comical
misadventures.
</plot>
</movie>
A.2 Configuratiegegevens
<?xml version=”1.0” encoding=”UTF-8” ?>
<configuration>
<language>1</language>
<RC>
<inbelnr>09090199</inbelnr>
<login>Stijn</login>
<passw>1234</passw>
</RC>
<movieServer>
<ip>157.193.215.89</ip>
<port>3456</port>
</movieServer>
<userSugg>
<ip>192.168.30.183</ip>
<port>2468</port>
</userSugg>
<configServer>
<ip>192.168.30.183</ip>
A.3 Suggestiegegevens 101
<port>1234</port>
</configServer>
<seqTV>
<name nr=’1’>een</name>
<name nr=’2’>Canvas</name>
<name nr=’3’>VTM</name>
<name nr=’4’>KANAALTWEE</name>
<name nr=’5’>VT4</name>
<name nr=’6’>VijfTV</name>
<name nr=’7’>TMF</name>
</seqTV>
<seqRadio>
<name nr=’1’>Radio 1</name>
<name nr=’2’>Radio 2</name>
<name nr=’3’>Klara</name>
<name nr=’4’>Klara Continuo</name>
<name nr=’5’>Donna</name>
<name nr=’6’>Donna Hitbits</name>
</seqRadio>
</configuration>
A.3 Suggestiegegevens
A.3.1 Registreren gebruikersactie
<?xml version=”1.0” encoding=”UTF-8”?>
<usersuggestion>
<program>
<name>Parelvissers</name>
<channel>een</channel>
<type>1</type>
<subtype>
<nr>0</nr>
A.3 Suggestiegegevens 102
</subtype>
</program>
<lengthwatched>0.85</lengthwatched>
<date>
<day>1</day>
<date>02/04/2006</date>
</date>
<how>2</how>
<likeliness>0</likeliness>
</usersuggestion>
A.3.2 Registreren suggestievoorkeuren
<?xml version=”1.0” encoding=”UTF-8”?>
<usersuggestion>
<day nr=’0’>
<tod nr =’0’>1</tod>
<tod nr =’1’>2</tod>
<tod nr =’2’>5</tod>
<tod nr =’3’>3</tod>
<tod nr =’4’>5</tod>
<tod nr =’5’>4</tod>
<tod nr =’6’>3</tod>
<tod nr =’7’>5</tod>
<tod nr =’8’>4</tod>
<tod nr =’9’>1</tod>
</day>
<day nr=’1’>
<tod nr =’0’>1</tod>
<tod nr =’1’>2</tod>
<tod nr =’2’>5</tod>
<tod nr =’3’>3</tod>
A.3 Suggestiegegevens 103
<tod nr =’4’>5</tod>
<tod nr =’5’>4</tod>
<tod nr =’6’>3</tod>
<tod nr =’7’>5</tod>
<tod nr =’8’>4</tod>
<tod nr =’9’>1</tod>
</day>
<type nr=’1’>
<subtype nr=’0’>4</subtype>
<subtype nr=’1’>2</subtype>
<subtype nr=’2’>4</subtype>
<subtype nr=’3’>3</subtype>
<subtype nr=’4’>1</subtype>
<subtype nr=’5’>2</subtype>
<subtype nr=’6’>3</subtype>
<subtype nr=’7’>5</subtype>
<subtype nr=’8’>4</subtype>
</type>
<type nr=’2’>
<subtype nr=’0’>1</subtype>
<subtype nr=’1’>2</subtype>
<subtype nr=’2’>3</subtype>
<subtype nr=’3’>1</subtype>
<subtype nr=’4’>2</subtype>
</type>
. . .
</usersuggestion>
A.3 Suggestiegegevens 104
A.3.3 Specifieke aanvraag suggestiegegevens
<?xml version=”1.0” encoding=”UTF-8”?>
<usersuggestion>
<global>
<day>
<all>yes</all>
<nr>0</nr>
<nr>1</nr>
</day>
<tod>
<all>no</all>
<nr>4</nr>
<nr>5</nr>
<nr>6</nr>
</tod>
<type>
<all>no</all>
<nr>3</nr>
<nr>5</nr>
</type>
<subtype type=12>
<all>no</all>
<nr>0</nr>
<nr>1</nr>
<nr>2</nr>
</subtype>
<subtype type=1>
<all>yes</all>
</subtype>
<channel>
<all>no</all>
<name>een</name>
A.3 Suggestiegegevens 105
<name>VTM</name>
<name>VT4</name>
</channel>
<cast>
<all>no</all>
<name>Julia Roberts</name>
<name>Tara Reid</name>
</cast>
<director>
<all>no</all>
<name>Steven Spielberg</name>
</director>
</global>
<last7days>
</last7days>
</usersuggestion>
A.3.4 Suggestiegegevens
<?xlm version=”1.0” encoding=”UTF-8”?>
<usersuggestion>
<programType nr=1>
<total>
<day nr=0>
<ToD nr=0>23</ToD>
<ToD nr=1>33</ToD>
<ToD nr=2>44</ToD>
<ToD nr=3>63</ToD>
<ToD nr=4>83</ToD>
<ToD nr=5>78</ToD>
<ToD nr=6>12</ToD>
<ToD nr=7>45</ToD>
A.3 Suggestiegegevens 106
<ToD nr=8>65</ToD>
<ToD nr=9>43</ToD>
</day>
<day nr=1>
<ToD nr=0>23</ToD>
<ToD nr=1>33</ToD>
<ToD nr=2>44</ToD>
<ToD nr=3>63</ToD>
<ToD nr=4>83</ToD>
<ToD nr=5>78</ToD>
<ToD nr=6>12</ToD>
<ToD nr=7>45</ToD>
<ToD nr=8>65</ToD>
<ToD nr=9>43</ToD>
</day>
</total>
<subtype nr=0>
<day nr=0>
<ToD nr=0>23</ToD>
<ToD nr=1>33</ToD>
<ToD nr=2>44</ToD>
<ToD nr=3>63</ToD>
<ToD nr=4>83</ToD>
<ToD nr=5>78</ToD>
<ToD nr=6>12</ToD>
<ToD nr=7>45</ToD>
<ToD nr=8>65</ToD>
<ToD nr=9>43</ToD>
</day>
<day nr=1>
<ToD nr=0>23</ToD>
<ToD nr=1>33</ToD>
A.3 Suggestiegegevens 107
<ToD nr=2>44</ToD>
<ToD nr=3>63</ToD>
<ToD nr=4>83</ToD>
<ToD nr=5>78</ToD>
<ToD nr=6>12</ToD>
<ToD nr=7>45</ToD>
<ToD nr=8>65</ToD>
<ToD nr=9>43</ToD>
</day>
</subtype>
<subtype nr=1>
<day nr=0>
<ToD nr=0>23</ToD>
<ToD nr=1>33</ToD>
<ToD nr=2>44</ToD>
<ToD nr=3>63</ToD>
<ToD nr=4>83</ToD>
<ToD nr=5>78</ToD>
<ToD nr=6>12</ToD>
<ToD nr=7>45</ToD>
<ToD nr=8>65</ToD>
<ToD nr=9>43</ToD>
</day>
<day nr=1>
<ToD nr=0>23</ToD>
<ToD nr=1>33</ToD>
<ToD nr=2>44</ToD>
<ToD nr=3>63</ToD>
<ToD nr=4>83</ToD>
<ToD nr=5>78</ToD>
<ToD nr=6>12</ToD>
<ToD nr=7>45</ToD>
A.3 Suggestiegegevens 108
<ToD nr=8>65</ToD>
<ToD nr=9>43</ToD>
</day>
</subtype>
. . .
</programType>
<programType nr=2>
<total>
<day nr=0>
<ToD nr=0>23</ToD>
<ToD nr=1>33</ToD>
<ToD nr=2>44</ToD>
<ToD nr=3>63</ToD>
<ToD nr=4>83</ToD>
<ToD nr=5>78</ToD>
<ToD nr=6>12</ToD>
<ToD nr=7>45</ToD>
<ToD nr=8>65</ToD>
<ToD nr=9>43</ToD>
</day>
<day nr=1>
<ToD nr=0>23</ToD>
<ToD nr=1>33</ToD>
<ToD nr=2>44</ToD>
<ToD nr=3>63</ToD>
<ToD nr=4>83</ToD>
<ToD nr=5>78</ToD>
<ToD nr=6>12</ToD>
<ToD nr=7>45</ToD>
<ToD nr=8>65</ToD>
A.3 Suggestiegegevens 109
<ToD nr=9>43</ToD>
</day>
</total>
<subtype nr=0>
<day nr=0>
<ToD nr=0>23</ToD>
<ToD nr=1>33</ToD>
<ToD nr=2>44</ToD>
<ToD nr=3>63</ToD>
<ToD nr=4>83</ToD>
<ToD nr=5>78</ToD>
<ToD nr=6>12</ToD>
<ToD nr=7>45</ToD>
<ToD nr=8>65</ToD>
<ToD nr=9>43</ToD>
</day>
<day nr=1>
<ToD nr=0>23</ToD>
<ToD nr=1>33</ToD>
<ToD nr=2>44</ToD>
<ToD nr=3>63</ToD>
<ToD nr=4>83</ToD>
<ToD nr=5>78</ToD>
<ToD nr=6>12</ToD>
<ToD nr=7>45</ToD>
<ToD nr=8>65</ToD>
<ToD nr=9>43</ToD>
</day>
</subtype>
. . .
A.3 Suggestiegegevens 110
</programType>
. . .
<channel name=”een”>
<day nr=0>
<ToD nr=0>23</ToD>
<ToD nr=1>33</ToD>
<ToD nr=2>44</ToD>
<ToD nr=3>63</ToD>
<ToD nr=4>83</ToD>
<ToD nr=5>78</ToD>
<ToD nr=6>12</ToD>
<ToD nr=7>45</ToD>
<ToD nr=8>65</ToD>
<ToD nr=9>43</ToD>
</day>
<day nr=1>
<ToD nr=0>23</ToD>
<ToD nr=1>33</ToD>
<ToD nr=2>44</ToD>
<ToD nr=3>63</ToD>
<ToD nr=4>83</ToD>
<ToD nr=5>78</ToD>
<ToD nr=6>12</ToD>
<ToD nr=7>45</ToD>
<ToD nr=8>65</ToD>
<ToD nr=9>43</ToD>
</day>
</channel>
<channel name=”vtm”>
<day nr=0>
A.3 Suggestiegegevens 111
<ToD nr=0>23</ToD>
<ToD nr=1>33</ToD>
<ToD nr=2>44</ToD>
<ToD nr=3>63</ToD>
<ToD nr=4>83</ToD>
<ToD nr=5>78</ToD>
<ToD nr=6>12</ToD>
<ToD nr=7>45</ToD>
<ToD nr=8>65</ToD>
<ToD nr=9>43</ToD>
</day>
<day nr=1>
<ToD nr=0>23</ToD>
<ToD nr=1>33</ToD>
<ToD nr=2>44</ToD>
<ToD nr=3>63</ToD>
<ToD nr=4>83</ToD>
<ToD nr=5>78</ToD>
<ToD nr=6>12</ToD>
<ToD nr=7>45</ToD>
<ToD nr=8>65</ToD>
<ToD nr=9>43</ToD>
</day>
</channel>
. . .
<cast name=”Tara Reid”>23</cast>
<cast name=”Sean William Scott”>20</cast>
<cast name=”Leonardo Di Caprio”>4</cast>
. . .
A.4 VoD server 112
<director name=”Steven Spielberg”>22</director>
<director name=”Jeff Schaffer”>46</director>
<director name=”David Lynch”>2</director>
. . .
</usersuggestion>
A.4 VoD server
A.4.1 Initialisatie
<?xml version=”1.0” encoding=”utf-8”?>
<rss xmlns:wica=”http://www.wica.intec.ugent.be/LiveEventBroadcastURI”
wica:schemaLocation=”http://www.wica.intec.ugent.be/LiveEventBroadcastURI leb.xsd”>
<channel id=”784”>
<title>VOD channel</title>
<author>Stijn Hennebel</author>
<link></link>
<description>Video on Demand</description>
<subtitle></subtitle>
<summary></summary>
<language>DUTCH</language>
<copyright>(c) 2006 Stijn Hennebel</copyright>
<owner>Stijn Hennebel</owner>
<email>Stijn.Hennebel@Ugent.be</email>
<category>Movies</category>
<subcategory>Komedies</subcategory>
<item id=”0”>
<title>Eurotrip (2004)</title>
<author></author>
<description>
A.4 VoD server 113
Jongeren reizen doorheen Europa op zoek naar Mieke
en beleven hilarische momenten...
</description>
<imageUrl>eurotrip.PNG</imageUrl>
<subtitle></subtitle>
<summary></summary>
<start></start>
<stop></stop>
<price>3.0</price>
<keywords>4,1</keywords>
<authentication required=”false”>
<username></username>
<password></password>
</authentication>
<enclosure id=”0” url=”rmi://192.168.30.2:1099/Streamer” exclusive=”true”>
<name>Eurotrip</name>
<file>D:/users/Stijn/vod/eurotrip.wmv</file>
</enclosure>
</item>
<item id=”1”>
<title>American Pie (1999)</title>
<author></author>
<description>
4 Tienerjongens sluiten een pact om hun maagdelijkheid te verliezen
vooraleer het afstudeerbal...
</description>
<imageUrl>ampie.PNG</imageUrl>
<subtitle></subtitle>
<summary></summary>
<start></start>
<stop></stop>
<price>3.0</price>
A.4 VoD server 114
<keywords>4</keywords>
<authentication required=”false”>
<username></username>
<password></password>
</authentication>
<enclosure id=”0” url=”rmi://192.168.30.2:1099/Streamer” exclusive=”true”>
<name>American Pie</name>
<file>D:/users/Stijn/vod/ampie.wmv</file>
</enclosure>
</item>
</channel>
</rss>
A.4.2 VoD- & LE-informatie
VoD
<?xml version=”1.0” encoding=”UTF-8”?>
<vod>
<item>
<id>0</id>
<title>Eurotrip (2004)</title>
<description>Een groepje jongeren trekt doorheen Europa en beleeft hilarische
momenten. . .</description>
<imageUrl>eurotrip.png</imageUrl>
<keywords>4,1</keywords>
<price>2.99</price>
<locator></locator>
</item>
<item>
<id>1</id>
<title>Dot the I (2003)</title>
<description>Young lovers in London are wrapped up in a love triangle that may
A.4 VoD server 115
not be exactly what it seems</description>
<imageUrl>dotthei.png</imageUrl>
<keywords>7,19</keywords>
<price>2.99</price>
<locator></locator>
</item>
. . .
</vod>
LE
<?xml version=”1.0” encoding=”UTF-8”?>
<le>
<item>
<id>0</id>
<title>Rock Werchter (2006)</title>
<description>Rock festival</description>
<imageUrl>werchter.png</imageUrl>
<keywords>14</keywords>
<price>3.99</price>
<locator></locator>
</item>
. . .
</le>
DATABANKTABELLEN 116
Bijlage B
Databanktabellen
Hier bevinden zich de verschillende tabellen die de databank bevat. Ze zijn telkens wat
opgevuld met testgegevens.
B.1 Algemeen
B.1.1 USERIDTABLE
USERID IP
0 127.0.0.1
1 192.168.30.183
2 192.168.30.3
B.2 Configuratiegedeelte
B.2.1 LANGUAGETABLE
USERID LANGUAGE
0 1
1 0
2 1
B.2 Configuratiegedeelte 117
B.2.2 RCTABLE
USERID LOGIN PASSWORD
0 fa456723 deolp?32
1 NULL NULL
2 NULL NULL
B.2.3 SERVERIDTABLE
SERVERID SERVERNAME
1 MOVIESERVER
2 USERSUGGSERVER
3 CONFIGSERVER
4 LIVEEVENTSSERVER
5 VODSERVER
B.2.4 SERVERSTABLE
SERVERID IP PORT
1 157.193.215.89 3456
2 192.168.30.183 2468
3 192.168.30.183 2468
4 192.168.30.183 3555
5 192.168.30.183 3556
B.2 Configuratiegedeelte 118
B.2.5 CHANNELTABLE
CHANNELID CHANNELNAME
0 een
1 ketnet/canvas
2 VTM
3 KANAALTWEE
4 VT4
5 VijfTV
6 Radio 1
7 Radio 2
8 Klara
9 Donna
10 Q-music
B.2.6 TVSEQTABLE
TVCHANNELNR CHANNELID
0 0
1 2
2 1
3 3
4 4
5 5
B.2.7 RADIOSEQTABLE
RADIOCHANNELNR CHANNELID
0 8
1 10
2 9
3 6
4 7
B.3 Suggestiegedeelte 119
B.3 Suggestiegedeelte
Deze tabellen bevatten enorm veel rijen. Slechts de eerste tien rijen zijn telkens opgenomen.
B.3.1 PROGRAMTYPEGLOBALTABLE
USERID DAY TOD PROGRAMTYPE COUNTER
0 0 0 0 0
0 0 0 1 4
0 0 0 2 0
0 0 0 3 1
0 0 0 4 0
0 0 0 5 6
0 0 0 6 0
0 0 0 7 0
0 0 0 8 8
0 0 0 9 0
B.3.2 PROGRAMSUBTYPEGLOBALTABLE
USERID DAY TOD PROGRAMTYPE PROGRAMSUBTYPE COUNTER
0 0 0 3 0 -6
0 0 0 3 1 -6
0 0 0 3 2 -6
0 0 0 3 3 -5
0 0 0 4 0 12
0 0 0 4 1 12
0 0 0 4 2 8
0 0 0 4 3 19
0 0 0 4 4 -6
0 0 0 4 5 1
B.3 Suggestiegedeelte 120
B.3.3 CHANNELGLOBALTABLE
USERID DAY TOD CHANNEL COUNTER
0 0 0 een 2
0 1 0 een 9
0 1 1 VTM 3
0 0 5 VT4 7
B.3.4 CASTTABLE
USERID CAST COUNTER
0 Sean William Scott 34
0 Tara Reid 18
B.3.5 DIRECTORTABLE
USERID DIRECTOR COUNTER
0 David Lynch -24
0 Steven Spielberg 13
SCHERMAFBEELDINGEN 121
Bijlage C
Schermafbeeldingen
Deze bijlage biedt een aantal schermafbeeldingen gemaakt via de emulator xletviewer.
Aangezien deze niet op een echte broadcast stroom aagesloten is, wordt de EPG van
testgegevens voorzien.
C.1 Hoofdscherm
Figuur C.1: Hoofdmenu met het draaiend menu
C.2 Informatieverkenner 122
C.2 Informatieverkenner
Figuur C.2: De informatieverkenner waarbij het menuutje met de opties opgelicht is.
C.3 Programma’s op dit momemt
Figuur C.3: Een overzicht met de programma’s die zich dit moment afspelen. Hier in dit
voorbeeld is er extra filminformatie opgevraagd.
C.4 Volledig TV overzicht 123
C.4 Volledig TV overzicht
Figuur C.4: Het volledig TV overzicht.
C.5 Herinneringenoverzicht
Figuur C.5: Overzicht van de ingestelde herinneringen.
C.6 Virtuele videotheek 124
C.6 Virtuele videotheek
Figuur C.6: De virtuele videotheek die momenteel de beschikbare films weergeeft.
Figuur C.7: De informatie geleverd door de movie information server.
C.7 Categorieoverzicht 125
C.7 Categorieoverzicht
Figuur C.8: Het menu om een gewenst genre op te zoeken. Ditzelfde menu wordt ook gebruikt
als input in het zoekscherm.
Figuur C.9: De resultaten
C.8 Suggesties 126
C.8 Suggesties
Figuur C.10: Ingeven van de suggestievoorkeuren
C.9 Zoeken naar programma’s
Figuur C.11: De zoekresultaten.
C.10 Instellingen 127
C.10 Instellingen
Figuur C.12: Instellingenmenu - optie : het instellen van het uitzicht van de EPG
C.11 Extraatje : Snake
Figuur C.13: De EPG bevat een verborgen extraatje. Wanneer men op de gele toets duwt in
het hoofdmenu, start het populaire spelletje Snake.
UML-SCHEMA’S 128
Bijlage D
UML-schema’s
D.1 Main module
Figuur D.1: Het overzicht van de main module. Elke controller beschikt over een referentie
naar de MainControllerInterface. Om de figuur niet te overladen, is deze echter enkel bij de
UserSuggestionController weergegeven.
D.2 Client connection module 129
Figuur D.2: De planner package.
D.2 Client connection module
Figuur D.3: Het volledige client connection systeem.
D.3 Import module 130
D.3 Import module
Figuur D.4: Het UML-schema van de importeermodule. Elke plug-in heeft een referentie naar de
ImportControllerInterface. Opnieuw zijn deze niet allen weergegeven om de figuur niet onnodig
te overladen. De plug-ins zijn er niet verder uitgewerkt.
Figuur D.5: De plug-in die het importeren van de SI verzorgt.
D.4 EPG data module 131
Figuur D.6: De plug-in die het opvragen van de VoD-elementen behandelt.
D.4 EPG data module
Figuur D.7: De EPGdata module.
D.5 User suggestion module 132
D.5 User suggestion module
Figuur D.8: De volledige user suggestion module.
Figuur D.9: Een schematisch overzicht van de user suggestion module.
D.6 Graphical module 133
D.6 Graphical module
Figuur D.10: De grafische module, elke schermklasse bevat een referentie naar de Graphical-
Controller. Deze is in de meeste gevallen weggelaten uit de figuur. Enkel de NavigatorScreen
klasse is verder uitgewerkt als illustratie.
D.7 Resource module 134
Figuur D.11: Ter illustratie bevindt zich hier een overzicht van een volledig scherm.
D.7 Resource module
Figuur D.12: De resource module.
BIBLIOGRAFIE 135
Bibliografie
[1] ARDISSONO, L., PORTIS, F. & TORASSO, P. (2001). Architecture of a system
for the generation of personalized Electronic Program Guides. Italy, Dipartimento di
Informatica, Universita di Torino.
[2] BLANCO-FERNANDEZ, Y., PAZOS-ARIAS, J.J., GIL-SOLLA, A. et al.
(2004).AVATAR: An Advanced Multi-Agent Recommender System of Personalized
TV Contents by Semantic Reasoning. Spain, Department of Telematic Engineering,
University of Vigo.
[3] BONNICI, S. (2003). Which Channel Is That On? A Design Model for Electronic
Programme Guides. Republic of Ireland, Neworld Group.
[4] BUCZAK, A.L, ZIMMERMAN, J. & KURAPATI,K. (2002). “Personalization: Im-
proving Ease-of-Use, Trust and Accuracy of a TV Show Recommender”. USA, Philips
Research USA.
[5] DIFINO, A., NEGRO, B. & CHIAROTTO, A. (2003). A Multi-Agent System for a
Personalized Electronic Program Guide. Italy, Telecom Italia Lab.
[6] DVB PROJECT (2005). Digital Recording Extension to Globally Executable MHP
(GEM), DVB Document A088 Rev.1
[7] DVB PROJECT (2005). PVR/PDR Extension to the Multimedia Home Platform,
DVB Document A087.
[8] EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE (ETSI)
(2000). Digital Video Broadcasting (DVB) - Implementation guidelines for the use
of Video and Audio Coding in Broadcasting Applications based on the MPEG-2
Transport Stream; MPEG-2 Implementation guidelines, Doc.nr.: ETSI TR 101 154
V1.4.1
BIBLIOGRAFIE 136
[9] EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE (ETSI)
(2002). Digital Video Broadcasting (DVB) - Multimedia Home Platform (MHP) Spec-
ification 1.0.2, Doc.nr.: TS 101 812 v1.2.1.
[10] EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE (ETSI)
(2004). Digital Video Broadcasting (DVB) - Guidelines on implementation and usage
of Service Information (SI), Doc.nr.: ETSI TR 101 211 V1.6.1
[11] EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE (ETSI)
(2004). Digital Video Broadcasting (DVB) - Specification for Service Information
(SI) in DVB systems, Doc.nr.: EN 300468 v1.6.1
[12] EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE (ETSI)
(2005). Digital Video Broadcasting (DVB) - Multimedia Home Platform (MHP) Spec-
ification 1.1.1, Doc.nr.: TS 102 812 V1.2.1
[13] FOTSCHL, H-P. & PLOSCH, R. Interactive Applications for the Multimedia Home
Platform. Austria, Sony NetServices GmbH
[14] GOREN-BAR, D. & GLINANSKY, O. (2002). Family Stereotyping - A Model to
Filter TV Programs for Multiple Viewers, Israel, Department of Information Systems
Engineering, Ben-Gurion University of the Negev.
[15] IMDb, The Internet Movie Database (IMDb), http://www.imdb.com
[16] IRT (2005). MHP knowledge database. http://www.mhp-knowledgebase.org
[17] JAVA (1998). JMF specification v1.0, http://java.sun.com/products/
java-media/jmf/1.0/index.html, Sun Microsystems Inc
[18] JAVA (2002). Java Technology in Digital TV, http://java.sun.com/products/
javatv/index.html, Sun Microsystems Inc
[19] KURAPATI, K. & GUTTA, S. (2002). TV Personalization through Stereotypes. USA,
Philips Research USA.
[20] MHP (2003). Digital Video Broadcasting Multimedia Home Platform. http://www.
mhp.org/mhp technology/mhp profiles/
[21] MORRIS, S. (2004). Interactive TV WEB, Your choice of MHP, OCAP and JavaTV
Information. http://www.interactivetvweb.org
[22] MORRIS, S. & SMITH-CHAIGNEAU, A. (2005). Interactive TV Standards: A guide
to MHP, OCAP and JavaTV. Burlington, MA: Focal Press, 585p.
BIBLIOGRAFIE 137
[23] PAWLAN, M. (2005). Introduction to Digital TV Applications Program-
ming. http://java.sun.com/developer/technicalArticles/javatv/apiintro/,
Sun Microsystems Inc.
[24] SCHWALB, E.M. (2003). iTV Handbook: Technologies and Standards. New Jer-
sey(USA), Prentice Hall PTR, 752p.
[25] UCHYIGIT, G. & CLARK, K. (2002). An Agent based Electronic Program Guide,
Londen, Department of Computing, Imperial College of Science, Technology and
Medicine.
[26] VAN SETTEN, M., VEENSTRA, M. & NIJHOLTPREDICTION, A. (2002). Strate-
gies: Combining Prediction Techniques to Optimize Personalization. The Netherlands,
Telematica Instituut & University of Twente.
[27] ZIMMERMAN, J., PARAMESWARAN, L. & AND KURAPATI, K. (2002). Celebrity
Recommender, USA, Philips Research and Philips Design.