Vorschlag: Gemeinsame Basis für netzwerkbasierte Tuner (SAT>IP, Netceiver, Octopus-Net)

Hi,

Gute IDEE - ich Unterstütze das Projekt - zumindest moralisch, mangels guter Programmierkanntnisse.

RESPEKT und viel Erfolg

Grüße

Das ist exakt das was der Suntek-Treiber macht. Auch der kann ja über das Netz mounten. Schade das er Closed-Source ist.

Gerald

Ich finde dieses LD_PRELOAD-Gebastel schon beim Sundtek-Treiber böse.
Siehe dazu auch:
http://blog.tridgell.net/?p=141
Was spricht gegen dieses "CUSE", das er dort anspricht?
http://lwn.net/Articles/308445/

Moin,

bin zwar auch nicht der Programmierer aber bin mal über folgenden Link gestolpert.

http://code.google.com/p/vtuner/

Gruß
Stefan

Nicht uninteressant.

Das knifflige jeder "IP-Tuner-Lösung" ist aber das Skalieren. Und ich konnte auf den ersten Blick nicht erkennen wie man das Problem bei vtuner gelöst hat.

Eine IP-Tuner-Lösung ist nämlich nur dann vorteilhaft, wenn man damit die Gesamtanzahl von Tunern auch reduzieren kann. Das ganze macht kaum Sinn wenn man am zentralen Punkt dann z.B. 2 Tuner pro VDR im Haus vorhalten muss. Sinn macht das ganze dann, wenn die ganze Netzwerkschicht so intelligent ist, dass sie einen Tuner, der für VDR 1 schon Transponder 1 einfängt, bei Anfrage auch auf einen VDR 2 mappen kann, der ebenfalls diesen Transponder benötigt.

Zitat von Mreimer

Sinn macht das ganze dann, wenn die ganze Netzwerkschicht so intelligent ist, dass sie einen Tuner, der für VDR 1 schon Transponder 1 einfängt, bei Anfrage auch auf einen VDR 2 mappen kann, der ebenfalls diesen Transponder benötigt.

Jep das finde ich essentiell und überaus wichtig - soweit ich in manchen Artikeln gelesen habe, wird teilweise tatsächlich 1Tuner an 1 Gerät gebunden, was die Lößung in meinen Augen unsinnig macht - ein inteligentes Mapping wäre sicherlich extrem wünschenswert und ein super Feature - und btw. VDR hatte ja schon immer in vielen Bereichen technisch fortschrittliche Lößungen an Board, da sich die Entwickler immer viele Gedanken gemacht haben was eine gute Lößung eines Problems angeht und im Endergebnis somit immer eine oder zwei Nase lang Vorsprung ( oder sogar weit mehr ).

Grüße

Und da der VDR im Zusammenhang mit dem Streamdev-Plugin das eigentlich ziemlich gut kann, wäre meine aktuell bevorzugte Lösung auch in der Tat ein zentraler Mini-Server mit VDR als Software darauf. Was man wirklich bräuchte wäre eine sparsame ARM-Plattform mit einem PCI-Express-X1 Anschluss um dort eine Octopus-Basisplatine draufbauen zu können.

Zitat von Mreimer

wäre meine aktuell bevorzugte Lösung auch in der Tat ein zentraler Mini-Server mit VDR als Software darauf.

die Frage ist nur was der generelle Netzwerksupport eines DVB Tuners eigentlich mit VDR zu tun haben soll. Es ist doch nur wieder eine Kruecke hier eine spezielle Applikation (hier VDR) als Netzwerkserver laufen haben zu muessen, nur weil die DVB Treiber nicht direkt netzwerktransparent sind. Zumal es viele Anwendungen (mplayer, etc.) gibt die mit Streamdev sowieso nichts anfangen koennen.

- sparkie

Der MPlayer kann durchaus Streamdev-Streams wiedergeben.

Ich befürchte halt, dass "Netzwerktransparenz eines DVB-Tuners" schlicht heißt, dass das Netzwerk als Verlängerung dazwischen liegt. Da sehe ich in den allermeisten Anwendungsfällen keinen Mehrwert.

Der Reiz einer zentralen "Kopfstation" ist ja gerade, dass man dort z.B. 8 Tuner verbauen würde und damit dann mit 4 Clients möglicherweise mehr Sender parallel zugreifen kann als wenn man in den 4 Clients jeweils zwei Tuner verbauen würde.

Und der VDR kann Tuner, im Zusammenhang mit Streamdev, durchaus skalieren und intelligent verteilen.

Ein LD_PRELOAD-binary-patch, der open() und ioctl() abfaengt und je nach Dateiname und magic number was anderes tut hoert sich ekelig an.

Im Prinzip will man doch genau sowas wie vtuner, nur dass zwischen Server und Client nicht das vtuner-Protokoll, sondern rtsp gesprochen wird.

vtuner wurde schon 2011 hier diskutiert, wer sich dafür interessiert, kann ja hier nachschlagen:
Das neue Netzwerk-Client, der für vdr verwenden können
https://github.com/yavdr/vtuner

