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 zur 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 sind 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, aber 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. 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...
a) an Änderungen am Streaming-Portal liegen, oder
b) an individueller Fehlkonfiguration im LAN-Umfeld, oder
c) an Fehlern nach einer individuellen Änderung an *irgendeiner* Komponente im Receiver, oder
d) an temporären, oder auch grundsätzlichen Änderungen am Internet-Provider
e) und und und...
Daher ist es sehr wichtig für die Programmierer des MediaPortals, zu wissen, dass all' diese Faktoren bereits vom User beachtet wurden, bevor man einen ernstzunehmenden "Bug-Report" postet!
Sollte sich zB. b) oder c) als Fehlerursache eines reportenden Users heraustellen, konnte weder die Community, als auch ein Programmierer nichts dabei hinzu lernen.
Man sollte also als User abwägen, ob man ausreichend getestet hat, bevor man im offiziellen MediaPortal-Thread 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
ToDo
MediaInfo - Der stille Helfer (nur HTTP)
ToDo
Installation/Auto-Update/Image
ToDo
Art der Installation (Kopieren via FTP oder .ipk Paket)
ToDo
Abhängigkeiten/Installation
ToDo
Nachzuinstallierende Pakete, bei manueller Installation
ToDo
FAQ/Häufigste Fehler
ToDo
Known Bugs
ToDo
Erstellen von Skins
ToDo