MediaPortal

Inhaltsverzeichnis

Einleitung

Was ist das MediaPortal ?

Das MediaPortal ist eine - unter der Programmiersprache Python entwickelte - Zusatzsoftware (Plugin) für digitale, auf Linux basierende TV/Radio-Empfangsgeräte (DVB-Receiver/Settopboxen), auf denen die Benutzeroberfläche Enigma2 (E2) residiert. Somit läuft es u.a. auf fast allen Dreamboxen, sowie auf VU+ Boxen. Das MediaPortal ist eine Sammlung von Plugin-Modulen, die innerhalb einer - von den Programmierern stets weiterentwickelten - Plugin-Oberfläche laufen. Die internen Plugin-Module geben Inhalte von Mediatheken (beispielsweise ARD/ZDF/RTL/N24 usw.) wieder. Auch Module zu Streaming-Plattformen mit rechtlich nicht eindeutig geklärten Inhalten (hier Grauzone genannt), sowie Erotik-Angebote verschiedener Anbieter sind hier implementiert. Aber sowohl die Grauzonen- als auch die Erotik-Module sind per Voreinstellung abgeschaltet, und müssen vom User innerhalb des PIN-geschützten Setup-Menüs selber freigeschaltet werden, da sich die Programmierer von der Verwendung distanzieren möchten, und die Verantwortung zur Benutzung damit dem User übergeben. Für Erotik-Angebote gibt es zusätzlich noch Schutz-Funktionen. Zum Einen kann man den Aufruf jedes Erotik.-Moduls mit einer zusätzlichen PIN-Abfrage schützen, sowie kann man zum Anderen mit einer "Panikfunktion" bei überraschendem Besuch (zB. Kinder, oder Schwiegermutter) das Vorhandensein der Erotik-Module auch mit der Info-Taste im Haupt-Menü ausblenden, bzw. verstecken, sodass niemand von der Existenz weiß. Um sie wieder anzeigen zu lassen, wird nach erneutem Drücken der Info-Taste erneut nach der PIN gefragt.

Historisches zu Enigma2/Linux

1996 (zwei Jahre nach der Festlegung des Standards DVB für Digitale Übertragungswege von TV+Radio), lieferte der erste große DVB-Provider DF1 im deutschsprachigen Raum die DBox als Settopbox für seine kostenpflichtigen Angebote aus. Die DBox wurde ausschließlich von Nokia hergestellt, und die proprietäre Benutzeroberfläche (GUI) lief in einer Java-Umgebung. Die Bootzeiten waren sehr lang, und die Umschaltzeiten dauerten teilweise 5 Sekunden.

Anmerkung: Einige Jahre später wurde der Bootloader gehackt, und ein findiger Programmierer ("Dr. Overflow") hat die Sprungmarken auf einen Bereich gelenkt, an dem er eigene Sourcen laufen lassen konnte (die Firmware hieß DVB2000). Zu großen Teilen in Assembler geschrieben, waren die Bootzeiten erstaunlich und die Umschaltzeiten teilweise unter einer Sekunde. Eine Besonderheit von DVB2000 war zudem, dass die SCSI-Schnittstelle der DBox - gegenüber der Original-Firmware - hier unterstützt wurde, um Sendungen auf einer SCSI-Festplatte aufzeichnen zu können.

Drei Jahre später (1999) wurde DF1 in "Premiere World" umbenannt. Der - zuvor noch Analog - ausstrahlende Pay-TV Anbieter "premiere" (deutscher Ableger des schweizer Teleclub) war bereits bei der Gründung von DF1 beteiligt (DF1 ging aus der Kirch-Gruppe hervor; Leo Kirch war ein Filmehändler, und handelte auch mit Lizenzen zur Übertragung von Sport-Events). Weitere drei Jahre später, wurde 2002 "Premiere Word" wieder in "Premiere" umbenannt.
In späteren original Firmware-Versionen der DBox waren Boot- und Umschaltzeiten auch akzeptabel. Doch nun wurde an Premiere-Kunden auch die DBox2 ausgeliefert. Hersteller waren Nokia, Sagem und Phillips. Auch hier wurde nach einer Weile der Bootloader gehackt ("tmbinc"), und an der Sprungmarke wurde diesmal ein abgespeckter Linuxkernel angesetzt, der dann ein ebenso deutlich abgespecktes Linux hinterher lud. Als GUI entstanden Enigma (Anfangs EliteDVB), Neutrino und LCARS, im extra dafür gegründeten OpenSource-Projekt Tuxbox. Damals wurde hauptsächlich in C und C++ programmiert. Auch hier war das Aufzeichnen von Sendungen - diesmal über die LAN-Schnittstelle der Dbox2, die keine SCSI-Schnittstelle mehr an Bord hatte - ein tolles Extra-Feature, dass auch weiterhin nicht durch die offizielle Firmware unterstützt wurde. Linux in Settopboxen war plötzlich sehr beliebt, und DreamMultiMedia brachte als erste Firma mit der DMM7000 eine reine SAT-Settopbox mit Linux als Betriebssystem auf den Markt. Weitere Firmen folgten später.

