blog · git · desktop · images · contact
2009-11-13
Der Fernsehstick MediaTV Pro der Berliner Firma Sundtek ist hier und kann ausprobiert werden. Diese Firma war mir vorher völlig unbekannt, mit Fernsehprodukten für den Rechner verbindet man ja normalerweise Hauppauge, Pinnacle, Terratec oder ähnliche.
Worum geht es bei diesem Stick? Grober Überblick, was er kann:
Also bis auf DVB-S quasi alles. Und der Hersteller verspricht Lauffähigkeit unter Linux. Oha. :)
Sundtek ist die Firma von Markus Rechberger. Wenn man diesen Namen verfolgt, stößt man zuerst auf den "em28xx-new"-Treiber, für den er wohl maßgeblich verantwortlich war, und irgendwann landet man bei diesem LWN-Artikel. "em28xx-new" scheint damals viele Devices zum Laufen gebracht hat, denn dieser Treiber wurde an einigen Stellen erfolgsversprechend erwähnt (zum Beispiel auch für den WinTV-HVR-900-Stick), dann aber wurde seine Entwicklung eingestellt. Jedenfalls kommt es mir so vor, als wüssten die Leute dort, was sie tun. :) Über die sonstigen Verquickungen mag sich jeder selbst sein eigenes Bild machen.
Das Schöne ist, dass mittlerweile jemand ein PKGBUILD für Arch gebaut hat, das im AUR liegt ("empia" -- meine Testläufe waren allerdings noch mit Version 091016). Das heißt, die Installation als solche ist für Arch-User trivial. Interessanter wird es, wenn man sich anschaut, wie der Treiber funktioniert -- und welche Nachbesserungen am PKGBUILD man vielleicht gerne vornehmen möchte.
Wie man nach der Lektüre des LWN-Artikels und der dortigen Kommentare schon erahnen kann, gibt es kein Kernel-Modul, die ganze Geschichte läuft im Userspace ab. Damit umgeht man natürlich einige Probleme und kann es sich auch einfacher leisten, einen closed-source-Treiber zu liefern. Das ist auch gleichzeitig einer der größten Kritikpunkte am ganzen Produkt, denn es sind nicht alle Quellcodes verfügbar. Da stellt sich dann natürlich die Frage, ob der Stick in ein paar Jahren noch nutzbar ist, falls der Treibersupport (für Linux) dann halt doch mal eingestellt werden sollte oder Sundtek vor die Hunde geht. Durch die Form des Userspace-Programms sinkt aber auf der anderen Seite die Wahrscheinlichkeit, dass ein neuer Kernel den Stick unbrauchbar macht. Folglich könnten die vorhandenen Treiber länger laufen. Ganz davon abgesehen, dass man grundsätzlich nur sehr wenige Hersteller findet, die tatsächlich mal alle Quellcodes liefern... :(
Wie aber wird dann mit dem Gerät kommuniziert? Dazu bedient sich der
Treiber eines "Tricks": Über den Preload-Mechanismus (siehe "man ld.so",
dort "LD_PRELOAD") werden bestimmte Calls aus der libc überschrieben
bzw. umgelenkt. Die Daten landen dann in einem Unix-Socket statt einer
Device-Node, an dessen anderem Ende der Treiberprozess sitzt.
Vermutlich, um die Support-Anfragen dahingehend möglichst gering zu halten, fügt der normale Installer von Sundtek diese Preload-Anforderung systemweit in "/etc/ld.so.preload" ein. Da die überschriebenen Funktionen aber grundlegender Natur sind (open(), read(), write() u.ä.), will man das vielleicht nicht unbedingt über sich ergehen lassen -- zumal im Forum schon über Probleme mit dem Firefox berichtet wurde. Weiterhin liegt die Library fest in "/opt", was unter Umständen beim Booten noch nicht gemountet ist, wodurch einige (wenn auch vermutlich harmlose) Fehlermeldungen erzeugt werden können.
Es ist also möglicherweise wünschenswert, diese systemweite
Registrierung nicht zu nutzen (im Arch-Paket müssen dafür die
entsprechenden Zeilen im Installationsskript entfernt werden) und
stattdessen manuell vor Aufrufen der genutzten TV-Programme die Variable
"LD_PRELOAD" passend zu setzen:
#!/bin/bash
export LD_PRELOAD="/opt/lib/libmediaclient.so:$LD_PRELOAD"
mplayer ...
Bevor irgendwas geht, muss eine Senderliste erstellt werden. Am besten scheint hier w_scan aus dem AUR zu funktionieren. In der Manpage dazu stehen viele Beispiele, was den Aufruf betrifft.
Übrigens: Wenn man für DVB-C scannt, kann man bei w_scan über den
Parameter "-S <index>" angeben, welche Symbolrate abgefragt werden soll.
Dabei muss für "<index>" ein Wert zwischen 0 und 12 angegeben werden. In
welche echte Symbolrate das übersetzt wird, verrät einem "w_scan -H".
Je nach TV-Anbieter kann es notwendig sein, diesen Wert explizit zu
setzen, da w_scan normalerweise nur die Raten 6900 und 6785 scannt --
manchmal muss es aber auch 6111 sein, sonst fehlen Sender.
Ist diese Liste erst einmal gebaut (kann bei DVB-C eine halbe Stunde oder länger dauern), kann es dann losgehen.
Was das Anschauen von digitalem Fernsehen betrifft, habe ich mit kaffeine die besten Erfahrungen gemacht. Dieses ist bei Arch im "extra"-Repository, aber klein ist das Programm nicht gerade. Vorallem, wenn man kein KDE nutzt, halst man sich damit einiges an Abhängigkeiten auf. Direktes Anschauen mit dem MPlayer oder VLC hat leider nicht funktioniert -- zumindest nicht über "mplayer dvb://", wie es an vielen Stellen im Netz erwähnt wird. Mit dem Umweg über manuelles Einstellen des Senders (siehe unten) ginge es aber auch.
Analoges TV schaut man aber trotzdem am besten über den MPlayer, mir ist er jedenfalls am liebsten. Mal ganz davon abgesehen, dass kaffeine das nicht kann. Einen analogen Sendersuchlauf kann man mit "scantv" aus dem "xawtv"-Paket durchführen:
scantv -c /dev/video0 -C /dev/vbi0 -n pal -f europe-west -o chanlist
Hat man einen Laptop, ist es natürlich sehr interessant, inwieweit sich der Stick zur automatisierten Aufnahme eignet. Gerade bei Nachtaufnahmen ist es schon nicht schlecht, wenn nicht ständig ein großer Lüfter bläst. ;)
Prinzipiell kann kaffeine das auch, allerdings nur für digitales Fernsehen. Außerdem muss man eingestehen, dass es (nur mit kaffeine) manchmal beim Senderwechsel hakt und einfach nichts kommt. Wenn ich etwas wirklich aufnehmen will, dann ist mir das zu unsicher. Also müsste eine eigene Lösung her -- dicke Pakete wie VDR oder ähnliches habe ich aus Zeitgründen nicht ausprobieren können.
Was digitales Fernsehen angeht: Sundtek liefert ein kleines Programm mit, das sich "mediaclient" nennt. Hierüber kann man als User an der Shell den Stick steuern und zum Beispiel den Transponder einstellen und bestimmte Streams bzw. PIDs herausfiltern lassen. Dafür gibt es zwar schon andere Programme wie zum Beispiel {c,t}zap aus den linuxtv-dvb-apps, jedoch bietet der mediaclient gegenüber diesen einen großen Vorteil: Nach erledigter Arbeit beendet sich der mediaclient wieder, czap und Co. müssen dagegen weiterlaufen. Gerade, wenn man mal eben schnell eine eigene Skriptlösung basteln will, wird einem dadurch das Leben definitiv erleichtert. ;) Oben erwähntes Problem, dass der Senderwechsel mit kaffeine nicht klappt, trat mit dem mediaclient kein einziges Mal auf.
Nach dem Tuning und Aufsetzen des Filters genügt folgender Aufruf, um
den Stream 1:1 auf die Platte zu schreiben (vorher eventuelles Setzen
von "LD_PRELOAD" nicht vergessen):
cat /dev/dvb/adapter0/dvr0 > foo.ts
Alternativ könnte auch der MEncoder auf dieses "Device" losgelassen werden (oder der MPlayer zum direkten Anschauen), sofern man direkt transcoden wollen würde. Für späteren Schnitt ist das aber nicht zu empfehlen.
Dieser Aufruf ist für DVB-T und DVB-C gleich. Das heißt, beide Varianten lesen aus demselben "Device". Das Internet sagt, dass das bei "richtigen" Recorderlösungen zu Problemen führen kann, da diese dann unter Umständen nicht wissen, ob sie gerade DVB-T oder DVB-C aufnehmen sollen. In der Tat muss man vorher den Modus auch explizit wählen, was bei einer eigenen Skriptlösung kein Problem darstellen sollte:
/opt/bin/mediaclient --setdtvmode=DVBC
Zusammen mit dem at-Daemon, sleep und kill hat man damit auch schon alle Werkzeuge beisammen, um einen Recoder zu basteln. Da der Stream vom Sender direkt übernommen wird, tritt nur eine minimale CPU-Last auf. Ein USB 2.0-Anschluss sollte es aber vielleicht doch besser sein. :) Und eine große Platte.
Bei analogem Fernsehen kann man sich das Einstellen des Senders sparen und dieses direkt dem MEncoder überlassen, welcher auch gleich Deinterlacing und entsprechende Komprimierung übernimmt. Sowieso ist hier der mediaclient überhaupt nicht nötig, "/dev/videoX" funktioniert immer. Jedoch muss man (im Moment) zu einem etwas seltsamen Trick greifen, um auch den Ton aufzunehmen: Hardwareseitiges Loopback. Sprich, ein kleines Kabel vom Audioausgang in den Mikrofoneingang. Die direkte Aufnahme vom Stick funktioniert zwar, nach dem Beenden verhaspelt sich der MEncoder aber in einem Deadlock und muss hart abgeschossen werden. Vielleicht wäre es auch eine Alternative, hierzu mal einen Blick auf den VLC oder andere Programme zu werfen. Meine billige Soundlösung im Laptop könnte natürlich auch noch dazwischengefunkt haben, ich weiß es nicht.
Pro:
Kontra:
Meine subjektive Meinung wäre, dass der Stick prima für Bastler geeignet ist, die den nötigen Pragmatismus aufbringen können, um mit den closed-source-Treibern leben zu können. Gerade, was die Automatisierung angeht, bietet der Stick durch den Verzicht auf Klick-Software viele Möglichkeiten. Außerdem ist es der einzige Stick, den ich so finden kann, der unter Linux läuft und DVB-{T,C} sowie analoges TV liefert.
Wem der Binärblob übel aufstößt oder wer eine Klick-Lösung sucht (wie gesagt, VDR und Co. habe ich nicht getestet), bei der einfach alles funktioniert, der sollte vielleicht doch lieber zu anderen Produkten greifen. Hier wird die Luft unter Linux dann aber doch recht schnell etwas dünn...