Overview

This section contains architectural documents giving an overview of the complete MediaPortal 2 system. The concepts are more or less valid, but some system components are exchanged and some jobs are done in another way. The overview pictures don't reflect the current system state any more.

Content Deprecated

Albert has deprecated this page or content because it is no longer relevant, but has been reatined for historical reference. The concepts are more or less valid, but some system components are exchanged and some jobs are done in another way. The overview pictures don't reflect the current system state any more

Installation scenarios and application parts

The MediaPortal 2 system is designed to support mainly two installation scenarios: The singleseat scenario and the multiseat scenario. A third scenario, the on-demand scenario, is supported to, but this scenario isn't designed to be a main usage scenario; its just a fallback if no MP2 server is available for the client.

To achieve all those configurations, the overall architecture divides the system into two main applications: The MP2 server and the MP2 client. The MediaPortal 2 client provides the user interface and will be started on demand, while the MediaPortal 2 server will typically run as a long-term running application, for example started as a system service.

The installation directory for both the singleseat and the multiseat scenario will in each case include both applications, so each of the applications could be started on demand. The inter-process communication between the application parts, either local or over network, is done via the UPnP protocol, while physical media transfer between the applications uses the SMB protocol. The installation scenarios are described more in detail from the users point of view in the Requirements document.

Overview Image

Call structure

MP2 System feature matrix

Shows a mapping of features to the MediaPortal 2 Client and Server application parts. Coloured cells signify that the feature is present, white cells mean the feature isn't present.

Distribution of tasks

Shows a table of use cases mapped to the necessary application parts to accomplish them.

MP2 Server

Responsibility and Distinction

The MediaPortal server is the central application in an MP2 system. It is responsible for managing the MediaLibrary, its media importers and most of the media which should be made accessible to the MediaPortal system. It also will handle all media access of the outside world. At runtime, the server will run on the machine where (most of the) media files are located or locally accessible by network shares, where all (or most) of the TV cards are installed and where typically the database server will run to host the database for the MediaLibrary. The MP server should run as system service on the MP server machine.

The server application of an MP2 system doesn't provide an own GUI; it will be managed and configured exclusively by MP clients and external configuration application(s).

Internal Structure

• MediaManager (master)
  • MediaLibrary (master)
  • MediaProviders (provide access to all locally accessible media and to media located at (remote) MP clients, used by importers)
  • MetadataExtractors (used to provide metadata for special media types)
  • Importer (uses MetadataExtractors to get metadata from media provided by all MediaProviders)
  • SMB Server (provides access to locally accessible media files)
  • UPnP mediaserver, provides access to local accessible media for the outside world (i.e. MP clients), furthermore provides a communication interface for MP clients

MP2 Client

Responsibility and Distinction

The MediaPortal client is the main frontend for the MP2 system. It provides the MediaPortal GUI, local media access, access to MP server media and the ability to access the MP server's MediaLibrary. The MP client application will be started on demand and will typically, but not necessarily, be connected to an MP server. In a singleseat installation, the client will run at the same machine as the server, in a multiseat installation, the client will run at another machine, typically connected by a fast (100 MBit/1 GBit) TCP/IP network of version 4 or 6.

Internal Structure

• MediaManager (slave)
  • Connector to master ML (UPnP control point)
  • MediaProviders (provide access to all locally accessible media and to media located at (remote) MP clients, used by importers)
  • MetadataExtractors (used to provide metadata for special media types)
  • SMB Server (provides access to locally accessible media files)
  • UPnP mediaserver provides access to local accessible media for the outside world (i.e. MP clients), furthermore provides a communication interface for MP clients
• SkinEngine/GUI
  • GUI Models (provide screens to be displayed by the GUI)
• Players (play local and remote media)
  • UPnP mediaserver to be controlled by UPnP controllers

Components

MediaManager

The MediaManager component is responsible for MediaLibrary (DB) and media access and communication to the outside world. The MediaManager can be thought of as the main communication component which is responsible for the exposal of all central MediaCenter functions to other local components and for the interconnection of the distributed system. Other local components will access the central MediaCenter functionality over the MediaManager's interface, which will delegate all jobs to its sub-components or to remote components.