Python hält Einzug in Linux basierende DVB-Receiver

Als Enigma2 an den Start ging, wurde in Python programmiert. Grund dafür war unter Anderem, dass zuvor zum Compilieren von ausführbaren Dateien für die Receiver, auf dem PC ein Cross-Compiler bemüht werden musste. Denn auch heute noch, haben die meisten Receiver keine x86-Prozessoren. Da die Speicherkapazität der Flash-ROMs - in denen das Betriebssystem Linux und die ganzen Apps/GUIs reinpassen müssen - im Laufe der Jahre zunahm, dachte man darüber nach, ob man nicht den Compiler direkt in die Box packen kann. Dann bräuchte man beim Programmieren auf dem PC nur noch einen normalen ASCII-Editor benutzen, die Sourcen in die Flash-ROMs der Box hochladen, und die Box würde selber compilieren; Cross-Compiler für Entwickler gespart. Hierfür hatte man sich für Python entschieden. Sowohl Enigma2, als auch sämtliche Plugins - die unter Enigma2 laufen - sind idR. ebenfalls in Python programmiert. So auch das MediaPortal.

Enigma2 nicht gleich Enigma2

Ein wenig kompliziert für den End-User ist, dass Enigma2 nicht auf allen Boxen gleich ist. Aufgrund von Streitigkeiten einiger Hersteller, hat die Firma DreamMultiMedia (Hersteller von Dreamboxen, und Pionier bei Linux-Settopboxen) große Teile der Sourcen von Enigma2 von OpenSource auf ClosedSource umgestellt. Somit fehlen Funktionen in Nicht-Dreamboxen, die von dem Tag der Umstellung an, für Dreamboxen hinzu kamen. Beispielsweise das Skinnen von Scrollbars.

Was bietet das MediaPortal?

Quantität

Es gibt vier Hauptkategorien (mit dem Stand von März 2014 zum MediaPortal v5.1.2.):

- Mediatheken ( ~ 30 Module )
- Grauzone ( ~ 20 Module)
- Fun/Music/Sport ( ~ 60 Module)
- Porn ( ~ 40 Module)

Qualität

Die Qualität der Module im MediaPortal ist stark von äußeren Einflüssen abhängig. Natürlich können auch einem MediaPortal-Programmierer Fehler unterlaufen. Aber grundsätzlich gibt kein Modul-Programmierer sein Modul zu einer Streaming-Plattform frei, ohne es zuvor selber ordentlich geprüft zu haben!
Wenn ein Modul plötzlich nicht mehr funktionieren sollte, wurde meist nicht "schlampig programmiert", sondern irgendein Detail auf Seiten des Streaming-Portals wurde geändert, doch die Sourcen fundieren noch auf den vorigen Details. Sollte so etwas vorkommen, dann ist es durchaus erwünscht, dies in einem der offiziellen Threads zum MediaPortal zu verkünden. Denn schließlich verwendet ein Modul-Programmierer nicht täglich seine eigenen Module, um zu prüfen, dass sie auch noch stets laufen. Hier ist man natürlich auf die Zuarbeit von Usern angewiesen.

