Het ontwerp van een intelligente EPG voor het...

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 starten 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.

2.4 Scenario’s 14

Figuur 2.3: Scenario 3: zoekscherm

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-,

zoeken 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/

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


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


∗ 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


– 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);


• 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.


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.


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


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


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


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

starten 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, . . .


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


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


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


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


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


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 -


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


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. 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


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.


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

• starten eindtijd

• de duur in seconden

• programmatype en -subtype

• korte beschrijving

4.4.2 Zoekfuncties

De EPGdataInterface biedt een heleboel zoeken 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.


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 :


• 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.


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


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.



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;


• 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


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”} };


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.


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


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 starten 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


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.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


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


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.


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.


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


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


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.


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 rijen 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


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.


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


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


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


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.


[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


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


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


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.


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


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


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


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

http://www.imdb.com/database_statistics


• 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

http://www.jmdb.de/index.html


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


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.


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


<usersuggestion>

<program>

<name>Parelvissers</name>

<channel>een</channel>

<type>1</type>

<subtype>

<nr>0</nr>


</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


<usersuggestion>

<day nr=’0’>

<tod nr =’0’>1</tod>










</day>

<day nr=’1’>












</day>

<type nr=’1’>

<subtype nr=’0’>4</subtype>









</type>

<type nr=’2’>






</type>

. . .

</usersuggestion>


A.3.3 Specifieke aanvraag suggestiegegevens


<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>


<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>


<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>

. . .


</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>


<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>[email protected]</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>


<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>


<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


<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>


<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>


<price>2.99</price>

<locator></locator>

</item>

. . .

</vod>

LE


<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


(2002). Digital Video Broadcasting (DVB) - Multimedia Home Platform (MHP) Spec-

ification 1.0.2, Doc.nr.: TS 101 812 v1.2.1.


(2004). Digital Video Broadcasting (DVB) - Guidelines on implementation and usage

of Service Information (SI), Doc.nr.: ETSI TR 101 211 V1.6.1


(2004). Digital Video Broadcasting (DVB) - Specification for Service Information

(SI) in DVB systems, Doc.nr.: EN 300468 v1.6.1


(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.

http://www.imdb.com

http://www.mhp-knowledgebase.org

http://java.sun.com/products/java-media/jmf/1.0/index.html

http://java.sun.com/products/java-media/jmf/1.0/index.html

http://java.sun.com/products/javatv/index.html

http://java.sun.com/products/javatv/index.html

http://www.mhp.org/mhp_technology/mhp_profiles/

http://www.mhp.org/mhp_technology/mhp_profiles/

http://www.interactivetvweb.org

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.

http://java.sun.com/developer/technicalArticles/javatv/apiintro/

Het ontwerp van een intelligente EPG voor het...

Documents

Transcript of Het ontwerp van een intelligente EPG voor het...