Local Responsibilities

Under local responsibilities, we subsume all jobs the MediaManager will expose to the local system. Each of those responsibilities will be found in a set of methods, properties and events in the MediaManager's main interface. The main local responsibilities are:

• Providing access to the MediaLibrary
• Providing a logical view of all known media in the system
• Maintaining/updating the MediaLibrary
• Providing physical access to all media (local/remote)
• Managing MetadataExtractors, MediaProviders and Importers

Both the server (master) MediaLibrary and the client (slave) MediaLibrary have to provide all those functions to the local application. Depending if we are looking at the master or slave MM, some of its sub-components will work differently (i.e. they will do calls to local sub-components or calls to remote components). I’ll describe the sub-components in the next sections.

Responsibilities for the exposal of functions to the outside world

Under those responsibilities for the outside world, we subsume functions, the MediaManager will provide for other machines, either remote MP applications or third-party software.

• Exposing physical access to all local media (via SMB server)
• Providing an interface to query local media (via UPnP)

MediaLibrary

The MediaLibrary is a component which basically consists of an SQL database holding a collection of all media known in the system. The media can be located at the local HDD, at remote network shares, in the internet, on DVDs/BlueRay discs or other removable devices or somewhere else.

The MediaLibrary database will be available on the MP server. MP clients don't have an own MediaLibrary database; MP clients will use the server's MediaLibrary via their Server ML Connector. The MediaLibrary contains a logical directory of all accessible media in the whole system. It stores all kinds of metadata. The data pool contains local accessible media on the server as well as media accessible via all contributing MP clients. It provides an interface to extend its media attributes to be used by MetadataExtractors.

MediaProviders

MediaProviders provide a common interface to access physical media files from all kinds of storage. The MediaProvider for the local HDD is very simple, while other MediaProviders like the remote SMB provider might be more complex (because it sometimes will have to mount a network drive). The TV engine is also a MediaProvider which provides a single media file for each TV card, organized as a ring buffer. The TV paper, for example, can also be realized as a combination of an HTTP MediaProvider and an appropriate MetadataExtractor, which grabs TV content from an internet resource.

MetadataExtractors

MetadataExtractors are responsible – well – for extracting metadata from physical media files. MEs work on media provided by MediaProviders. MetadataExtractors provide a "logical" media access, as they (mostly) don't care about where the physical media files are originally located. They define the type and format of metadata they provide – the MediaManager will add appropriate attributes to the MediaLibrary's data tables, if needed.

Importer

In the MP2 system, there is no need any more to have different importers for different data types. There is one importer which can cope with all sensible combinations of MediaProviders and MediaExtractors. The importer is responsible for applying the appropriate MetadataExtractors to media which need to be imported.

SMB Server

The SMB server is responsible for providing access to any media which is provided by any MediaProvider to the outside world (except the Remote SMB Provider for accessing remote MP clients). The SMB server will also provide a user authorization – It will only provide access to media for authorized users.

UPnP mediaserver

The UPnP mediaserver exposes the content directory functionality to the outside world. This functionality will be available in MP clients and MP servers, to provide a standard UPnP mediaserver. All physical remote media transfer in the MediaPortal system will be done by using the SMB protocol.

UPnP mediarenderer

The UPnP mediarenderer exposes the current player's control to the local network. This function is useful to control the MP client's player via UPnP remote controls.

UPnP Control Point

The UPnP control point is responsible to remotely access the MP server's UPnP actions.

SkinEngine/GUI

The Skin Engine is responsible to display screen files which are provided by plugins. The data the screens are displaying is provided by locally installed model instances.

Models

to be continued

Players

Players are responsible to render media content which was made accessible by the local MediaManager, this might be local media like local DVD, or remote media from a media server. The current player progress and some player controls will be made available for external UPnP control points by the UPnP mediaserver

Resources

See the documents in the file:  http://upnp.org/resources/upnpresources.zip for a set of descriptions and specifications of the UPnP AV architecture and its components.