Doch bevor ein User im "offiziellen Thread" zum MediaPortal die Nicht-Funktion eines Moduls postet, sollte er zuvor die Funktionen noch an seinem PC im Browser gegen-prüfen. Allerdings wird es nun leider etwas komplizierter:
Denn sollte es auch auf dem PC nicht laufen, so kann dem Media-Portal zunächst immer noch nicht qualitativ eine "Schuld" zugewiesen werden, denn die vermisste Funktionalität könnte auch...

a) an Änderungen am Streaming-Portal Anbieter liegen, oder
b) an individueller Fehlkonfiguration im LAN-Umfeld, oder
c) an Fehlern nach einer individuellen Änderung an *irgendeiner* Komponente im Receiver (zB. Firmware-Update), oder
d) an temporären, wie auch an grundsätzlichen Änderungen beim Internet-Provider (dann läuft es auch im Browser am PC nicht)
e) oder oder oder...

Daher ist es sehr wichtig für die Programmierer des MediaPortals, zu wissen, dass all' diese Faktoren bereits vom User beachtet wurden, bevor er einen ernstzunehmenden "Bug-Report" postet!

Sollte sich später zB. b) oder c) als Fehlerursache eines reportenden Users heraustellen, konnte weder die Community, als auch ein Programmierer etwas dabei hinzu lernen.
Man sollte also als User abwägen, ob man ausreichend getestet hat, bevor man im offiziellen MediaPortal-Thread einen Bug-Report postet. Und nur wenn man sich unsicher ist, sollte man besser den "MediaPortal HILFE-Thread" nutzen. Der Hilfe-Thread ist aber kein Abfall-Eimer für alles, was nicht im offiziellen Thread besprochen werden sollte. Auch hier geht man davon aus, dass zuvor ordentlich getestet wurde. Nehmt Euch also die Mühe, und testet ordentlich, bevor Ihr postet!!!!

Streaming-Protokolle RTMP/HTTP

Streaming-Portale können ihre Filme/Clips (die meist als .mp4 oder .flv vorliegen) mit unterschiedlichen Streaming-Protokollen an die User verbreiten. Das liegt nicht im Einflussbereich des MediaPortals, sondern des Anbieters. Manche bieten ausschlisslich HTTP an, manche ausschliesslich RTMP, und manche beides gleichzeitig (zB. das ZDF kann beides). Die Module des MediaPortals bevorzugen grundsätzlich RTMP, sofern ein Anbieter dieses anbietet. Sollte RTMP nicht angeboten werden, dann bekommt man als MediaPortal-User nicht mit, das im Hintergrund HTTP werkelt...

Wie funktionieren die Module des MediaPortals technisch?

Die HTML-Seiten eines Streaming-Portal Anbieters beinhalten diverse Metadaten zu den Medieninhalten (Länge, Handlung, Anzahl an Aufrufen, uvm.), sowie auch die Links zu den Clips. Die Module des MediaPortals filtern stets die benötigten HTML-Tags mittels RegEx aus, und ignorieren den Rest der HTML-Seiten. Damit entfällt die Notwendigkeit von Adobe Flash (o.ä.) auf der Settopbox, und der rechenintensive Seitenaufbau eines Web-Browsers entfällt ebenso. Benötigt werden nur die Metadaten, sowie der Link zu den eigentlichen Mediainhalten. Diese werden - je nach Anbieter - entweder über das HTTP-Protokoll, oder über das RTMP-Protokoll an die User gestreamt. Welches Protokoll verwendet werden kann, muss ein Programmierer für ein MediaPortal-Modul zunächst herausbekommen, und programmiert dementsprechend. Die Modul-Programmierer des MediaPortals bevorzugen RTMP, sofern vom Anbieter unterstützt.

Was ist RTMP?

RTMP ist ein Protokoll zum Streaming von Mediainhalten. Das Internet besteht nämlich nicht nur aus URLs wie "http://...". Es gibt es auch andere Aufrufe, wie "rtmp://...". Hierbei wird statt HTTP das Protokoll RTMP zwischen Server und Client vereinbart, bevor Daten fließen. Die genaue URL für RTMP ist meist nicht im Klartext in den HTML-Seiten zu entnehmen, kann aber aus diversen, zuvor gefilterten Tags im Modul zusammengesetzt werden. Sobald ein winziges Detail Seitens des Anbieters geändert wird, kann das im MediaPortal zum Nicht-Funktionieren führen. Dann müssen die User auf ein Update des betroffenen Moduls im MediaPortal warten.

