Faculteit Ingenieurswetenschappen Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. Lagasse Onderzoeksgroep Wireless & Cable Directeur: prof. dr. ir. L. Martens
Ontwerp van een intelligente EPG voor 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 Universiteit 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 meegewerkt 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 verbeteren 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 kopi¨eren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking 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-platform door Stijn Hennebel Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen Academiejaar 2005–2006 Promotor: Prof. Dr. Ir. L. Martens Scriptiebegeleiders: Ir. T. Deryckere, Lic. M. Ide Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. Lagasse Onderzoeksgroep Wireless & Cable Directeur: prof. dr. ir. L. Martens
Samenvatting De ontwikkeling van een geavanceerde en intelligente EPG bovenop een eenvoudig uitbreidbare architectuur is het resultaat van deze thesis. Naar de gebruikers toe levert de gebruiksvriendelijke applicatie een waaier aan mogelijkheden. Dankzij de informatieverkenner kunnen ze alle mogelijke zenders overlopen, herinneringen en opnames instellen zonder ook maar een seconde van hun programma te missen. Het overzicht van de programma’s wordt op verschillende manieren aangeboden, gesorteerd volgens zender, tijdstip of genre. Dankzij de movie information server verwent de EPG de gebruikers met extra filminformatie. Een VoD-server (video on demand) biedt de abonnees de mogelijkheid om vanuit hun luie zetel films of live events te bestellen en te bekijken. Als kers op de taart is het systeem zelflerend waardoor de EPG zelf actief op zoek gaat naar je favoriete programma’s. Hoewel het visuele aspect op onderzoeksniveau van minder belang is, is er toch heel wat aandacht aan besteed. Het heeft namelijk een grote impact op de indruk die de applicatie nalaat. De architectuur zorgt voor eenvoudige uitbreidbaarheid. Het toevoegen of vervangen van importeermogelijkheden, grafische interfaces, suggestiealgoritmes, . . . is heel eenvoudig. Dit maakt deze applicatie een goede basis om ze verder uit te bouwen tot een allesbevattende EPG.
Design of an intelligent EPG for the MHP environment. 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 and give an overview of the functions a modern EPG should incorporate. We will show the architecture of a modular EPG system. This system enables the user to organize services according to his preferred view and record applications using a PVR. Further the EPG will allow the addition of different user personalisation modules. Keywords— Digital Interactive Television, Electronic Program Guide, Multimedia Home Platform, Personalization
I. I NTRODUCTION
W
ITH the advent of digital television, users are offered hundreds of channels and even more programs. To help them choose the programs of their interest, an EPG (electronic program guide) is needed. Simple EPGs show a list of programs that are and will be broadcasted. Such an EPG provides only a view per service provider and results in long search and scroll times to find the appropriate program. An EPG that can organize the programs more thematically (genre, age, language, . . . ) and that tells the user where he can find what he wants will augment the usability of the application and improve the experience of iDTV. The application is developed on top of the Multimedia Home Platform (MHP) standard. MHP allows the development of interactive applications in a hardware platform independent way because it offers a common application programming interface (API), the DVB-J API. This standard is comprised of a number of software packages that provide generic APIs to a wide range of features of the platform. The EPG is based on the MHP specification 1.0.2[3], because this is currently mostly available on the set-top boxes. Metadata is inserted in the broadcast stream to demultiplex the different transport streams and to offer information about the events. Retrieving this program specific information/service information (PSI/SI) is one of the most important tasks of the EPG.
movie, it connects to a movie database to collect specific information, including director, actors, rating and even a trailer, if the content provider is willing to put these trailers into a transport stream. Video on demand (VoD) is also one of the possibilities the EPG offers. The dedicated VoD server delivers movies and live 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 supports this. The user can easily record a program by selecting it, so he doesn’t have to worry about the start and end time. Users can plan their TV happening. They can easily select and add programs to their planner. The EPG can give the user a reminder or automatically switch to the pre-planned programs. The application itself can be personalized. It supports multiple languages and it’s even possible to change the skin to a predefined or a self made one. And last but not least, the EPG is self-learning. It has a built-in recommender function. Based on the user actions in the past, the user preferences and the programs currently possible to choose, it can give some suggestions. The recommender function will not be limited to one recommender algorithm. Pluggability for other algorithms is built-in. III. A RCHITECTURE The architecture is split up in different modules according to their functionality. They each have their own responsibility. The interaction between the modules must be kept as low as possible. A. Main module The main is the controlling center of the application. It arranges the start-up of the application and the initialisation of all the other modules. Also the configuration management and the planner functionality resides here.
II. R EQUIREMENTS The EPG should help the users to find, select and acquire programs of their interest. This will be implemented by providing different views that sort the programs in different ways. Each view will have his own purpose. There are some views where the user can browse by channel, by category, by genre, . . . Besides this functionality, there’s also a visible controller that allows the user to browse, search and schedule the recordings of another program, while continuing to watch. The EPG has to deliver as much information as possible. It can connect to different dedicated servers who deliver specific information about programs or it can use for example PSI/SI information available in a DVB transport stream. E.g. in case of a
B. Import module The import module delivers the metadata that describes the different programmes to the EPG. It controls a number of importing plug-ins. These plug-ins have to implement an ImportPlugIn interface which forces the plug-ins to deliver service discovery to the controller. This makes this system easily extendable. Each plug-in takes care of a specific task such as importing service information (SI) from the stream, possible live events from a live event or video on demand (VoD) server. It can also fetch specific information such as movie information from a movie database.
The EPG can be seen as an information center about TV programs. It has to provide as much information as possible. This should go further than just some simple description. As seen from the architecture, the metadata can be retrieved from several technological places. SI can be extracted from the broadcast 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 or live events which can be ordered by the user. The movie information server delivers specific movie related information. It contains the data from IMDd (International Movie Database). Other dedicated servers who deliver specific information related to some programs such as e.g. Big Brother or extra 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 module. This module also provides specific data functions such as searching, sorting and so on . . . D. User Suggestion Module The recommender algorithms can be split into different categories ([2], [5]). • Implicit algorithms These algorithms work with data only obtained by the selflearning process. It suffers from the cold-start problem. • Explicit algorithms An explicit algorithm works with initial start-up information provided by the user. Therefor it immediately delivers accurate results. But the user must be willing to spend some effort. • Algorithms based on stereotypes People are classified into stereotypes or a combination of it. By interrogating the user according his age, sex, occupation, etc. the system defines the right stereotype and delivers recommendations conform his profile. The EPG handles a hybrid system containing different kind of algorithms ([6]). Those are combined in a slightly dynamic way. Each recommendation is delivered together with a confidence and likeliness value. The former describes how sure the algorithm is about his decision. The latter estimates the appreciation of the suggested program. Based on confidence, duplicate recommendations are eliminated and the most confident one remains. In most cases a TV is used by more than one user ([4]). So here arises a problem because those users (e.g. children and parents) can have a completely different TV behaviour. When users have to log in, they will see this too much as a burden. By incorporating the time of the day, a family profile can be built. E.g. in the late evening it will mostly be the parents who watch TV. The metadata is stored on a global and on a dynamic way. The dynamic table only incorporates the actions of the last seven days which makes it possible to always take into account the most recent evolutions. The internal system consists of three parts ([1]). The registration submodule records the viewing behaviour of the users and stores their choices in the user database. The data submodule keeps
track of all the data. It collects the data from the remote user database and gets the data from the data manager. The recommender submodule has several recommender algorithms. They all use the data as input, deliver suggestions and implement a specific interface, which makes the system easily upgradeable by simply inserting newer or more sophisticated algorithms. E. Graphical Module The graphical module contains everything with respect to the graphical user interface. There are different modes, each with their own purpose and their own screen. E.g. there’s a mode that shows an overview of all the current programs. The user can easily select what he wants to see at that moment. There are also modes to search programs on the basis of keywords, to set some configuration parameters and so on . . . It’s easy to extend the applicating by adding new screens. Implementing the right interface suffices. F. System Resources Module If an application wants to use the scarce resources, he has to reserve 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 to take care of playing the content. H. Client Connection Module Some modules, such as the import module and the user suggestion module, have to use the return channel to connect to remote servers. This module abstracts the details of a socket connection and the encapsulation of an object into a XML-file. It consists of an asynchronous system with a built-in priority scheduler. IV. C ONCLUSIONS In this paper, we have presented an open, modular and easily extendable architecture for an intelligent and advanced EPG. It is built as a framework around the requirements for a user friendly EPG and allows to use external modules that fulfil these requirements. So the different functionalities can easily be replaced by newer or more sophisticated ones. R EFERENCES [1] Blanco-Fernndez, 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. [2] Buczak, A.L, Zimmerman, J. & Kurapati,K. (2002). “Personalization: Improving Ease-of-Use, Trust and Accuracy of a TV Show Recommender”. USA, Philips Research USA. [3] European Telecommunications Standards Institute (ETSI) (2002). Digital Video Broadcasting (DVB) - Multimedia Home Platform (MHP) Specification 1.0.2, Doc.nr.: TS 101 812 v1.2.1. [4] 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. [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 Netherlands, Telematica Instituut & University of Twente.
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 ´e´en-richtings broadcastverkeer. De opkomst van interactieve digitale televisie (iDTV) opent heel wat perspectieven. Dankzij 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 effici¨entere bandbreedte benutting. Een transportstroom kan immers dankzij de MPEG-2-codering meerdere digitale kanalen bevatten waar voorheen slechts ´e´en 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 specificaties 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 bijvoorbeeld 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. Bovendien 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 specificatie. 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 systeembron 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 afstandsbediening, 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 systeempjes 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 toevoegen 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 Video Recorder [7] / Personal Digital Recorder [6]), waarbij de gebruiker eenvoudig een programma kan selecteren zonder zich zorgen te maken over de start- en eindtijden.
De informatieverkenner biedt de mogelijkheid om alle zenders te overlopen, herinneringen en opnames in te stellen zonder ook maar een seconde van je programma te missen. Op het onderste gedeelte na, blijft het volledige videobeeld immers zichtbaar.
Met de ingebouwde virtuele videotheek is het mogelijk om films of live events (LE) zoals concerten 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 eenvoudige manier de applicatie verder kunnen uitbouwen. Een goed gestructureerde modulaire architectuur zorgt ervoor dat men op een transparante wijze nieuwe importeereenheden, schermen, 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 initi¨ele 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 2.3.1
Kwaliteitsaspecten 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 mogelijkheden 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
2.4
12
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
2.4.2
13
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 tevoorschijn 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 GraphicalController 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 herinnering 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 uitgebreider 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 hi¨erarchische structuur. De hoofdmodule bevat de Xletklasse 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 terugkeerkanaal regelt. Elke module die een verbinding met een server wil opzetten, kan gebruik maken van deze module. • epgdatamodule Dit is de EPGdata module die als opslageenheid fungeert. Ze bevat alle relevante data voor de hele applicatie en levert elke module de nodige gegevens. Ze is voorzien van opslag-, zoek- en sorteerfuncties. • nanoxml Sommige modules moeten XML-bestanden parsen. Hiervoor maken ze gebruik van deze package, ontwikkeld door Marc De Scheemaecker. Het betreft de NanoXML 2 Lite versie1 . • playmodule Het overschakelen naar een zender en het afspelen van de inhoud ervan wordt hier in de afspeelmodule geregeld. • resourcemodule Het initialiseren en het reserveren van de verschillende systeembronnen gebeurt in de systeembronnenmodule. • usersuggestionmodule Deze module bevat het volledig zelflerend systeem. Ze verwerkt de geregistreerde gebruikersacties en verstuurt deze gegevens naar de server. Verder levert ze op basis van de opgedane kennis en de mogelijke programma’s een aantal aanbevelingen. 1
te downloaden op http://nanoxml.cyberelf.be/
3.2 Overzicht packages
17
– USalgorithms Deze subpackage bevat alle kiesalgoritmes. • planner Deze package, een onderdeel van de hoofdmodule, verzorgt het bijhouden van de herinneringen 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 categorie. – 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 weergegeven. – 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 programmaoverzicht 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 terugkeerkanaalparameters in te geven. – suggestionscreen Hier kan men enerzijds suggesties opvragen en anderzijds de initi¨ele voorkeuren doorgeven. – 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 opgenomen. 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 applicatie 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 technologie¨en, 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
Figuur 3.1: De modulaire architectuur van de EPG.
19
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 hoofdmodule de configuratiegegevens aan de configuratieserver opvragen. De client connection module 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 co¨ordinatie 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 gebracht 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 bekomen 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 programma’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 ´e´en 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 ingesteld. Op die manier kan ´e´en TVTimer -object alle herinneringen verwerken. De configuratie van de TVTimer gebeurt aan de hand van een TVTimerSpec-klasse. Deze klasse 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 gecre¨eerd dat de melding weergeeft. Het inladen van het geluid zorgt voor een kleine vertraging. Het geluidsfragment is een mp2-bestand. MHP ondersteunt namelijk slechts ´e´en formaat voor geluidsfragmenten: 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 gecre¨eerd. 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 hi¨erarchie. Het genereren van de HScene gebeurt aan de hand van een template. Eerst ontwikkelt 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 co¨ordineren. Wanneer bijvoorbeeld 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 suggestiemodule 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 ´e´en 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 co¨ordineren: 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, configuratiegegevens, . . . ). Bij de ene zal er een XML-bestand verstuurd worden, bij de ander volstaat
4.2 Client Connection Module
26
een eenvoudig commando. Daarnaast moet elke aanvraag over een id beschikken zodat intern in het systeem, deze eenvoudig kan bijhouden welke module welke aanvraag deed. Om dit alles soepel te laten verlopen, is het Return Channel Request Protocol (RCRP) ontwikkeld. Deze bevat 4 veldjes. • ID: 2 bytes. Per byte zijn er slechts 7 bits geldig (Java Byte system). Hierdoor zijn er maximaal 127 x 127 = 16255 mogelijke id’s. Dat zou ruimschoots moeten volstaan. • RequestType: 1 byte : dit is het type van aanvraag – movie information server – user suggestion server – configuration server – VoD-server – LE-server • RequestSubType: 1 byte : dit zorgt voor een opdeling binnenin het type – movie information server ∗ basisinformatie ∗ vorige + cast ∗ vorige + korte beschrijving ∗ vorige + foutjes in de film ∗ vorige + opmerkelijke uitspraken – user suggestion server ∗ registratie gebruikersactie ∗ registratie initi¨ele suggestievoorkeuren ∗ opvragen van alle verwerkte gegevens ∗ opvragen van specifieke verwerkte gegevens – configuration server ∗ alle configuratiegegevens opvragen ∗ taalvoorkeur ∗ terugkeerkanaalparameters
4.2 Client Connection Module
∗ 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
27
4.2 Client Connection Module
28
– S: SQL-statement • Payload zelf. Dit heeft natuurlijk een variabele lengte en bevat de eigenlijke gegevens die verstuurd worden.
iDTV-Applicaties kunnen dit protocol heel algemeen invullen en bijgevolg het gemakkelijk overnemen. De requesttypes en -subtypes kan men zelf naar eigen goeddunken invullen en ze zorgen ervoor dat de server onmiddellijk weet welke gegevens de client nodig heeft, indien hij ook dit protocol ondersteunt en dezelfde conventies qua types en subtypes hanteert. Het protocol heeft een header van slechts 5 bytes. De verschillende aanvragen kon men evengoed via een XML-bestand aan de server doorgeven, maar dan zou de overhead veel groter zijn. Omwille van performantieredenen werd dit hier zo kort en snel mogelijk gehouden.
4.2.2
Interne Architectuur
Het UML-schema van deze interne architectuur is afgebeeld in D.3. RequestCollector De hoofdklasse uit de client connection module is de RequestCollector -klasse. Deze implementeert 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 priority);
4.2 Client Connection Module
29
• public int getLEinformation(short moduleID, int LEid, byte reqSubType, short priority); • public void doVODaction(short moduleID, int VODid, byte reqSubType); • public void doLEaction(short moduleID, int VODid, byte reqSubType); • public int getDataWebServer(short moduleID, String IPwebServer, int portNr, short priority, 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 priority, byte reqType, byte reqSubType, String payload, char payloadType); De drie laatste functies laten toe om gegevens uit te wisselen met servers die RCRP niet ondersteunen. 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 RCCommonConfigurationklasse. In het ander geval worden deze meegeleverd als functieargument.
4.2 Client Connection Module
30
De klassen RCRequestType, RCRequestSubType, PayloadType en RequestPriority bevatten een tekstuele representatie van de verschillende bytewaarden aan de hand van static final variabelen. 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 grafische module. Indien dit nieuwe scherm immers externe informatie via het terugkeerkanaal wil opvragen, deponeert hij simpelweg deze bij de GraphicalController.
4.2 Client Connection Module
31
RequestProcessor Het belangrijkste onderdeel van de RequestCollector is de klasse RequestProcessor. Dit is een thread die op regelmatige tijdstippen de RequestItems ophaalt, verwerkt en terugstuurt naar de juiste module. De thread vraagt de RequestItem met de hoogste prioriteit op. Indien RCRP gebruikt wordt, dan gaat hij eerst de header ervan initialiseren. Daarna vult hij de payload op en verstuurt hij de aanvraag over het IP-netwerk. Het effectief versturen op socketniveau wordt verzorgd door de TcpSocketClient-klasse. Indien nodig, wacht hij op het antwoord van de server. Dit antwoord, vaak in XML-vorm, zal daarna in de meeste gevallen geconverteerd worden tot een klasseobject. Dit gebeurt door de klasse FormatConvertor. De RequestProcessor bevat een lijst met referenties naar de verschillende modules die de RCReceiveInterface implementeren. Het antwoord, al dan niet omgezet tot een klasseobject, wordt aan de hand van die referenties teruggestuurd naar de oorspronkelijke module. Wanneer er ergens een fout optreedt, wordt de desbetreffende foutcode doorgegeven aan de ontvangende module. Het grootste gedeelte van de tijd zal deze verwerkingsthread geen werk verrichten. Ze moet bijgevolg dan ook niet onnodig systeembronnen verspillen. Dit moet dus zo effici¨ent 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 IPadres 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 XMLformaat 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 gebeuren. 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 toekomstige 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 gebruiker de EPG tevoorschijn laten komen. Indien nog niet alle gegevens ge¨ımporteerd zijn, dan kan men bladeren tussen de verschillende programma’s die zich op dit ogenblik afspelen, terwijl
4.3 Import Module
33
de overige programma’s verder binnengehaald worden. Deze vertraging volledig wegwerken is momenteel technologisch gezien niet mogelijk. Het kan wel heel wat verbeterd worden door bijvoorbeeld het gebruik van interne cache in de set-top box. Meer uitleg hierover in 4.3.7.
4.3.2
Metadata
Een EPG heeft als belangrijkste functie informatie geven over tv-programma’s. Deze informatie moeten veel verder reiken dan enkel een klein tekstje met de korte inhoud ervan. Gegevens zoals bijvoorbeeld kijkcijfers kunnen een meerwaarde betekenen. De EPG zal de gebruiker ook extra programmaspecifieke gegevens leveren. Bijvoorbeeld bij programma’s zoals Big Brother is het mogelijk om allerlei weetjes, nominatiegegevens en dergelijke op te vragen. Bij films bijvoorbeeld kan men communiceren met een filmdatabank zoals IMDb om de regisseur, de acteurs en actrices, het waarderingscijfer, . . . op te vragen en kan zelfs eventueel ook een trailer aangeboden worden. Eerst wordt de service informatie (SI) gelezen uit de broadcast stroom. Daarna gaat het systeem na van welke programma’s men nog extra informatie kan opvragen. Het ophalen zelf echter gebeurt slechts wanneer een gebruiker dit daadwerkelijk aanvraagt. Zodoende wordt er geen extra informatie opgehaald die de gebruiker niet nodig heeft. We moeten immers rekening houden met een eindig intern geheugen. De verschillende taken worden zoveel mogelijk uitgevoerd 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 verschillende API’s, namelijk de DVB SI API en de JavaTV API. Het grote verschil tussen beide is dat DVB SI toegang verleent tot alle SI-tabellen. JavaTV daarentegen is veel algemener. Ze kan ook gebruikt worden in een OCAP-systeem. Ze werkt niet op niveau van SI-tabellen, maar werkt
4.3 Import Module
34
eerder met een taakgebaseerde aanpak. Je vraagt bijvoorbeeld de services op en ze worden je geleverd. Hoe dit in de tabellen opgeslagen is, hoef je niet te weten. JavaTV heeft als groot nadeel dat het geen toegang heeft tot op het descriptor-niveau. En dit is onontbeerlijk wanneer men bijvoorbeeld het genre van een programma wil opvragen. DVB SI API De DVB SI API verleent je toegang tot alle SI-tabellen die deel uitmaken van de standaard DVB SI-specificatie([10], [11]). We vertrekken van een databank die alle SI-tabellen bevat: de SIDatabase. Deze bevat in feite niet alle SI-gegevens, maar heeft de mogelijkheid om deze op te vragen. Door het oproepen van de statische functie getSIDatabase() op de singleton-klasse SIDatabase bekomt men dit object. Nu kunnen we alle mogelijke tabellen opvragen, alsook het toevoegen van verschillende soorten listeners, maar later hierover meer. De kabel bestaat uit een aantal transportstromen. Deze bevatten elk op zich een aantal services, 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 hi¨erarchisch. Eerst worden de services opgevraagd en daarna, de events van de verkregen services. Via de functie retrieveSIServices(short retrieveMode, Object appData, SIRetrievalListener listener, 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 SIRetrievalListener. Verder kan er bij die aanvraag ook een zelf te defini¨eren object AppData meegegeven worden om de programmeur de mogelijkheid te bieden de SIRetrievalListener extra informatie te verschaffen opdat die zo de ontvangen gegevens zou kunnen verwerken. De SIDatabase kan deze gegevens op verschillende manieren ophalen. De retrieveMode-parameter
4.3 Import Module
35
uit de aanvraag bepaalt deze. Er zijn drie mogelijkheden: • gegevens enkel uit de cache halen • de gegevens enkel uit de stroom halen • eerst in de cache kijken, zit het niet in de cache, dan pas uit de stroom halen Indien men de gegevens uit de cache haalt, dan worden deze logischerwijze veel sneller bekomen dan wanneer men ze uit de stroom haalt. Het nadeel is natuurlijk dat ze mogelijks verlopen kunnen zijn. Wanneer men een SIService-object bekomt, is het mogelijk via dit object de SIEvents ervan op te vragen. Dit gebeurt in drie stappen (voor de duidelijkheid zijn de functieargumenten weggelaten) • het huidig programma: retrievePresentSIEvent() • het programma daarop volgend : retrieveFollowingSIEvent() • alle toekomstige programma’s binnen bepaald interval: retrieveScheduledSIEvents() Verder is het ook mogelijk het type van de Service op te vragen. De verschillende mogelijkheden zijn : digitale tv, digitale radio, Pal, Secam, NTSC, FM radio, . . . (zie [11]) Gegevens als id, naam, locator, en dergelijke kunnen natuurlijk ook opgevraagd worden. Een SIEvent bevat alle nodige gegevens over een programma, zoals het genre, de duur, de start- en eindtijd, de DvbLocator, de running status, een korte beschrijving, . . . Het genre wordt bekomen door de twee content-nibbles op te vragen. Men bekomt ´e´en 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 ´e´en functie: public void postRetrievalEvent(SIRetrievalEvent event). De klasse SIRetrievalEvent heeft een aantal subklasses, waaronder de klasse SISuccessfulRetrieveEvent. Wanneer het ontvangen object van dit type is, betekent dit dat de aanvraag gelukt is en kan men de resultaten bekomen via de functie getResults(). De overige subklassen wijzen op de oorzaak van het falen zoals bijvoorbeeld SILackOfResourcesEvent, SITableNotFoundEvent, . . .
4.3 Import Module
36
Via het SIRetrievalEvent-object kan men het eerder meegestuurde AppData-object bekomen om zo de verwerking van de ontvangen resultaten verder af te werken. De SI-gegevens zijn helemaal niet statisch. Wat op het ene tijdstip een toekomstig programma 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 verschillende 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 effici¨enter 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 ´e´en welbepaalde taal. Wanneer men de SI in verschillende talen wil, dan moet men meerdere instanties van de SIManager cre¨eren. 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 SIRequestor -interface implementeert. Deze interface bevat twee functies: • public void notifySuccess(SIRetrievable[] result) Deze functie wordt opgeroepen wanneer de aanvraag gelukt is en verkrijgt de resultaten als parameter. • public void notifyFailure(SIRequestFailureType reason) Wanneer het opvragen mislukt is, wordt deze functie opgeroepen. De oorzaak van het falen wordt er meegedeeld. Door deze klasse te voorzien van de nodige gegevens, kan men de resultaten er verwerken.
Hier wordt er dus niet met een listener gewerkt die de nodige events ontvangt. Per aanvraag
4.3 Import Module
37
wordt er een SIRequestor -instantie gecre¨eerd die de resultaten van deze aanvraag zal verwerken. Dit is een nadeel ten opzichte van het DVB SI-systeem waarbij er slechts ´e´en 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 SIManager. 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 requestor) 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 ´e´en soort Event, bijvoorbeeld de ProgramScheduleListener
4.3 Import Module
38
ontvangt enkel de ProgramScheduleEvent. Op die manier kan men enkel inschrijven op de events waarin men ge¨ınteresseerd is. Keuze Ik ben begonnen met het importeren van SI via de JavaTV API. Het feit dat JavaTV niet tot op descriptor-niveau reikt, was me toen nog onbekend. Het importeren gebeurt slechts in twee fasen: de huidige programma’s en alle overige programma’s. Dit werkt voortreffelijk. Ik heb dit uitgetest door de SI uit de kabel van Telenet op te vragen. De testapplicatie importeerde mooi alle nodige informatie. Via het JMF-systeem kon ik vloeiend tussen de verschillende zenders schakelen, met als opmerking dat enkel de niet-ge¨encrypteerde 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 informatieverkenner. Meer informatie over de informatieverkenner vindt u in 4.7.5 op pagina 65. Het opvragen van het programma volgend op het huidige is zoals eerder vermeld heel wat complexer dan via de DVB SI API. Het meest doorslaggevende nadeel is natuurlijk dat deze API niet tot op descriptor-niveau reikt. Het opvragen van het genre is hierdoor onmogelijk, tenzij men zelf deze API zou uitbreiden . . . Dit alles leidde mij ertoe het importeersysteem verder en volledig uit te bouwen aan de hand van de DVB SI API. Qua opbouw is deze heel wat eenvoudiger. In het labo is een teststroom ontwikkeld door het opnemen van een transportstroom uit de kabel van telenet. Het importeren werkt voortreffelijk wanneer dit op deze zelfgemaakte transportstroom gebeurt. Het importeren van de SI-informatie uit de kabel van Telenet lukt echter niet via de DVB SI API. De oorzaak hiervan is me tot op heden nog steeds onbekend. De API slaagt er niet in om er de services te
4.3 Import Module
39
ontdekken.
4.3.4
LE- & VoD-server
Deze server levert video on demand” en live events” aan de gebruiker. Onder video on ” ” ” demand” verstaat men een virtuele videotheek waarbij men een film kan bestellen. Live events zijn bijvoorbeeld concerten, festivals, . . . die live opgenomen worden en aan de kijker beschikbaar worden gesteld. De VoD-server dient als tussenliggende server tussen de Xlet en de IP2DVB-gateway. Deze gateway, ontwikkeld door Kristof Demeyere, zet de film zelf op de kabel en levert de juiste locator aan de VoD-server. Dankzij deze locator kan de Xlet de film localiseren op de broadcast stroom. Deze gateway wordt, evenals de VoD-server, ge¨ınitialiseerd via een XML-bestand. (zie bijlage nr A.4.1) Dit XML-bestand bevat de nodige gegevens over de film zelf zoals naam, beschrijving, prijs, e.d. alsook de fysische locatie van het filmbestand. Bij het opstarten van de EPG worden alle VoD- en LE-gegevens opgevraagd aan de VoDserver. 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 gecre¨eerd en in de opslageenheid opgeslagen. Wanneer alles ge¨ımporteerd is, verwittigt de hoofdmodule de GraphicalController die verder het VodScreen hiervan op de hoogte brengt. De Xlet kan aan de hand van de verkregen id’s de nodige acties op een bepaald item uitvoeren. Deze acties zijn: afspelen, pauzeren, stoppen, vooruit- en achteruitspoelen. Deze acties worden doorgegeven aan de gateway die het verdere verloop ervan verzorgt. Het doorgeven van deze aanvragen verloopt via het HTTP-protocol. Om compatibiliteitsredenen heb ik hiervoor de HTTP-module van Kristof overgenomen. Voor meer informatie over de IP2DVB-gateway verwijs ik door naar Kristofs thesisverslag. De EPG communiceert dus niet rechtstreeks met de IP2DVB-gateway, maar werkt via een
4.3 Import Module
40
tussenliggende, eigen ontwikkelde server. Op die manier kan later altijd op een eenvoudige wijze overgeschakeld worden op een nieuwere versie of op een compleet ander systeem. De communicatie tussen de Xlet en de eigen VoD-server blijft immers behouden. Dankzij het RCRPprotocol kan men ook eenvoudig nieuwe acties toevoegen door deze als een nieuw subtype te defini¨eren.
4.3.5
Movie Information Server
De gebruiker wordt extra informatie over films aangeboden. De eigen ontwikkelde movie information 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 effici¨ent mogelijke manier beheerd wordt. Ze moet dus vaak ge¨ updatet worden en zoveel mogelijk interessante SI bijhouden.
4.3.8
Keuze SI - externe server
Momenteel wordt de basisinformatie over de programma’s uit de stroom zelf gehaald. Een alternatief bestaat erin deze informatie op te halen van een externe server. Beide systemen hebben hun voor- en nadelen. Het ophalen van SI heeft als grote voordeel dat de EPG compleet onafhankelijk van het terugkeerkanaal is. Het nadeel is echter dat het importeren van SI relatief
4.3 Import Module
41
traag verloopt. Via een externe server zal dit heel wat sneller verlopen, maar hiervoor moet er natuurlijk zo’n server ontwikkeld en up-to-date gehouden worden. Een overzichtje: SI • voordelen – onafhankelijk van het terugkeerkanaal. – geen server vereist • nadelen – relatief traag Externe server • voordelen – snel • nadelen – afhankelijk van het terugkeerkanaal – ontwikkeling & onderhoud van deze server Het manueel ingeven van de SI in de server is onbegonnen werk. Bijgevolg moet deze server automatisch de SI ophalen uit de broadcast stroom. Er moet hiervoor een brug tussen het MHPplatform 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 broadcastprofiel. Vervolgens leek het, in het kader van deze thesis, eerder aangewezen om de SI rechtstreeks uit de kabel op te halen, dan deze van een server te halen. Zo worden de mogelijkheden van de desbetreffende API’s meer en beter benut. Deze thesis bestaat er - naar mijn mening -
4.3 Import Module
42
in om de verschillende MHP API’s te bestuderen en toe te passen in een Xlet. Hardwarematig gezien zou het gebruik van een server ook een aantal praktische problemen met zich meebrengen. De combinatie van een set-top box met een server dat tevens automatisch stream events kan genereren is helemaal niet evident. Het zou het importeersysteem ook heel wat complexer maken, waardoor ik minder tijd in de overige features zou kunnen steken.
4.3.9
Intern systeem
Zoals elke module heeft ook deze module een controller, namelijk de ImportController. Deze implementeert vier interfaces • EPGmodule • RCReceiveInterface • ImportInterface • ImportControllerInterface
De ImportInterface is gericht naar buiten toe, naar de overige modules, terwijl de ImportControllerInterface 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 functies 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 EPGdataInterface 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. Daarnaast zijn er nog twee plug-ins die de Vod-gegevens en de LE-gegevens importeren. De overige
4.3 Import Module
43
twee plug-ins, het importeren van programmaspecifieke informatie en algemene extra informatie zijn reeds in het systeem ge¨ıntegreerd, maar zijn niet verder uitgewerkt. Deze worden als een uitbreiding voor later beschouwd. Opdat de ImportController deze op een eenvoudige manier kan beheren, moeten ze elk de ImportPlugIn-interface implementeren. Voor de importeermodule is het heel belangrijk dat deze eenvoudig uitbreidbaar is. Later kunnen er immers andere en nieuwe technologie¨en 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 opvragen 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 sequenti¨ele fases: 1. huidige tv-programma’s 2. volgende tv-programma’s 3. huidige radioprogramma’s
4.3 Import Module
44
4. de overige tv-programma’s 5. de volgende radioprogramma’s 6. de overige radioprogramma’s Het importeren van de huidige radioprogramma’s wordt hier voorgenomen op de overige tvprogramma’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. Hieronder 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 natuurlijk 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 defini¨eren 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 XMLbestand 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 MainControllerInterface 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 effici¨ente manier opgeslagen 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 aangemaakt 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 programma’s, dan de programma’s daaropvolgend en het eindigt met alle overige programma’s in
4.4 EPGdata Module
46
de toekomst. Om dit eenvoudig bij te houden, bestaat er voor elke zender een klasse ChannelList die het huidig, het volgend en alle toekomstige programma’s bijhoudt. Wanneer de opslageenheid een Vector van huidige programma’s ontvangt, moet deze per programma kijken in welk klasseobject dit programma opgeslagen moet worden. De bedoeling is de verzameling van ChannelList-klassen zo compact mogelijk op te slaan zonder aan performantie in te boeten. Java heeft verschillende soorten klassen om data bij te houden, zoals List, Vector, ArrayList, HashTable, HashMap, . . . Deze hebben allen hun voor- en nadelen. Een Vector en HashTable hebben het grote voordeel ten opzichte van een ArrayList en HashMap dat ze gesynchroniseerd zijn. Hiervoor moeten ze logischerwijs wel wat aan snelheid inboeten. Dit is echter voor geen al te grote structuren te verwaarlozen. Aangezien de EPGdata module zijn gegevens ter beschikking stelt aan meerdere modules die zelf meerdere threads bevatten, is het aan te bevelen deze gegevens gesynchroniseerd op te slaan. Het grote verschil tussen Vector en HashTable is het feit dat een Vector volgorde bewaart en een HashTable niet. Dit heeft een aantal belangrijke implicaties. Toevoegen van programma’s en het overlopen ervan zijn de twee belangrijkste acties en moeten bijgevolg zo snel mogelijk gebeuren. Het overlopen van de verschillende zenders is met een Vector heel eenvoudig. Eenmaal deze gesorteerd is, kan men gewoonweg de zenders overlopen. Met een HashTable is dit niet het geval. Deze behoudt de volgorde niet en bijgevolg is het niet mogelijk om de zenders makkelijk te overlopen in een welbepaalde volgorde. Deze volgorde zou extern moeten opgeslagen worden. Het toevoegen van programma’s is dan weer veel eenvoudiger aan de hand van een HashTable. Het opzoeken gebeurt namelijk via de hashfunctie van de naam van de zender. Bij een Vector daarentegen moet de volledige rij overlopen worden tot de juiste zender gevonden is. Om de voordelen van beide datastructuren over te nemen, is er gebruik gemaakt van een hybride oplossing. De ChannelList-objecten worden bijgehouden in een Vector. Op die manier kan men deze dus enorm snel overlopen. Om te zoeken naar een bepaalde zender, maakt het system gebruik van een HashTable, die per zender de index in de Vector bijhoudt. Hierdoor zal het zoeken in die vector heel wat sneller verlopen. Wanneer echter de volledige Vector gesorteerd wordt, moet ook de HashTable hieraan aangepast worden. Maar dit eenmalig kleine nadeel weegt niet op tegen het grote voordeel van het snel zoeken.
4.4 EPGdata Module
47
Indien men extra filminformatie opvraagt via de movie information server, wordt ook deze filminformatie opgeslagen in de opslageenheid. Dit gebeurt aan de hand van de klasse Movie. Deze klasse is een subklasse van de klasse Program. Ze bevat naast de basisinformatie ook typische filmgegevens zoals regisseur, cast, . . . Ook de gegevens van de VoD- en LE-programma’s worden hier bijgehouden in de klassen VODElement en LEElement respectievelijk. Samengevat bevat de EPGdata-klasse dus een Vector die per zender een object van de klasse ChannelList bijhoudt, een Vector van VODElement-objecten , een Vector van LEElementobjecten en een Vector van Movie-objecten. De klasse ChannelList bevat een current Program, een next Program en een Vector van future Program-objecten. Elk object van de klasse Program bevat alle nodige gegevens over een programma. Dit kan zowel een tv- als een radioprogramma zijn. Een overzicht hiervan is terug te vinden in het UML-schema in D.7. • naam van het programma • naam van de zender • de locator • start- en eindtijd • de duur in seconden • programmatype en -subtype • korte beschrijving
4.4.2
Zoekfuncties
De EPGdataInterface biedt een heleboel zoek- en sorteerfuncties aan. Zo is het mogelijk om alle programma’s van een bepaald type, alle programma’s binnen twee bepaalde tijdstippen, alle mogelijke genres die terug te vinden zijn in de opslageenheid, . . . op te vragen, en dit telkens op verschillende manieren. Er is eveneens een systeem voorzien om de volledige opslageenheid op kernwoorden te doorzoeken. Een soort zoekmachine dus. Deze taak wordt uitbesteed aan de ChannelList-klasse die op zich, z’n eigen programma’s doorzoekt. Er zijn twee verschillende methodes voorzien om te zoeken op kernwoorden.
4.4 EPGdata Module
48
De eerste methode bestaat erin dat, los van het aantal kernwoorden, punten gegeven worden op de belangrijkheid van overeenkomst. Wanneer de naam van het programma perfect overeenkomt 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 KeywordSortElement-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 v´e´el 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://..<sID>[.[&]][;<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 bestandssysteem. Elk van deze componenten wordt in hexadecimale tekens voorgesteld en enkel de eerste drie componenten zijn verplicht.
4.5 Play Module
4.5.2
51
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 mediagegevens 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 protocol 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 ge¨experimenteer 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 verscheen 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 gecre¨eerd, 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 samen met SI. De gebruiker kan dus binnen ´e´en service kiezen welke stromen hij bekijkt. Zo kan
4.5 Play Module
52
men bijvoorbeeld videobeeld vanuit verschillende camerahoekpunten gezien, meesturen. Parafraserend 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 mogelijks 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 ServiceContextFactory kan de huidige ServiceContext opgevraagd worden. Door de methode select( DvbLocator[] 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 inspelen 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 exclusieve 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 ResourceProxy en de ResourceServer. Een ResourceClient kan toegang tot systeembronnen aanvragen aan de ResourceServer. Ze maakt hiervoor een ResourceProxy aan die deze toegang regelt. De ResourceServer zal deze dan al dan niet valideren. Op die manier kan de ResourceServer heel eenvoudig de toegang ook terug afnemen door de ResourceProxy ongeldig te verklaren. De applicatie heeft dus op geen enkel moment rechtstreeks contact met de bron zelf, maar moet telkens via een proxy om. De functies uit de ResourceClient zijn :
4.6 Resource Module
54
• public boolean requestRelease(ResourceProxy proxy, Object requestData) ; Hier wordt de ResourceClient gevraagd zijn toegang tot de systeembron van deze proxy op te geven omdat een andere applicatie deze toegang aangevraagd heeft. De applicatie staat vrij hierop al dan niet in te gaan door de waarde true of false terug te geven. • public void release(ResourceProxy proxy) ; In deze functie verwittigt de ResourceServer dat de systeembron vrijgegeven wordt. De ResourceClient wordt hier nog de kans gegeven om een aantal zaken op te kuisen vooraleer de systeembron definitief afgenomen wordt bij het be¨eindigen 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 programma. Ze bestaat uit drie grote onderdelen: de verschillende schermlagen, het terugkeerkanaal en exclusieve toegang tot KeyEvents.
4.6.1
Intern systeem
De ResourceController is de dirigent in de systeembronnenmodule. Deze implementeert twee interfaces, nl. ResourceControllerInterface en de welgekende EPGmodule. De ResourceControllerInterface 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, ReturnChannel 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 eenvoudig 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 specifieke interface (ScreenLayerInterface, ReturnChannelInterface en ExclusiveKeyAccessInterface
4.6 Resource Module
55
respectievelijk) die de nodige publieke functies aanbiedt. Referenties naar deze interfaces kunnen via de ResourceController opgevraagd worden.
4.6.2
De verschillende schermlagen
Een tv-beeld bestaat uit drie verschillende lagen. De achterste laag is de achtergrondlaag. Hierin kan ofwel een kleur ofwel een I-frame afgebeeld worden. De middelste laag waarin de videostroom afgespeeld wordt, is de videolaag. De bovenste laag is de grafische laag. Daarin worden de grafische componenten van een applicatie afgebeeld. Wanneer de applicatie exclusieve toegang tot een van deze lagen wil verschaffen, moet de applicatie deze reserveren. Hiervoor moet men per laag het desbetreffende ResourceProxy-object cre¨eren. Deze zijn HGraphicsDevice, HVideoDevice en HBackgroundDevice. Het reserveren ervan wordt gevraagd aan het ResourceServer -object (tevens vertegenwoordigd door de klassen HGraphicsDevice, HVideoDevice en HBackgroundDevice) via de functie reserveDevice(ResourceClient client). De verschillende lagen worden gebundeld tot ´e´en fysiek geheel, de HScreen. Er is slechts ´e´en 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 positie 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 bijgevolg 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 ConnectionRCInterface 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 gecre¨eerd 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 ´e´en per scherm. Zo worden deze mooi gescheiden van elkaar.
4.7 Graphical Module
4.7.1
57
Intern systeem
De GraphicalController heeft in het grafisch systeem een enorm belangrijke functie. Deze beheert de verschillende schermen en delegeert de opdrachten van de kern van het systeem door naar alle schermen. Het UML-schema van deze module is terug te vinden in D.10. De GraphicalController implementeert de interfaces RCReceiveInterface, EPGmodule en GraphicalControllerInterface. Deze laatste levert de functies waarbij de controller de verschillende schermen kan aanspreken en omgekeerd. Via de functie setModus(short modus) kan de hoofdmodule bijvoorbeeld een bepaald scherm (mode) opstarten en zichtbaar maken. De GraphicalController zorgt er steeds voor dat slechts ´e´en scherm zichtbaar is en focus heeft. Via functies als setLanguage(int taalIndex) en setSkin(short skinIndex) wordt de GraphicalController aangespoord om de taal en de skin in elk scherm aan te passen. Omgekeerd, levert de GraphicalControllerInterface-interface functies die de schermklassen kunnen oproepen, zoals switchToChannel(), recordProgram(), addToPlanner(), getMovieInformation(), retrieveReminderList(), . . . De GraphicalControllerInterface is een subklasse van de Observer -interface. Van zodra er een wijziging optreedt in de opslageenheid zal deze (de Observable) via het model-view paradigma automatisch de GraphicalController (de Observer ) hiervan op de hoogte brengen via de update() functie. De GraphicalController bevat een collectie van schermen. De index bepaalt het type en wordt gedefinieerd in de klasse ScreenModus. Momenteel zijn er elf verschillende modi gedefinieerd, wat men natuurlijk nog kan uitbreiden. • public static final short MAIN SCREEN = 0; • public static final short VISIBLE CONTROLLER = 1; • public static final short CURRENT PROGRAMS = 2; • public static final short ALL PROGRAMS = 3; • public static final short CATEGORY = 4; • public static final short SUGGESTION = 5; • public static final short LIVE EVENTS VOD = 6;
4.7 Graphical Module
58
• public static final short PLANNER = 7; • public static final short SEARCH = 8; • public static final short SETUP = 9; • public static final short PVR = 10; Elke schermklasse moet de ScreenInterface implementeren. Deze interface zorgt ervoor dat de GraphicalController de nodige informatie over de schermen kan opvragen en eenvoudig bepaalde opdrachten kan doorgeven. Elk scherm bestaat uit een hoofdcontainer die verder opgesplitst wordt in deelcontainers. Het is de verantwoordelijkheid van de hoofdcontainer van elk scherm om de verkregen opdracht zoals bijvoorbeeld het veranderen van de taal, door te spelen naar zijn eigen deelcomponenten die dit, indien nodig, terug verder doorspelen naar hun deelcomponenten. Er is dus een duidelijke hi¨erarchie aanwezig. De GraphicalController zelf is een subklasse van de HContainer -klasse. Deze wordt rechtstreeks toegevoegd aan de HScene. Ook hier wordt de hi¨erarchie 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 setAllVisibleFalse() 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 gecre¨eerd. Deze zal alle klassen voor dit nieuwe scherm bevatten. De nieuwe schermklasse implementeert de interface ScreenInterface, bevat een referentie naar de controller en wordt toegevoegd aan de rij met schermenklassen. Verder voegt men ook een mode toe aan de ScreenModus-klasse.Het hoofdmenu bestaat uit een
4.7 Graphical Module
59
ronddraaiend menu. Deze zal automatisch de aanwezige schermen opnemen. Meer informatie hierover in 4.7.5 op pagina 64. Via de ScreenLayerInterface als gegevenselement is het mogelijk om een afbeelding in de achtergrond 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”,”T´el´evision”,”ne change pas”} };
4.7 Graphical Module
60
Wanneer nu de taalIndex op twee gesteld wordt, dan worden bijgevolg de termen in het Frans op het scherm afgebeeld. Een andere oplossing bestaat erin de verschillende opschriften bij te houden in configuratiebestanden. 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 voorgeprogrammeerde en een die volledig zelf samengesteld kan worden. Elke skin wordt eenduidig bepaald door een achtergrondafbeelding en vier verschillende kleuren: • bgColor : de achtergrondkleur van de open vlakken (transparante kleur) • edgeColor : de voorgrondkleur van de tekst in de knoppen en vlakken • bgColorF : de kleur van de knoppen wanneer deze geselecteerd zijn (focus) • bgColorNF : de kleur van de koppen wanneer deze niet geselecteerd zijn. Deze klasse levert de nodige functionaliteit om de verschillende kleuren en achtergrond voor de huidige skin in te stellen en af te leveren. Het doorspelen van de skin doorheen het volledige programma gebeurt op een gelijkaardige manier als het doorgeven van de taal. De GraphicalController krijgt de opdracht om een bepaalde skin in te stellen en geeft deze opdracht door aan de hoofdcontainers van alle schermen via de functie changeSkin(). Deze spelen dit terug verder door aan hun deelcontainers en componenten. Een hoofdcontainer bevat telkens de vier verschillende kleuren als publieke gegevenselementen zodat de deelcontainers hier toegang tot hebben. Wanneer de skin ingesteld wordt op een component, worden deze vier kleuren als parameter meegegeven want een component heeft namelijk geen referentie naar de hoofdcontainer.
4.7 Graphical Module
61
Het skinsysteem is ontwikkeld nadat de applicatie voor het grootste gedeelte voltooid was. Michiel Ide stelde voor om de EPG uit te breiden met verschillende skins. Dit was een uitdaging. Op die manier was het mogelijk aan te tonen dat de huidige architectuur eenvoudig uitbreidbaar is met features zoals deze. Doorheen de applicatie is enkel in alle grafische componenten de functie changeSkin() toegevoegd en het systeem werkte. Dit laat niet weg dat de implementatie hiervan toch wel enige tijd in beslag nam door de vele containers en componenten. Momenteel is het niet mogelijk om de instellingen van de huidige skin op te slaan. Opslag op de set-top box is met de huidige boxen niet mogelijk omdat hun geheugen niet blijvend is. Deze instellingen moeten dus bijgevolg op de configuratieserver opgeslagen worden. Wegens tijdsgebrek is dit opengelaten als een mogelijke uitbreiding voor het programma. De implementatie hiervan werd namelijk niet als topprioriteit beschouwd. Het gebruik van een eigen gekozen achtergrond is een verdere uitbreiding om het systeem nog heel wat te personaliseren. De EPG levert de gebruiker de mogelijkheid om de achtergrond volledig zelf te kiezen. Dit kan bijvoorbeeld een foto van zijn/haar vriend(in) zijn, een foto van zijn of haar favoriete filmster, favoriete auto, noem maar op. Hiervoor moet de gebruiker in staat gesteld worden een afbeelding door te geven. Dit kan bijvoorbeeld gebeuren via een website, waar men zijn achtergrondafbeelding kan uploaden. Aan de hand van een identificatiecode kan de applicatie de juiste achtergrond via het terugkeerkanaal opvragen aan de verantwoordelijke server.
4.7.4
Vaak gebruikte componenten
HP logo De applicatie is opgefleurd met een logo, het HP Solutions logo. Het design en de implementatie ervan heeft David Plets verzorgd. Er zijn twee verschillende modi, elk met een eigen design. Indien gewenst kan men de kleuren automatisch in elkaar laten overvloeien en het logo laten bewegen. HScrollComp Deze klasse, afgeleid uit de klasse ScrollableText ontwikkeld door Oy, zorgt ervoor dat een tekst van een willekeurige lengte automatisch opgedeeld wordt zodat alles mooi zichtbaar is. Men kan doorheen de tekst lopen aan de hand van een eenvoudig scrollsysteem. De lay-out
4.7 Graphical Module
62
van de originele component werd volledig aangepast. Dank hiervoor aan David Plets voor de implementatie ervan. HProgressBar Deze component vertoont hoe lang een programma reeds aan de gang is op een visueel aantrekkelijke manier. Er zijn twee verschillende modi: met en zonder asgegevens. Wanneer men deze optie aanzet via de functie setAxesOn(true), dan verschijnt er links en rechts boven het balkje de start- en eindtijd respectievelijk. Verder kan men ook de voor- en achtergrondkleur van de component instellen. HPolygon Deze klasse levert componenten in de vorm van een +, een - of een driehoek. Voor deze laatste is het ook mogelijk de ori¨entatie 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 gegevensveld. 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 geselecteerde programma. Deze informatie bestaat uit de naam van het programma en een beschrijving. Deze beschrijving komt in een HScrollComp terecht zodat men doorheen de tekst kan lopen om
4.7 Graphical Module
63
deze volledig te lezen. Ze bevat meestal het genre en de korte inhoud. Opnieuw kan men de taal en de skin naar believen aanpassen. MovieInformationScreen De MovieInformationScreen-klasse levert een doorzichtig venster waarbij er informatie over een film wordt weergegeven. Deze kan natuurlijk ook simpelweg SI-informatie over een gewoon tv-programma afbeelden. Deze tekst is in een HScrollComp geplaatst zodat men doorheen de tekst kan lopen indien deze niet binnen het kader past. Wanneer er nog geen informatie beschikbaar is omdat ze nog van de server opgehaald moet worden, bevindt de container zich in de wachtstatus. Er verschijnt een melding op het scherm dat de informatie opgehaald wordt. Indien de informatie niet beschikbaar is omdat de server bijvoorbeeld ontoegankelijk is, dan genereert dit venster hiervoor eveneens een melding. Zoals in alle containers en componenten kan men ook hier de taal en skin instellen. GetBackContainer De meeste schermen leveren de mogelijkheid om over te schakelen naar een bepaald programma en dit te bekijken. Om de kijker tijdens het tv-kijken niet verder te storen wordt de volledige applicatie onzichtbaar gemaakt. Deze blijft echter in de achtergrond actief. Wanneer de gebruiker 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 ontwikkeld. 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 screenModus). 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 GraphicalController het vorig scherm of het hoofdmenu respectievelijk terug zichtbaar.
4.7 Graphical Module
4.7.5
64
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 ontwikkeld, 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 menuafbeeldingen 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 ´e´en item afgebeeld in plaats van twee voor een oneven aantal menu-items. Het aantal niveaus, de co¨ordinaten, de afmetingen van de afbeeldingen, de onderlinge tussenafstanden, . . . werkelijk alles moet automatisch bepaald worden. Op een paar details na is alles geautomatiseerd. Enkel op de x-co¨ordinaten 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 ´e´enmaal 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 opgehaald en herschaald zijn vooraleer het menu af te beelden. Dit herschalen levert geen al te grote
4.7 Graphical Module
65
vertraging op, zodat het niet nodig is om alle afbeeldingen in alle nodige formaten vooraf mee te sturen. De besturing van het menu gebeurt via de pijltjestoetsen rechts en links. Wanneer men op de linkertoets drukt, draait het menu wijzerzin. In het midden van het wiel verschijnt het HP Solutions logo. Deze beweegt en de kleuren vloeien op een random manier in elkaar over. In het hoofdscherm is het verder mogelijk om de taal in te stellen via de kleurtoetsen rood en groen. Indien men op de gele toets drukt start een verborgen feature, namelijk het populaire spelletje Snake (zie C.13 voor een afbeelding hiervan). Dit menu kan men op verschillende manieren uitbreiden. De mode waarin er een even aantal items aan het wiel worden toegevoegd is nog niet ge¨ımplementeerd. Ook op visueel vlak is het mogelijk om het geheel nog wat op te fleuren. Zo kan het wiel realistischer gemaakt worden door de afbeeldingen in een cirkel te laten bewegen wanneer men aan het wiel draait. Hiervoor moet het menu natuurlijk de padco¨ordinaten 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 ´e´en programma met beschrijving ofwel twee programma’s op het scherm te plaatsen. Wanneer er slechts ´e´en programma getoond wordt, kan de gebruiker het programma daaropvolgend opvragen met het pijltje naar omhoog en dan terugkeren met het pijltje naar omlaag. Indien men op de ok-toets drukt, schakelt de EPG over naar het gekozen programma indien
4.7 Graphical Module
66
deze zich op dit ogenblik afspeelt, anders wordt er gewoon naar die zender overgeschakeld. Via de blauwe toets kan men dit menu onzichtbaar maken om het tv-kijken verder niet te verstoren. Via de gele toets is het mogelijk om het extra menu op te roepen. Er verschijnt een venstertje met vier verschillende mogelijkheden die men aanstuurt via de kleurtoetsen. Deze zijn: kiezen van een programma, het opnemen ervan, een herinnering instellen voor dit programma of het venstertje terug sluiten. C.2 toont een afbeelding van de informatieverkenner met dit extra menuutje opgelicht. Wanneer men de volledige informatie over een programma wilt, kan men deze opvragen via de infotoets. Er verschijnt een doorzichtig venster in het midden van het scherm dat informatie zoals genre en beschrijving levert. Wanneer er extra informatie beschikbaar is zoals bij een film wordt deze automatisch op de desbetreffende server opgehaald en op het scherm geplaatst. De package graphicalmodule.navigatorscreen bestaat uit drie klassen. De hoofdcontainer is de klasse NavigatorScreen. Deze heeft drie deelcontainers: de onderste balk SimpleNavigator, het menuvenstertje ColorChooseMenu en het informatievenster MovieInformationScreen, dewelke zich in de hoofdpackage graphicalmodule bevindt. De SimpleNavigator -klasse verkrijgt telkens focus. Deze ontvangt en verwerkt bijgevolg de verschillende KeyEvents. De EPGdatamodule levert een referentie naar een Vector met alle huidige programma’s en via de pijltjestoetsen kan men zo de verschillende zenders eenvoudig overlopen. Wanneer men een actie op een bepaald programma uitvoert zoals het opnemen ervan, wordt deze actie doorgegeven aan de NavigatorScreen die dit verder doorgeeft aan de GraphicalController zodat het uiteindelijk in de hoofdmodule terecht komt. De NavigatorScreen wordt telkens op de hoogte gehouden in welke fase het importeren zich bevindt en zal de SimpleNavigator naargelang deze fase voorzien van de nodige gegevens, dewelke hij ophaalt via een referentie naar de EPGdataInterface. Dit leverde de grootste moeilijkheden. De knoppen moeten immers naargelang de reeds voorhanden mogelijkheden al dan niet zichtbaar zijn. Wanneer bijvoorbeeld de radioinformatie nog niet ge¨ımporteerd is, zal de tekst bij de groene knop niet zichtbaar zijn. En indien enkel voor de tv-zenders beide programma’s ge¨ımporteerd zijn, zal de uitleg bij de rode knop enkel voor de tv-zenders en niet voor de radiozenders zichtbaar zijn. Bij het indrukken van een toets moet er telkens via booleans nagegaan worden welke informatie er reeds beschikbaar is en welke informatie er momenteel op het scherm zichtbaar is. Afhankelijk daarvan wordt de desbetreffende actie uitgevoerd.
4.7 Graphical Module
67
De beschrijving bij het programma wordt geplaatst in een HStaticText waarop een DVBTextLayoutManager losgelaten wordt. Er zijn slechts twee regels tekst beschikbaar. Indien dit onvoldoende 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 ´e´en en vtm zullen hier bovenaan staan. De hoofdcontainer is de klasse CurrentScreen. Deze bevat meerdere deelcontainers, zoals de TitleScreen, ProgramInfoScreen en CurrentInformationScreen. Deze laatste klasse bevat de legende die een overzicht biedt van de verschillende mogelijkheden. Naargelang het aantal zenders maakt de CurrentScreen-klasse dynamisch knoppen aan van het objecttype HTextButtonIndexedInfo. Deze klasse is een subklasse van de HTextButton-klasse. Ze bevat als extra gegevensvelden een index en een boolean die aangeeft indien men al dan niet extra informatie kan opvragen. Dit wordt visueel voorgesteld door een i op het einde van de knop te plaatsen. De generatie van de knoppen gebeurt volledig automatisch aan de hand van het aantal knoppen en de de vrije plaats waar ze terecht komen. De knoppen worden verdeeld in pagina’s. De gebruiker kan doorheen deze pagina’s bladeren aan de hand van de pijltjestoetsen links en rechts. Driehoekjes, voorgesteld door de klasse HPolygon geven aan in welke richting men kan bladeren. Dit gaat heel wat sneller dan alle knoppen te moeten overlopen en biedt ook een beter overzicht aan. De gebruikelijke acties zoals het overschakelen naar dit programma of het opnemen ervan zijn voorzien. Via de gele toets kan men schakelen tussen televisie en radio. Wanneer men een zender selecteert, verschijnt de informatie in de ProgramInfoScreen en wordt de HProgressBar in de legende automatisch aangepast. Het toevoegen van een HFocusListener aan deze knoppen zorgt ervoor dat de applicatie op de hoogte gebracht wordt indien een knop focus verkrijgt of verliest via de functies focusGained(FocusEvent e) en FocusLost(FocusEvent e) respectievelijk.
4.7 Graphical Module
68
Aan de hand van de index, kan men opvragen welke knop er juist geselecteerd is. Indien er extra informatie voorzien is, kan men deze opvragen via de infotoets. Deze informatie verschijnt opnieuw in de ProgramInfoScreen-container. Via de kanaal omhoog- en omlaagtoetsen kan men doorheen deze informatie lopen. C.3 toont een foto van dit scherm waarbij er extra filminformatie opgevraagd is. Rechtsboven verschijnt een herschaalde versie van het videobeeld, dat het huidig programma bevat. Via de groene toets kan men de preview-mode aan of uit zetten. In deze mode zal het videobeeld automatisch overschakelen naar de zender die momenteel geselecteerd is. Op die manier kan men telkens zien hoe het programma eruit ziet. Dit overschakelen zorgt wel telkens voor een minimale vertraging. Het terugkeren naar het hoofdmenu gebeurt zoals overal met de blauwe toets of via de back-toets. Het gebruik van de ok-toets op een HTextButton of een afgeleide klasse hiervan leverde een klein probleempje op. Deze wordt namelijk niet opgevangen door het toevoegen van een KeyListener. Voor de ok-toets is er namelijk een HActionListener nodig. Het toevoegen van deze klasse als een private innerclass lost het probleem op een elegante manier op. Volledig televisieoverzicht Dit scherm levert zoals de naam doet vermoeden, een overzicht van alle zenders met al hun programma’s. Deze worden gesorteerd per zender. De volgorde van de zenders wordt weerom bepaald door hun populariteit. Hier kan men zoals in een tv-gids vooruitblikken naar de programma’s die zich op een later tijdstip zullen afspelen. Zie C.4 voor een afbeelding hiervan. Het UML-schema van deze subpackage is terug te vinden in D.11. Het scherm is opgebouwd uit een aantal deelcontainers. De TitleScreen levert opnieuw de titel en de datum samen met het HP-logo. De ProgramInfoScreen levert de informatie over het geselecteerde programma. Wanneer er extra filminformatie opgevraagd wordt, verschijnt ook deze in dit gedeelte van het scherm. Via de kanaal omhoog- en omlaagtoetsen kan men opnieuw doorheen de tekst lopen. De FullOverviewInformationScreen-klasse levert de legende. Deze is afhankelijk van waar de focus zich bevindt. Dit wordt verder in de tekst duidelijk. Rechtsboven verschijnt opnieuw het videobeeld. De klasse AllProgramMenu levert het overzicht met de programma’s. Deze bestaat uit een StaticChannelMenu en per zender een StaticProgramMenu. De StaticChannelMenu bevat een
4.7 Graphical Module
69
rij van HTextButtonIndexed -objecten, waarmee men alle zenders kan overlopen via de pijltjes omhoog en omlaag. Het bladeren doorheen de verschillende zenders gebeurt opnieuw aan de hand van pagina’s. Via de rode en de groene toets kan men naar een volgende en vorige pagina respectievelijk overgaan. Dit in tegenstelling tot de overige schermen waar de pijltjes naar links en rechts deze functionaliteit bieden. Hier dienen deze pijltjes echter om te schakelen tussen het zender- en het programmamenu. Het al dan niet oplichten van de tekst volgende pagina” ” en vorige pagina” in de legende geeft de richtingen aan naar dewelke de gebruiker kan blade” ren. Het genereren van de knoppen afhankelijk van het aantal zenders en de beschikbare plaats gebeurt evenals het opdelen in pagina’s volledig automatisch en op dezelfde manier als in alle overige schermen. Via de gele toets kan men opnieuw schakelen tussen radio- en televisieprogramma’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 legende 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 FullOverviewScreen 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 automatisch overgeschakeld wordt naar dit programma wanneer het begint. Zie C.5 voor een afbeelding van dit scherm. De legende geeft een overzicht van de mogelijkheden. Zo kan men herinneringen verwijderen, instellen indien deze al dan niet automatisch moeten starten of het programma laten opnemen. Via de pijltjes naar links en rechts kan men naar goede gewoonte bladeren tussen de verschillende
4.7 Graphical Module
70
pagina’s met herinneringen. Door op de ok-toets te drukken schakelt men over naar de zender van het geselecteerde programma. Telkens wanneer men dit scherm opstart en het dus focus verkrijgt, haalt het de lijst met herinneringen op en genereert het een menu met knoppen hiervoor. Er zijn speciale knoppen hiervoor ontwikkeld, de HTextButtonIndexedAutomatic-knoppen. Deze hebben naast hun index een boolean automatic en infoOn als extra gegevensvelden. Wanneer de boolean automatic op true staat verschijnt er een groen vinkje op het einde van de knop en wanneer deze op false staat een rood kruisje. De boolean infoOn bepaalt of er al dan niet een i op de knop verschijnt om aan te tonen dat men extra informatie kan opvragen. Het verwijderen van een knop leverde een eigenaardige fout op. Wanneer er een knop in de keyPressed() functie verwijderd werd, dan werd deze index toegekend aan de knop eronder. 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 SetupLanguageScreenklasse.
4.7 Graphical Module
71
SetupSkinScreen Daarnaast biedt de EPG ook de mogelijkheid om het uitzicht ervan volledig te personaliseren. De onderliggende implementatie hiervan gebeurt in de klasse SkinLayout (zie 4.7.3). De klasse SetupSkinScreen daarentegen verzorgt het grafisch gedeelte. De gebruiker wordt de mogelijkheid geboden om ofwel een bestaande skin te kiezen, ofwel er een zelf samen te stellen. Via de rode toets bladert men doorheen de verschillende mogelijke skins. Deze worden volledig automatisch en onmiddellijk tijdens het bladeren ingesteld, zodat men direct het resultaat ziet. Indien men de skin volledig zelf wil samenstellen, drukt men op de groene toets. De eerste kleurenpalet wordt geselecteerd. Via de pijltjestoetsen kiest men het gewenste kleur en bevestigt men door op de ok-toets te drukken. De gekozen kleur verschijnt als achtergrond bij de tekst boven het palet en men gaat over naar het volgende kleurenpalet. Dit moet men herhalen voor de vier kleuren. Ook de achtergrond kan men zelf kiezen. Door op de gele toets te drukken doorloopt men de mogelijke achtergrondafbeeldingen. Een afbeelding van dit scherm is terug te vinden in C.12. Voor het selecteren van een kleur is er een nieuwe component ontwikkeld: de HColorPalette. Deze component is opgebouwd uit een matrix van zestien HArrayTextButton-objecten, ingedeeld in vier rijen en vier kolommen. De HArrayTextButton is een subklasse van de HTextButton dewelke navigeerbaar is. De pijltjestoetsen worden via de functies setMove() en setFocusTraversal() naargelang de positie van de knop ingesteld om de verschillende kleuren te overlopen. Elke knop in de matrix heeft namelijk een specifieke achtergrondkleur. Wanneer de gebruiker op de ok-toets drukt, gaat men aan de hand van de rij- en kolomco¨ordinaat 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 ´e´en, vtm, canvas, ketnet, VT4, Ka2, . . . hard gecodeerd en wordt ervoor gezorgd dat deze telkens vooraan in de lijst komen. De gebruiker moet natuurlijk in staat zijn deze volgorde aan te passen, wat dit scherm mogelijk maakt. Het resultaat wordt daarna doorgegeven aan de hoofdmodule die ze bewaart op de configuratieserver. Deze klasse is omwille van tijdsgebrek niet ge¨ımplementeerd. Op het scherm verschijnt de
4.7 Graphical Module
72
boodschap dat deze feature enkel in een toekomstige versie beschikbaar zal zijn. SetupRCdataScreen Wanneer het terugkeerkanaal niet verloopt over een permanent verbinding, 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 initi¨ ele suggestievoorkeuren Via de rode toets gaat men over naar het WatchPreferencesScreen. Deze klasse levert de gebruiker de mogelijkheid om zijn voorkeuren in te geven. Dit proces is helemaal niet verplicht. Voor elk tijdslot en voor elk genre moet er een getal tussen 1 en 5 ingegeven worden. Bijgevolg duurt dit proces toch wel enkele minuten.
4.7 Graphical Module
73
Wanneer het gaat over de kans dat de gebruiker in een welbepaald tijdsslot naar tv kijkt, dan stelt de waarde 1 helemaal geen kans voor, de waarde 3 neutraal en de waarde 5 een heel grote kans. Indien de gebruiker z’n waardering over een bepaald genre gevraagd wordt, dan betekent 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 CircularScrollComponent 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 CircularFillScrollComponent 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 server 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 aanbevelingen. Ze worden gesorteerd zodanig dat de programma’s dat de gebruiker wellicht het liefst zal zien, bovenaan komen te staan. Deze waardering wordt in procent uitgedrukt. De legende toont opnieuw de reeds gekende mogelijkheden: het bekijken of het opnemen van het geselecteerde
4.7 Graphical Module
74
programma of een herinnering hiervoor instellen. Verder wordt er opnieuw gebladerd tussen de verschillende pagina’s via de pijltjes toetsen naar links en rechts en verschijnt de informatie over het programma telkens onderaan. Zoekscherm De gebruiker kan de volledige tv-gids doorzoeken naar een welbepaald programma. Hiervoor worden de zoekfuncties uit de opslageenheid gebruikt. Het zoekscherm is een heel handig hulpmiddel 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 HMultilineEntry. 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 pijltjestoetsen de types en subtypes overlopen en kiest er een uit door op de ok-toets te drukken. Deze wordt dan als kernwoord toegevoegd. Ditzelfde menu is ook in het categorieoverzicht terug te vinden, zie C.8 voor de afbeelding ervan. Er zijn twee verschillende methodes voorhanden, zoals besproken in 4.4.2. Men kan tussen deze methodes wisselen via de groene toets. Nadat men alles goed ingegeven heeft, drukt men op de rode toets om de zoekresultaten op te halen. De zoekresultaten worden gesorteerd volgens het aantal procent overeenkomst. Verder is dit scherm op een gelijkaardige manier opgebouwd als de resultaten op het suggestiescherm. Via de back-toets kan men terugkeren om nieuwe kernwoorden in te geven. Een afbeelding van dit scherm is terug te vinden in C.11. Categorieoverzicht In het categorieoverzicht is het mogelijk programma’s van een welbepaald genre op te vragen. Men start met een menu waarbij men het juiste genre selecteert door eerst het type en daarna het
4.7 Graphical Module
75
subtype te kiezen. Via de ok-toets bevestigt men z’n keuze. Aan de opslageenheid worden alle programma’s opgevraagd die voldoen aan dit genre. Naargelang het aantal resultaten worden er automatisch knoppen gecre¨eerd 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, dewelke 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 VoDserver. De server levert voor elk onderdeel een XML-bestand. Het parsen van deze XMLbestanden gebeurt in de importeermodule, meer bepaald in de klassen ImportVOD en ImportLiveEvents 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 opslageenheid 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 deze 1
ontwikkeld door Kristof Demeyere
4.7 Graphical Module
76
door naar de applicatie zelf. Deze locator wordt opnieuw in XML-formaat (zie 4.3.4 en A.4.2) verstuurd. Het parsen hiervan gebeurt echter in de VodScreen-klasse zelf. Van zodra de locator ontvangen is, schakelt de EPG over naar het opgevraagde item. Deze wordt vertoond in de VODPlayScreen. Dit scherm bevat twee componenten, namelijk VODKeysComponent 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 voeren. 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 MovieInformationScreenvenster 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 MovieInformationScreenklasse, die ze afbeeldt. Een afbeelding van dit scherm is terug te vinden in C.7. De filminformatie is opgebouwd als ´e´en 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
4.8
77
User Suggestion Module
4.8.1
Aanbevelingsalgoritmes
Soorten Er is momenteel reeds heel wat onderzoek naar personalisatie van applicaties verricht. Personalisatie 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 systemen. 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 systemen 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 onmiddellijk goede en betrouwbare resultaten levert zonder een lange leertijd.. Dit vergt natuurlijk wat inspanningen.
Daarnaast bestaan er ook algoritmes die voorgedefinieerde stereotypen bevatten (zie vb.
4.8 User Suggestion Module
78
[14] en [19]). Deze aanpak is gebaseerd op de vaststelling dat vaak mensen opgesplitst kunnen 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 financi¨ele 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 verbetering. In [5] bespreekt men een architectuur waarbij men verschillende soorten algoritmes bundelt om op die manier de voordelen te combineren tot ´e´en goed functionerend geheel. Dit gebeurt op een statische manier. Telkens leveren de drie eenheden (impliciet, expliciet en stereotypisch) 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 inhoudsgebaseerde algoritmes. • systeem Sommige technieken hebben nood aan actieve interactie, beschikbare metadata, initi¨ele opstartgegevens, . . . Deze zijn niet altijd in dezelfde mate beschikbaar. Afhankelijk hiervan moet opnieuw het juiste evenwicht tussen de verschillende algoritmes gevonden worden.
Deze EPG bundelt een aantal verschillende soorten algoritmes. Deze leveren elk apart een aantal suggesties. Op basis van hun eigen schatting naar de betrouwbaarheid (zie 4.8.2) van hun resultaten krijgen de ene aanbevelingen voorrang op de andere. Op die manier bekomen we een lichte vorm van dynamische samenwerking. De EPG richt vooral zijn pijlen op het
4.8 User Suggestion Module
79
zelflerend aspect. Televisie kijken is en blijft immers een passief gebeuren. Ze laat daarentegen wel toe het leerproces te versnellen door een volledig uitgewerkt profiel in te stellen. Maar ze laat de gebruiker hier volledig in vrij. Het opstellen van dit profiel kan op elk ogenblik gebeuren. Men hoeft deze gegevens niet per se in het begin in te voeren. Het systeem houdt automatisch rekening met de eerder opgeslagen en verwerkte informatie. Meerdere gebruikers Het tv-kijken is meestal een familiegebeuren. Het suggestiesysteem moet dus voor elk lid van het gezin goede aanbevelingen produceren. Ze moet dus als het ware de kijker identificeren om zijn of haar favoriete programma’s te zoeken zonder dat hij of zij zich moet aanmelden. Men zou dit aanmeldingsproces immers te vaak als een last zien. En wie moet er zich aanmelden wanneer men met meerdere personen naar tv kijkt? Het Family Interactive TV systeem (FIT, zie [14]) probeert deze doelstellingen in de mate van het mogelijke te realiseren. FIT bouwt een aantal groepen van stereotypes. Hiervoor moet de gebruiker drie stappen doorlopen: • het bepalen van de stereotype door het ingeven van je leeftijd en je job • een score aan elk genre geven • per tijdsslot ingeven wat de kans is dat je op dat moment tv kijkt Aan de hand van de huidig bekeken programma’s bepaalt FIT wie er naar tv kijkt, kiest de juiste groep en levert aan de hand daarvan de suggesties. Het zelflerend aspect is hier herleid tot het verwerken van feedback. Het algoritme levert een aantal suggesties en zet de drie belangrijkste bovenaan. Naargelang de keuze, wordt positieve of negatieve feedback terug verwerkt in het relevant profiel. In dit artikel linkt men de tijd aan een gebruiker en de gebruiker aan een aantal genres. Maar eenzelfde persoon zal ook een verschillend gedrag vertonen naargelang het tijdstip. In de vroege avond zal men bijvoorbeeld liever naar een nieuwsmagazine kijken en in de late avond naar een film. In deze EPG worden genres rechtstreeks gelinkt aan tijdssloten. In de late middag zullen wellicht eerder de kinderen naar kinder-en jeugdprogramma’s kijken en in de late avond gaan de volwassenen hoogstwaarschijnlijk naar een film kijken. Het registreren en analyseren van welke genres men op welke tijdsstippen bekijkt is dus voldoende. In het huidig systeem is er enkel
4.8 User Suggestion Module
80
onderscheid tussen een weekdag en het weekend gemaakt. Een dag wordt verder opgesplitst in tien tijdssloten.
4.8.2
Metadata
Een zelflerend systeem registreert de acties van de gebruikers, verwerkt ze en onthoudt ze. Maar welke metadata moet er verzameld worden? En hoe moet deze bewaard worden? Er zijn twee soorten programma’s die het systeem in rekening moet brengen. Enerzijds heb je deze die men op een heel regelmatige basis bekijkt en die dus goed gekend zijn. Anderzijds heb je de ongekende programma’s waarvan het suggestiesysteem vermoedt dat men deze wel zou smaken omdat ze gelijkaardig aan de veel bekeken programma’s zijn (zie [25]). Om ook deze laatste groep op te nemen, is het belangrijk dat het systeem bijhoudt welke genres er op welke tijdstippen vaak bekeken worden. Een genre is natuurlijk nogal breed. In [25] geven de auteurs een methode aan om specifieke metadata te verzamelen over de bekeken programma’s. Ze verwijderen alle betekenisloze woorden zoals de, van, over, in, . . . uit de beschrijving en geven elk van de overblijvende woorden een gewicht naargelang hun belangrijkheid. Op die manier bekomt men na een tijdje per genre een lijst van woorden die een positief en die een negatief effect hebben. Het algoritme toetst de beschrijving van een programma aan beide lijsten met woorden om hieruit te besluiten of de gebruiker dit programma al dan niet graag zal zien. De gegevens die men verzamelt kan men op verschillende manieren bewaren. Men kan bijvoorbeeld alle historische gegevens bijhouden (globaal), of men kan bijvoorbeeld enkel de registraties 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 maandenlang 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 gedeelte is echter wegens tijdsgebrek langs de serverzijde niet volledig uitgewerkt. Een aanbeveling in [5] bevat telkens een waarde die aangeeft hoe graag de gebruiker dit programma wellicht zal zien en hoe zeker het algoritme van zijn beslissing is. Dankzij deze laatste waarde kunnen de verschillende algoritmes op een dynamische manier samenwerken. Indien een algoritme niet de nodige gegevens bevat en bijgevolg helemaal niet zeker van zijn keuzes is, kan
4.8 User Suggestion Module
81
hij dit gemakkelijk aangeven zodat zijn verdiensten niet in rekening worden gebracht. Dit idee werd volledig overgenomen. Films hebben specifieke gegevens zoals acteurs, actrices en de regisseur. [27] beweert dat een acteur of actrice meestal een gelijkaardige rol speelt in een film, zodat de cast een belangrijke indicatie levert of men de film al dan niet graag zal zien. Beschouw bijvoorbeeld de acteurs Tom Cruise en Tom Hanks. Beide zijn enorm gerenomeerde acteurs en bijgevolg echte publiekstrekkers. 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 gewone jongen van een lager intelligentieniveau die een ongelofelijk leven leidt in Forest Gump, . . . Het suggestiesysteem uit deze EPG neemt bijgevolg ook de cast en de regisseur in rekening. Deze informatie is echter tijdsonafhankelijk en wordt dus algemeen opgeslagen.
4.8.3
Intern systeem
Architectuur Het suggestiesysteem bestaat uit drie grote delen. Deze worden aangestuurd door de UserSuggestionController. Deze controller implementeert de UserSuggestionInterface die de publieke functies gericht naar de hoofdmodule levert. Deze functies zijn: het opvragen van de aanbevelingen, het registreren van de suggestievoorkeuren en het registreren van een gebruikersactie. De architectuur van deze module is grotendeels gebaseerd op [2]. Ze is echter aangepast aan de noden van deze EPG. Het schema in D.9 biedt een vereenvoudigd overzicht, terwijl D.8 het volledig UML-schema weergeeft. Registratie
De registratiesubmodule ontvangt gebruikersacties en het ingegeven gebruikers-
profiel. Dit profiel kan zonder meer doorgegeven worden aan de LogSystem-klasse die ze omzet naar een XML-bestand en naar de server verstuurt. Het profiel bestaat hoofdzakelijk uit twee onderdelen: • per dag en per tijdsslot de kans dat de gebruiker op dat moment tv kijkt • per genre een score dat de waardering voor dit genre bepaalt
4.8 User Suggestion Module
82
De overige gegevens worden via het zelflerend systeem bekomen. De gebruikersacties worden toegevoegd aan een lijst. Daarna onderzoekt de UserActionsCollector -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 verwerken, 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 ´e´en keer op te vragen en te verwerken. Het XML-bestand kan immers nogal groot uitvallen (zie A.3.4). Deze specifieke aanvraag wordt aan de hand van een XML-bestand (zie A.3.3) doorgegeven aan de server. Per item kan men aangeven of men al dan niet alle informatie erover wenst te verkrijgen. Men kan bijvoorbeeld zoals in A.3.3 aangeven dat men niet alle informatie over de subtypes van het type
4.8 User Suggestion Module
83
12 wilt kennen, maar enkel over de subtypes 0, 1 en 2. De huidige algoritmes gebruiken enkel de gegevens uit het huidig tijdsslot. Bijgevolg moet het systeem enkel deze gegevens opvragen. Dit levert een enorme reductie (tot twintig maal!) aan gegevens die getransporteerd en verwerkt moeten worden. Het parsen van de ontvangen gegevens gebeurt in de client connection module die een USDataObject aflevert. De USData-klasse bevat ook een verwijzing naar de EPGdata module opdat de algoritmes ook toegang hebben tot de beschikbare programma’s. Aanbevelingen
Het hoofddoel van het suggestiesysteem is natuurlijk het afleveren van een
aantal aanbevelingen. De RecommenderCollector -klasse bevat hiervoor een aantal verschillende algoritmes en stuurt deze aan. Elk van deze algoritmes heeft een referentie naar de USDataklasse 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 ´e´en soort algoritme. Hierdoor is de uitbreidbaarheid van dit systeem enorm belangrijk. Dit wordt zoals hierboven aangegeven, gerealiseerd dankzij de interne architectuur en de USRecommenderAlgorithmInterface. Momenteel is er slechts ´e´en algoritme ge¨ımplementeerd. Deze illustreert de werking van deze module. USAFavSubtypes Dit algoritme vraagt eerst de twee meest bekeken programmatypes in het huidig tijdsslot op. Per gekozen type bepaalt het de twee populairste subtypes. Zo bekomt men
4.8 User Suggestion Module
84
vier combinaties. Men neemt de twee beste en zoekt de programma’s die aan dit genre voldoen. Wanneer de opslageenheid er in totaal minder dan 10 gevonden heeft, zoekt hij verder naar de overige twee combinaties. Per aanbeveling wordt via specifieke functies de betrouwbaarheid en de appreciatie bepaald en de resultaten gebundeld tot een rij van Recommendation-objecten. Dit is een simpel, maar effici¨ent 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 programma’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 exponenti¨ele 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-commerci¨ele 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 tekstbestanden 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
5.1.1
86
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 bestempeld worden1 .
5.1.2
Werking & mogelijkheden
Systeem De movie information server is geschreven in de programmeertaal C en draait op een UNIXgebaseerd 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 • Genres 1
zie http://www.imdb.com/database statistics
5.1 Movie Information Server
87
• De gebruikerswaardering en distributiegegevens hiervan • Regisseur • Volledige cast – Naam van de acteur/actrice – Naam van het personage in de film • Kort inhoud Data De databank bestaat dus eigenlijk uit bestanden die onleesbare bytegegevens bevatten. Deze worden automatisch gegenereerd uit de tekstbestanden die men van de FTP-server kan downloaden. 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 gemaakte tools te vinden die deze bestanden omzetten naar gegevens in bijvoorbeeld een MySQLdatabank.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 filminformatie, 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 functionaliteit 2
bv. http://www.jmdb.de/index.html
5.1 Movie Information Server
88
om gegevens over gelijk welke film op te vragen. Bijgevolg zullen de Xlets momenteel telkens dezelfde films opvragen, namelijk de films die deze dag op tv te zien zijn. De externe cache kan dus de prestaties van het systeem heel veel verbeteren en het heel wat schaalbaarder maken. Wanneer ik deze server thuis op mijn eigen computer draai (Knoppix besturingssysteem) werkt alles perfect. Eerlijkheidshalve moet ik eraan toevoegen dat eenmaal de server ge¨ınstalleerd werd op de computer in het testlabo(Ubuntu besturingssysteem), het cachegedeelte soms raar deed. Deze gaf af en toe verkeerde informatie terug. Ik kon echter geen fout terugvinden in de code en heb de versie in het testlabo laten werken zonder externe cache om er zeker van te zijn dat deze altijd de juiste informatie teruggeeft.
5.1.3
Installatie
De databankbestanden kunnen via FTP opgehaald worden : • ftp.fu-berlin.de (Duitsland) • ftp.funet.fi (Finland) • ftp.sunet.se (Zweden) Na decompressie worden de list-files geplaatst in het mapje lists”. ” Via het commando make databases” wordt de volledige databank gegenereerd. ” Via het commando make install” wordt het volledige systeem ge¨ınstalleerd. ” Om de server mee te integreren zijn de volgende commando’s nodig: • gcc -c msFunctions.c -o msFunctions.o • gcc -c movieServer.c -o movieServer.o • gcc -O -o movieServer movieServer.o msFunctions.o dbutils.o titlesearch.o years.o biographies.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
5.1.4
89
Uitbreidingen
Momenteel is het enkel mogelijk om de basisinformatie op te halen. De databank bevat echter nog veel meer informatie, namelijk biografie¨en, 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 geheugen. 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 behoort. 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 aanvraag 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 waardering 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
5.2.2
91
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 respectievelijk. 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 verschillende 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 programma’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 categoriescherm 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 ´e´en 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 hiervan 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 functionaliteiten werden gebundeld in verschillende modules, elk met hun specifieke taak en verantwoordelijkheid. Het grafisch gedeelte staat hierdoor volledig los van de rest. Bijgevolg 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 interactiekanaal moet aantrekken. Dit systeem bevat bovendien een priority scheduler. Belangrijke aanvragen zullen hierdoor steeds voorrang krijgen.
6.2 Algemene uitbreidingen en integraties
6.2
95
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 beschikt 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 informatie 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 mogelijke 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 VoDserver. De gateway plaatst de nodige films op de broadcast stream en levert de juiste
6.2 Algemene uitbreidingen en integraties
96
locators aan de VoD-server die ze verder doorgeeft aan de juiste applicatie.
Sportportaal David Plets ontwikkelde een applicatie die de sportliefhebber verwent met alle mogelijke informatie die hij maar kan bedenken. Dankzij zijn informatiebalken is het mogelijk de gebruiker op de hoogte te houden van de lopende wedstrijden terwijl hij naar andere programma’s kijkt. Het instellen en aansturen van deze informatiebalken zou men vanuit de EPG kunnen regelen. We kunnen hier nog verder in gaan door beide applicaties volledig aan elkaar te koppelen. Wanneer men informatie over de wedstrijden, de spelers, het klassement enzovoorts wil, dan kan hij vanuit de EPG het sportportaal opstarten.
eID De integratie van de elektronische identiteitskaart (eID1 ) biedt mogelijkheden bij het bestellen van VoD-items. Ze zorgt voor een veilige en eenvoudige identificatie van de gebruiker. 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 automatisch 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 identificatie 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 familieprofiel 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, zangwedstrijden en dergelijke kijkt men liever samen met vrienden en kenissen dan alleen. Een 1
De thesis van Joost Cammaert handelt over de integratie van de eID binnen het MHP-platform.
6.2 Algemene uitbreidingen en integraties
97
instant messenger2 kan dit gevoel wat nabootsen door korte tekstberichtjes zoals Heb je ” die goal gezien! Prachtig h´e!”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 luidspreker 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 contactpersonen.
2
Kevin Hoekman ontwikkelde voor zijn thesis een instant messenger voor het MHP-platform
XML-BESTANDEN
Bijlage A
XML-bestanden A.1
Filminformatie
<movie> EuroTripComedyAdventure2004 <userrating> 00000121016.1Jeff SchafferScott Mechlowicz <moviename>Scott Thomas
98
A.1 Filminformatie
99
Jacob Pitts <moviename>Cooper Harris Kristin Kreuk <moviename>Fiona Cathy Meils <moviename>Mrs. Thomas Nial Iskhakov <moviename>Bert Michelle Trachtenberg <moviename>Jenny Travis Wester <moviename>Jamie Matt Damon <moviename>Donny Jessica Boehrs <moviename>Mieke
A.2 Configuratiegegevens
100
Fred Armisen <moviename>Creepy Italian Guy 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.
Jongeren reizen doorheen Europa op zoek naar Mieke en beleven hilarische momenten... eurotrip.PNG <subtitle> <summary> <start> <stop> <price>3.0 4,1 <username> <password> <enclosure id=”0” url=”rmi://192.168.30.2:1099/Streamer” exclusive=”true”> EurotripD:/users/Stijn/vod/eurotrip.wmvAmerican Pie (1999) <description> 4 Tienerjongens sluiten een pact om hun maagdelijkheid te verliezen vooraleer het afstudeerbal... ampie.PNG <subtitle> <summary> <start> <stop> <price>3.0
A.4 VoD server
114
4 <username> <password> <enclosure id=”0” url=”rmi://192.168.30.2:1099/Streamer” exclusive=”true”> American PieD:/users/Stijn/vod/ampie.wmv
A.4.2
VoD- & LE-informatie
VoD 0Eurotrip (2004) <description>Een groepje jongeren trekt doorheen Europa en beleeft hilarische momenten. . . eurotrip.png4,1 <price>2.99 1Dot the I (2003) <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 dotthei.png7,19 <price>2.99
...
LE 0Rock Werchter (2006) <description>Rock festival werchter.png14 <price>3.99 ...
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
B.2.2
117
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
B.2.5
118
CHANNELTABLE
CHANNELID
CHANNELNAME
0
´e´en
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
B.3
119
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
B.3.3
120
CHANNELGLOBALTABLE
USERID
DAY
TOD
CHANNEL
COUNTER
0
0
0
´e´en
2
0
1
0
´e´en
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
C.2
122
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
C.4
123
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
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.
124
C.7 Categorieoverzicht
C.7
125
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
C.8
126
Suggesties
Figuur C.10: Ingeven van de suggestievoorkeuren
C.9
Zoeken naar programma’s
Figuur C.11: De zoekresultaten.
C.10 Instellingen
C.10
127
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
D.3
130
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
D.5
User suggestion module
Figuur D.8: De volledige user suggestion module.
Figuur D.9: Een schematisch overzicht van de user suggestion module.
132
D.6 Graphical module
D.6
133
Graphical module
Figuur D.10: De grafische module, elke schermklasse bevat een referentie naar de GraphicalController. 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, Universit`a 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: Improving Ease-of-Use, Trust and Accuracy of a TV Show Recommender”. USA, Philips Research USA. [5] DIFINO, A., NEGRO, B. & CHIAROTTO, A. (2003). A Multi-Agent System for a Personalized Electronic Program Guide. Italy, Telecom Italia Lab. [6] DVB PROJECT (2005). Digital Recording Extension to Globally Executable MHP (GEM), DVB Document A088 Rev.1 [7] DVB PROJECT (2005). PVR/PDR Extension to the Multimedia Home Platform, DVB Document A087. [8] EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE (ETSI) (2000). Digital Video Broadcasting (DVB) - Implementation guidelines for the use of Video and Audio Coding in Broadcasting Applications based on the MPEG-2 Transport Stream; MPEG-2 Implementation guidelines, Doc.nr.: ETSI TR 101 154 V1.4.1
BIBLIOGRAFIE
136
[9] EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE (ETSI) (2002). Digital Video Broadcasting (DVB) - Multimedia Home Platform (MHP) Specification 1.0.2, Doc.nr.: TS 101 812 v1.2.1. [10] EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE (ETSI) (2004). Digital Video Broadcasting (DVB) - Guidelines on implementation and usage of Service Information (SI), Doc.nr.: ETSI TR 101 211 V1.6.1 [11] EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE (ETSI) (2004). Digital Video Broadcasting (DVB) - Specification for Service Information (SI) in DVB systems, Doc.nr.: EN 300468 v1.6.1 [12] EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE (ETSI) (2005). Digital Video Broadcasting (DVB) - Multimedia Home Platform (MHP) Specification 1.1.1, Doc.nr.: TS 102 812 V1.2.1 ¨ ¨ [13] FOTSCHL, H-P. & PLOSCH, R. Interactive Applications for the Multimedia Home Platform. Austria, Sony NetServices GmbH [14] GOREN-BAR, D. & GLINANSKY, O. (2002). Family Stereotyping - A Model to Filter TV Programs for Multiple Viewers, Israel, Department of Information Systems Engineering, Ben-Gurion University of the Negev. [15] IMDb, The Internet Movie Database (IMDb), http://www.imdb.com [16] IRT (2005). MHP knowledge database. http://www.mhp-knowledgebase.org [17] JAVA
(1998).
JMF
specification
v1.0,
http://java.sun.com/products/
java-media/jmf/1.0/index.html, Sun Microsystems Inc [18] JAVA (2002). Java Technology in Digital TV, http://java.sun.com/products/ javatv/index.html, Sun Microsystems Inc [19] KURAPATI, K. & GUTTA, S. (2002). TV Personalization through Stereotypes. USA, Philips Research USA. [20] MHP (2003). Digital Video Broadcasting Multimedia Home Platform. http://www. mhp.org/mhp technology/mhp profiles/ [21] MORRIS, S. (2004). Interactive TV WEB, Your choice of MHP, OCAP and JavaTV Information. http://www.interactivetvweb.org [22] MORRIS, S. & SMITH-CHAIGNEAU, A. (2005). Interactive TV Standards: A guide to MHP, OCAP and JavaTV. Burlington, MA: Focal Press, 585p.
BIBLIOGRAFIE
137
[23] PAWLAN, M. (2005). Introduction to Digital TV Applications Programming. http://java.sun.com/developer/technicalArticles/javatv/apiintro/, Sun Microsystems Inc. [24] SCHWALB, E.M. (2003). iTV Handbook: Technologies and Standards. New Jersey(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). Strategies: 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.
