Sundtek Support Forum
Deutsch => Sundtek MediaTV Pro => Thema gestartet von: joergd am Dezember 11, 2009, 11:20:50 Nachmittag
-
Hallo,
ich habe seit Kurzem einen Sundtek MediaTV Pro unter Linux mit dem VDR im Einsatz. Die Entscheidung dafür war relativ leicht, da das Angebot von DVB-C-Geräten mit Linux-Unterstützung leider recht übersichtlich ist. Bedenken könnte man haben, weil die erforderliche Software Closed Source ist, aber ich unterstütze bisher eigentlich eher Bemühungen von Firmen, die innovative Produkte für Linux entwickeln, auch wenn diese nicht frei sind. Im Fall MediaTV Pro habe ich inzwischen leider selbst einige Bedenken, ich würde es sehr begrüßen, wenn diese von Sundtek einmal kommentiert werden könnten. Denn eigentlich würde ich mir gern einen oder gar zwei weitere Sticks zulegen, um mehrere parallele Aufzeichnungen zu ermöglichen.
Zu den einzelnen Punkten:
- Der Treiber soll durch die Nutzung vom usbfs vom Kernel unabhängig sein.
Zumindest im von mir verwendeten aktuellen Kernel 2.6.32 wird usbfs als "deprecated" gekennzeichnet, wird also bald nicht mehr verfügbar sein. Sollte dann auch welchen Gründen auch immer keine neue Firmware mehr für den MediaTV Pro erscheinen, muß ich (wenn möglich) einen alten Kernel verwenden oder den Stick entsorgen. - Die Userspace-Treiber bilden die Linux DVB API nach?
Wenn das eine 100%ige Nachbildung wäre, gäbe es nicht die Probleme, wie sie mit den verschiedensten Programmen auftreten (z.B. hier: http://support.sundtek.com/index.php/topic,177.0.html (http://support.sundtek.com/index.php/topic,177.0.html) von mir beschrieben). Hier habe ich also wieder ähnliche Bedenken wie im vorigen Punkt: Ändert sich die Linux DVB API und damit die darauf aufsetzenden Programme, funktioniert der MediaTV Pro ohne Anpassung nicht mehr. Ohne Support von Sundtek ist der Stick dann nicht mehr zu gebrauchen. - Support
Das ist der entscheidende Punkt: Solange der Support von Sundtek funktioniert, sind mir die obigen Punkte egal. Das ist jedoch im Moment leider nicht der Fall. Ich hatte Probleme beim Einsatz mit meiner zugegebenermaßen etwas exotischen Konfiguration (s. Link im vorigen Punkt). Wie vom Support gewünscht, habe ich extra einen Remote-Zugang eingerichtet und den VDR laufen lassen - allerdings hat sich nie jemand darum gekümmert. Der verspochene Kontakt per E-Mail in dieser Woche hat auch noch nicht stattgefunden. - Einfache Installation durch Installer
Das mag zwar für einfache Installationen zutreffen. In meiner Umgebung z.B. wird es mir durch den Installer aber unnötig schwer gemacht. Ich nutze eine separaten IR-Empfänger für die Fernbedienung und muß dies auch weiterhin tun, da der MediaTV Pro an der Rückseite meines VDR-Rechners angeschlossen ist und so kein Sichtkontakt besteht. Da durch den Installer der IR-Empfänger des MediaTV Pro aktiviert wird, muß ich erst lange untersuchen, was der Installer genau tut und anschließend entsprechende Korrekturen vornehmen. Lieber wäre mir (evtl. auch als Alternative zum Installer) ein einfaches Archiv mit allen Dateien und einer kurzen Beschreibung, was diese tun. - Unterstützung anderer Architekturen
Bei Open Source Projekten wäre der Einsatz auf nicht-x86-Architekturen relativ problemlos möglich. Da meine ursprünglich vorgesehene Konfiguration (ReelVDR auf "normaler" PC-Hardware) mit dem MediaTV Pro nicht funktioniert, habe ich diesen alternativ an einen OpenRD Client mit ARM-Architektur angeschlossen und greife darauf über das VDR StreamDev Plugin zu. Aber auch hier gibt es Probleme, und da im aktuellen Treiber-Paket nur eine alte Version für die ARM-Architektur enthalten ist, kann ich die neue Netzwerk-Unterstützung auch nicht nutzen. Eine neue ARM-Version wurde schon mehrmals versprochen (http://support.sundtek.com/index.php/topic,158.msg700.html#msg700 (http://support.sundtek.com/index.php/topic,158.msg700.html#msg700)), ist aber immer noch nicht verfügbar. - Daß Software-Entwicklung nicht immer einfach ist und immer mal unerwartete Probleme auftreten, ist mir klar. Trotzden würde ich bevorzugen, wenn keine unhaltbaren Versprechungen gemacht werden. Ich habe wegen der ungelösten ReelVDR-Probleme extra mit relativ hohem Aufwand die ARM-Variante installiert. Hätte Sundtek statt den getroffenen Aussagen zum ARM-Support gesagt, daß sich dieser aus sicher verständlichen Gründen etwas verzögert, hätte ich evtl. eine andere Variante (z.B. X86 Streaming Server) wählen können. So habe ich mich erst lange mit dem ReelVDR und danach ähnlich erfolglos mit dem OpenRD Client beschäftigt...
Ich hoffe, mit meiner Kritik zum Nachdenken anzuregen und eine Verbesserung des derzeitigen Zustandes zu erreichen. Da komplett Open Source wegen der Restiktionen der Chip-Hersteller wohl nicht möglich ist, wäre mir persönlich zum derzeitigen Stand ein möglicht kleines Closed-Source-Modul am liebsten, welches sich gut in die bestehenden Open-Source-Lösungen einfügt.
Jörg
-
USBDEVFS ist bereits seit laengerer Zeit depreciated. USBDEVFS wurde frueher "gemounted" dies entfaellt dadurch das udev die Nodes/Interfaces jetzt direkt anlegt - lediglich das mounten ist depreciated nicht das Interface an sich. Der Treiber verwendet bei neueren Systemen woertlich das USB DEVIO Interface, welches der Ersatz fuer USBDEVFS darstellt. Die Kernel Entwickler sind mit der Benennung bereits selber durcheinander gekommen da es intern teilweise noch immer als USBDEVFS gekennzeichnet ist.
Es aendert sich fuer den Treiber nichts und das Interface ist wie urspruenglich angekuendigt weiterhin stabil, stabile Interfaces fuer Applikationen ist das Um und Auf fuer Linux hierbei wird sich auch zukuenftig nichts aendern. Ebenfalls Unternehmen wie VMWare, SUN/Oracle(Virtualbox) setzen auf diese Schnittstelle. Qemu verwendet diese ebenfalls.
Zu den Verzoegerungen, es gibt mittlerweile eine vielzahl an kritischen Anwendungen fuer uns wo wir direkt mit anderen Unternehmen zusammenarbeiten. Hierfuer sind teilweise auch Aenderungen an unserem Treiber notwendig (z.B.: Umstellung der Kopierroutinen auf SSE/MMX um die CPU Last zu verringern). Diese Aenderungen fliessen allesamt in den Haupttreiber ein welcher dann oeffentlich freigegeben wird. Ausnahmslos allen Problemen wird nachgegangen, jedoch muessen wir hierbei auch Prioritaeten vergeben.
Der ARM Build ist soweit mittlerweile intern Komplett, jedoch gibt es derzeit noch weitere Aenderungen welche hier einfliessen. Wir wollen hierbei keine Loesungen fuer Einzelkaempfer anbieten sondern besonders durch die Netzwerkunterstuetzung neue Moeglichkeiten fuer jedermann schaffen. Die Linux Entwickler arbeiten diesmal enger als zuvor mit den Windows Entwickler zusammen um die Geraete auch ueber das Lan im Windows benutzen zu koennen.
Sobald wir Ihr spezielles Problem identifiziert haben wird es ebenfalls in den Treiber einfliessen, die vorgenommenen Aenderungen am Treiber werden bei jedem Update beschrieben sodass man auch sieht das hierbei auch ziemlich viel gemacht wird.
Bezueglich dem Nachbilden der API, dies ist ein sehr komplexer Vorgang viele Opensource Kerneltreiber funktionieren derzeit z.B.: nicht mit Zapping, andere wiederum haben keine Audio Ausgabe bei Analog TV oder FM Radio, bei genauerem hinsehen gibt es dann auch noch recht viele Moeglichkeiten den Kernel komplett lahm zulegen mit so einigen Treibern. Diese Probleme wurden von uns allesamt bereits geloest, und es wird auch noch weitere Aktualisierungen geben. Auf unserem getesteten NAS kommt z.B.: Linux 2.6.15 zum Einsatz, der Treiber laesst sich innerhalb weniger Sekunden auch dort installieren, aktuelle Opensource Treiber kann man mit diesem System ueberhaupt nicht mehr uebersetzen.
-
Hallo
Lieber wäre mir (evtl. auch als Alternative zum Installer) ein einfaches Archiv mit allen Dateien und einer kurzen Beschreibung, was diese tun.
Das würde ich auch bevorzugen. Das würde die Pflege des PKGBUILD (http://aur.archlinux.org/packages.php?ID=31472) für ArchLinux (http://www.archlinux.org) sehr vereinfachen.
Liebe Grüße
-
Dies ist kein Problem zusaetzlich nur den Link zu einem 32 bzw. 64 Bit Archiv fuer fortgeschrittene Linux Anwender anzubieten. Wir machen dies bereits fuer einige groessere Kunden.
-
@Sundtek: Danke für die ausführliche Antwort.
USBDEVFS ist bereits seit laengerer Zeit depreciated. USBDEVFS wurde frueher "gemounted" dies entfaellt dadurch das udev die Nodes/Interfaces jetzt direkt anlegt - lediglich das mounten ist depreciated nicht das Interface an sich.
Okay - wieder etwas gelernt.
Der ARM Build ist soweit mittlerweile intern Komplett, jedoch gibt es derzeit noch weitere Aenderungen welche hier einfliessen.
Ich will Ihnen da auch nicht reinreden, mir persönlich würde eben ein funktionierender Treiber ohne neue Funktionalitäten (welche ja oft auch neue Fehler "erzeugen") genügen. Vor allem, da dieser schon mehrfach angekündigt wurde...
Okay - ich werde mal abwarten, wie das kommende Release ausfällt, wenn da alles funktioniert, bin ich ja zufrieden.
Dies ist kein Problem zusaetzlich nur den Link zu einem 32 bzw. 64 Bit Archiv fuer fortgeschrittene Linux Anwender anzubieten. Wir machen dies bereits fuer einige groessere Kunden.
Das wäre prima, vor allem, wenn das auch für ARM gäbe.