Was ist RTMP-Dump?

RTMP-Dump ist eine Funktion, die nur dann wirksam wird, wenn folgende Vorraussetzungen gegeben sind:

- RTMP-Dump funktioniert nur (!) bei Usern, die eine Festplatte in ihrem Receiver verbaut haben
- RTMP-Dump nutzt nämlich die Festplatte des Receivers, um einige Zeit Streaming-Daten zu puffern, bevor abgespielt wird!
- RTMP-Dump funktioniert nicht, bei Streaming-Dienstleistern, die nur HTTP-Streaming anbieten!

Was mache ich, wenn ich RTMP-Dump einstelle, und es passiert nichts?

Wenn man RTMP-Dump einstellt, und es passiert nichts, dann ist in den allermeisten Fällen der Grund, dass ein Portal lediglich HTTP als Protokoll anbietet.

Woher weiß man als User, dass RTMP-Dump nicht funktioniert?

Das weiß nur der Modul-Programmierer durch seine Recherchen während seiner Programmierarbeit. Der User wird darüber nicht informiert, denn er will ja nur einen laufenden Clip sehen.

HTTP-Dump

Nebs RTMP-Dump, gibt es auch HTTP-Dump im MediaPortal. Hier wird - analog zu RTMP-Dump - auf die Festplatte des Receivers gepuffert, bevor abgespielt wird. Die Angabe in Prozent, wieviel des Stream zwischengepuffert werden soll, bis der Player loslegt, kann auch hier angegeben werden. Aufgrund des Zusatz-Plugins "MediaInfo", dass ausschließlich HTTP-Streams unterstützt, wurde HTTP-Dump aus den meisten Modulen wieder ausgebaut.

Abrisse bei manchen Streaming-Portalen/Modulen

Immer wieder aktuelle Frage in den Threads zum MediaPortal - in vielen Foren - ist, dass beispielsweise die Streams der RTL-Group nach 1-2 Minuten stoppen. Betrifft idR. die VU+ Boxen. Bei den Dreamboxen läuft es meist ohne Abbrüche weiter. Dieses Problem ist vermutlich - wie unter 2222 beschrieben - ein reines VU+ Problem. Ansätze zur Behebung des Problems in VU+ Boxen ist, dass die MediaPortal-Programmierer eine Feature eingebaut haben, dass ein Stream - von der Abriss-Stelle ab - fortgeführt wird. Das funktioniert aber auch nur bei Streaming-Portalen, die dieses Feature unterstützen. Denn es gibt Portale, die auch händisches "Springen" nicht mögen. Bei jenen funktioniert es auch nicht.

Zusammenfassend kann man aber sagen, dass die betroffenen Portale meist in "Fun/Music/Sport" zu finden sind. Unter den Porn-Modulen sind eigentlich keine Fälle bekannt.

MediaInfo - Der stille Helfer (nur HTTP)

Es gibt ein Zusatzmodul - auch hier im Board zu finden - namens "MediaInfo", welches es erlaubt, MediaInhalte, die via HTTP gestreamt werden, auf Festplatte zu verbannen. RTMP funktioniert hier NICHT!

Im Grunde wird hier die Funktion von HTTP-Dump nachgebildet. Nur mit dem Unterschied, dass die MediaInhalte - gegenüber HTTP-Dump - auf der Festplatte liegen bleiben. Somit kann man zB. einen Spielfilm dauerhaft speichern. Andere Verwendung (die Grundidee von MediaInfo) wäre, ein Media-Event damit runter zu laden, und nach einigen Minuten zeitversetzt (durch PLAY im offiziellen MediaPlayer) anzuschauen, in der Hoffnung, dass hinten der Download nicht weiterhin langsamer bleibt, als der Kopf des Streams, der gerade angeschaut wird.