Gruß
hepi

Hallo,
ursprünglich fand ich die Idee mit einem VDR Plugin naheliegender aber vor allem um die Verbreitung und somit auch den Nutzerkreis und Support zu erhöhen ist die Idee mit einem wie auch immer implementierten DVB Treiber eine sehr interessante Alternative.

Um ehrlich zu sein glaube ich aber, dass von den aufgezählten Möglichkeiten SAT>IP das größte Potenzial weil auch den größten Support in der Industrie hat. Wenn man sich die SAT>IP Specs mal durchliest sind da viele gute Ideen und Arbeit schon eingeflossen die der VDR gerade in großen Installationen so auch nicht besser abbilden kann.

Zitat

Das knifflige jeder "IP-Tuner-Lösung" ist aber das Skalieren.

Bei kleinen Installationen wird es darauf hinauslaufen, 1 Tuner pro gleichzeitig laufendem VDR. Und Unsinnig ist das jetzt bei einem Preis von 35Euro pro Tuner auch nicht unbedingt.

Zitat

Eine IP-Tuner-Lösung ist nämlich nur dann vorteilhaft, wenn man damit die Gesamtanzahl von Tunern auch reduzieren kann.

Kann man, aber erst wenn mehr VDRs am Netzhängen als Transponder vorhanden oder gewünscht. Vorher hat man immer das Problem wenn zwei den gleichen Transponder sehen und einer umschalten möchte. Bei SAT>IP ist einer von beiden der Owner, der beim Umschalten den Kanal auch für den zweiten Nutzer wechselt bzw. diesen dann rauswirft.

Zitat

soweit ich in manchen Artikeln gelesen habe, wird teilweise tatsächlich 1Tuner an 1 Gerät gebunden, was die Lößung in meinen Augen unsinnig macht

Der Nutzer kann bei SAT>IP einen Tuner anfordern, das ist aber ausdrücklich nicht empfohlen. Standard ist, dass die Tuner den Nutzern dynamisch zugewiesen werden. Ich weiß ja nicht auf wieviele VDRs ihr im Haus so kommt, aber bei drei ist bei mir bereits Schluss und ich muss sagen selbst bei 10 wird es vermutlich ohne die Einschränkungen im Programmumfang nicht mit wesentlich weniger Tunern gehen.
Wie gesagt, ich finde insbesondere die SAT>IP Lösung ziemlich interessant und so wie das Format der HTTP-Requests aussieht sollte es auch eigentlich schon mit dem iptv Plugin funktionieren. Bleibt noch die Frage der Umschaltzeiten und der Stabilität aber bei der Anzahl an verschiedenen Herstellern die um den Markt konkurrieren glaube ich das es in der nächsten Zeit qualitativ hochwertige Geräte geben wird.

Zitat von Mreimer

Ich finde dieses LD_PRELOAD-Gebastel schon beim Sundtek-Treiber böse.
Siehe dazu auch:
http://blog.tridgell.net/?p=141
Was spricht gegen dieses "CUSE", das er dort anspricht?
http://lwn.net/Articles/308445/

Der Vogel von dem Blog sollte sich mal seinen Projekten widmen, kurz darauf kam sogar via Heise eine root-Sicherheitslücke in Samba. Vergleicht man hierzu noch das Samba auch Windows und Mac Clients blockieren kann dann gibt es auch genug auf anderen Seiten zu bemängeln (und dort arbeitet der mit). Der hat sich zudem einmal mit LD_PRELOAD gespielt, was er da hervorgebracht hat bringt so einige Applikationen zum Absturz da er damit nur wenig Erfahrung hat.

Cuse ist Schrott da es produktiv nicht stabil ist, man kann dadurch wieder recht einfach zu einem Kernel Oops kommen (wir haben dies sehr genau getestet, damit bekommt man erst recht eine Sicherheitslücke in das System).
LD_PRELOAD kann man zudem lokal oder global anwenden und es ist rückwärts-kompatibel, dadurch läuft das Ganze ab Linux 2.6.15 mit einem Treiber ohne kompilieren zu müssen.
Nichts desto trotz muss man dies nicht verwenden, es ist nur ein kompatibilitäts-Layer für Linux DVB bzw. Video4Linux, der Treiber kann auch direkt angesprochen werden bzw. Applikationen können z.B /opt/lib/libmcsimple.so direkt einbinden. Hier wird sich in Zukunft einiges tun tvheadend hat z.B ein Plugininterface für solche Geräte integriert. Auch bei uns entwickelt sich alles weiter.

Unsere neuen Geräte gehen ab kommender Woche in Produktion, sobald diese verfügbar sind kann man einfach auf jedem Rechner innerhalb von gut 15 Sekunden den Treiber installieren - egal welcher Kernel dort nun läuft oder ob es ein Embedded System ist oder nicht.

Zitat