Möchte man mit MediaInfo einen Stream runterladen, dann fährt man zunächst den Stream an, und drückt - wenn er dann angelaufen ist - die Info-Taste. Hier muss man bei Bedarf (bei der ersten Nutzung) noch den Speicherort auf der Festplatte festlegen.
Hat man das alles zuvor bedacht, ist es eine gute Idee, den laufenden Stream im MediaPortal zu beenden, da sonst doppelt "runtergeladen" wird. Einmal in Echtzeit im MP, und einmal via MediaInfo... Wenn Download beednet, kann man auch Wochen später den Stream von dem voreingestellten Pfad aus ansehen, oder gar woanders hin kopieren, und dort auch auf einen optischen Datenträger brennen (o.ä.). Das ist allerdings nicht die Grundidee, von MediaInfo... Anfragen zu Problemen damit sind daher nicht erwünscht.

Nochmals als Hinweis: MediaInfo kann nicht mit RTMP-Streamings umgehen/agieren!!!. Nur HTTP-Streamings werden unterstützt!

Installation/Auto-Update/Image

Hier muss man ein wenig aufpassen...

Es gibt das MP zum Download als .ipk Datei. Dieses lädt man via FTP in den /tmp Ordner hoch, und schiebt den Install-Prozess händisch an.

Das MediaPortal ist aber auch via Feed in vielen Images bereits implementiert (in einer bestimmten Version). Wenn man nun ein händisch runtergeladenes .ipk einer neueren MP-Version über das, im Feed eines Images enthaltenen drüber-installiert, kann es zu Inkonsistenzen kommen. Daher sollte man sich vor der Installation darüber Gedanken machen...

Zu empfehlen wären folgende Vorgehensweisen:

- Entweder das MediaPortal eines Image-Feeds benutzen, und stets den Update des Feeds des Images abwarten, und das Update des MP wird erst mit dem Update des Images wirksam.
- Oder das MediaPortal nicht im Feed installieren, sondern per Hand... Dann wäre das Einschalten des Überwachers auf Updates (innerhalb des MediaPortals) auch wirksam, und darf genutzt werden

Zweiteres ist eigentlich zu empfehlen, da man nicht erst auf ein Update des Image-Erstellers warten muss, um stets die neuste Version (Bugfixes) des MediaPortals nutznießen zu können.

Art der Installation (Kopieren via FTP oder .ipk Paket)

Bis vor einigen Monaten, konnte man in der GIT-Umgebung noch ein ZIP-File herunterladen, und - nach Löschen von eigen ungenutzten Dateien - die täglich aktuellste Version via FTP in das FlashROM des Receiveres hochladen.

Seit das GIT zum MP aber nun versteckt ist, geht das nicht mehr. Man muss nun also entweder auf die Implementierung der neuesten Version innerhalb der Image-Betreuers warten, oder auf -falls man händisch installiert hatte, was zu empfehlen ist - eine neue Version des MP, um sie händisch, oder via Auto-Update Funktion zu installieren.

Sollte man die händische Funktion bevorzugen, dann ist die .ipk Date - die meist im zweiten Posting des offiziellen MP-Threads zu finden ist, via FTP nach /tmp der Box hochzuladen. Hat man dies gemeistert, dann sollte man zunächst im Erweiterungs-Menü unter

Abhängigkeiten/Installation

Auch hier muss man ein wenig aufpassen. Sollte man das MediaPortal händisch installiert haben (was zu empfehlen ist), dann werden über das .ipk auch sämtliche Treiber/Libs, die das MediaPortal benötigt, automatisch mit-installiert. Sollte man anders vorgegangen sein, dann muss man evtl. händisch vorgehen, oder auch nachhelfen... Der "Telnet"-Client wird benötigt. Ab Windows7 muss man den "Telnet-Client" meist erst per Hand nach-installieren... Das geht über Systemsteuerung, "Programme und Funktionen", und darunter (auf der linken Seite) unter "Windows Funktionen aktivieren oder deaktivieren" anklicken. Eine Windows-CD wir meist dazu nicht benötigt.

Ist der Arbeitsschritt abgeschlossen, so öffnet man eine Eingabeaufforderung (unter Win7 auf den Start-Button klicken, und "Eing" eintippen. Dann Enter. Dann in dem schwarzen Fenster "telnet <IP der Box>" eintippen, und User/PW der Box eingeben. Nun kann man folgendes eingeben...

Nachzuinstallierende Pakete, bei manueller Installation

ToDo

FAQ/Häufigste Fehler

ToDo

Known Bugs

ToDo

Erstellen von Skins

ToDo