Und da der VDR im Zusammenhang mit dem Streamdev-Plugin das eigentlich ziemlich gut kann, wäre meine aktuell bevorzugte Lösung auch in der Tat ein zentraler Mini-Server mit VDR als Software darauf. Was man wirklich bräuchte wäre eine sparsame ARM-Plattform mit einem PCI-Express-X1 Anschluss um dort eine Octopus-Basisplatine draufbauen zu können.

da gibts bisher nur die tegra-dev platform von nvidia

Die Frage ist, in wiefern CUSE eine instabile API ist.

Oder anders: Ist diese Art der "Instabilität" nur problematisch für Closed-Source-Applikationen (keine Binärkompatibilität gewahrt)? In diesem Fall wäre das nämlich für das hier angedachte Projekt total irrelevant, denn mal eben für ein neues Kernel-Major-Release diesen Daemon neu kompilieren sollte nicht das Problem sein.

Zitat von Moorviper

da gibts bisher nur die tegra-dev platform von nvidia

Und was würde die 8-fach Variante kosten? Alleine die 4 Doppeltuner und die Bridge kommen auf über 600 Euro. Da probier ich doch erstmal zwei 4-fach SAT>IP Server aus, die sich laut Spezifikation ohne weiteren Aufwand zusammen betreiben lassen und bezahle nicht mal die Hälfte...

Zitat von Mreimer

Die Frage ist, in wiefern CUSE eine instabile API ist.

Oder anders: Ist diese Art der "Instabilität" nur problematisch für Closed-Source-Applikationen (keine Binärkompatibilität gewahrt)? In diesem Fall wäre das nämlich für das hier angedachte Projekt total irrelevant, denn mal eben für ein neues Kernel-Major-Release diesen Daemon neu kompilieren sollte nicht das Problem sein.

Kernel-Userspace APIs an sich sind üblicherweise stabil.
Es sind einfach Programmierfehler in CUSE. Zudem weiß man nicht mal ob CUSE in jedem System freigeschalten oder beinhaltet ist.

Sobald die neuen Geräte verfügbar sind klappt DVB-C/T/T2 automatisch via Netzwerk (Linux/Win/Mac werden als Client auch soweit unterstützt).
Die Netzwerkfähigkeit ist bei uns schon sehr lange verfügbar, und lässt sich auch auf Routern (z.B TP-Link WR1043ND) benutzen.
Die Treiber an sich laufen bei uns auch auf MacOSX, die Software ist sehr portabel ausgelegt, so kann man Mac unter anderem auch als Server verwenden.

Wenn man sich etwas spielen würde und auf MacOSX VDR gegen /opt/lib/libmcsimple.so linken würde könnte man sogar VDR direkt auf Mac mit der Linux DVB API verwenden.

Soweit ich mich erinnere ging es hier im Sat>IP und alternativ Netceiver. Wäre der Treiber der Sundtek-Sticks Open Source könnte man ihn möglicherweise für Sat>IP und den Netceiver ausbauen. Da er das aber nicht ist, ist er für den hier im Thread diskutierten Anwendungsfall nicht verwendbar.

Nachtrag: Gerade mal nachgeschaut: CUSE ist bei Archlinux als Modul verfügbar. Ob es auf anderen Distributionen verfügbar ist, kann ggf. mit "grep CONFIG_CUSE /boot/config" ermittelt werden.

Und wenn ich mich nicht komplett verlesen habe, basiert das allseits bekannte "FUSE" auch auf "CUSE".

Moin!

<Offtopic>
Mein sundtek-Plugin redet z.B. schon ohne LD_PRELOAD mit dem mediasrv, um mitzubekommen, ob ein neuer Stick angestöpselt wurde oder nicht. Klappt wunderbar.
Es ist theoretisch auch gar nicht so schwer, ein vdr-Plugin zu schreiben, dass ebenfalls ohne LD_PRELOAD auskommt und die DVB-Geräte über die "native" API dem vdr zur Verfügung stellt. Das einzige, was mich davon abgehalten hat, ist, dass ich quasi die komplette Klasse cDvbDevice kopieren müsste und noch ein paar andere Hilfsklassen (cPoller usw.), weil statt open/read/write/close die entsprechenden Funktionen von Sundtek benutzt werden müssen.

Mein Programmiererherz widerspricht da ein wenig, insbesondere wegen der Pflege, wenn sich was am cDvbDevice im vdr ändert und dann auch noch die Features mit Device-Bonding usw. Die würden ja nicht einfach automatisch und geräteübergreifend funktionieren.

Alternativ müsste man mal genau herausfinden, wo man in cDvbDevice "Hooks" oder "Callbacks" einbauen müsste, um Nicht-Kernel-Devices da unterbringen zu können.
Und so ein Patch müsste natürlich auch von Klaus akzeptiert werden.
</Offtopic>

Wenn der Sundtek-Treiber zusätzlich eine "Sat>IP"-Schnittstelle bietet, könnte sich die Hardware in eine allgemeine Lösung dann ja nahtlos einfügen.

Lars.