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

  • 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".

    Eine Schnittstelle dafür ist geplant. Aktuell hat jedoch die neue Hardware eine größere Priorität, wir haben alle Geräte überarbeitet und gehen damit direkt in Berlin in die Produktion.
    Die Software wurde die letzten Monate über bereits so angepasst das die alten Geräte weiterhin mit dem verfügbaren Installer supportet werden (sobald sich auf der Treiberebene etwas tut z.B Sat IP hinzustößt) wird dies dann auch mit den alten automatisch funktionieren.

  • 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".

    Quote


    Wäre der Treiber der Sundtek-Sticks Open Source könnte man ihn möglicherweise für Sat>IP und den Netceiver ausbauen.

    Was hält dich denn davon ab? Die Sticks supporten doch die offizielle DVB und Video4Linux API - nur halt mit dem Unterschied das wir die API unter Kontrolle haben da wir diese neu implementiert haben, zudem beeinflussen wir die lokale API nicht (sprich wir tauschen die lokalen vorhandenen Video/DVB Treiber nicht mit einem Paket von uns aus wie so manche andere) da wir parallel funktionieren.
    Somit müssen wir uns nicht mit den Kernel-DVB/V4L Maintainern rumschlagen um neue Features einzubauen - dies war in der Vergangenheit vor 5 Jahren ja schon eine unannehmbare Qual.

    Edited 2 times, last by Sundtek (October 18, 2013 at 1:39 PM).

  • 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.


    Das ist einfach unwahr. Sicher ist der Treiber closed source, aber das API ist offen und bekannt.

    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Somit müssen wir uns nicht mit den Kernel-DVB/V4L Maintainern rumschlagen um neue Features einzubauen


    Damit redet ihr euch doch nur raus. Andere haben komischerweise keine Probleme mit den Kernel-Maintainern.

    Mir sind bisher drei Hersteller bekannt, die sich weigern die Treiber an den Kernel durchzureichen.
    DVBSky (Treiber als Kernelpatch)
    Linux4Media (Alte Treiber sind schon im Kernel. Über ein Update dort wurde schon viel geredet, aber bisher ist nichts passiert)
    und Sundtek.

    Wobei die oberen beiden noch den Anstand haben, ihre Treiber unter GPL zu stellen.

    Dazu kommt ja noch, dass Hardwaretreiber grundsätzlich mal nichts im User Mode zu suchen hat. Das ist einfach falsch.

    VDR4Arch ➡️ Die VDR Distribution für Arch Linux

    Edited once, last by Copperhead (October 18, 2013 at 4:08 PM).

  • Bevor es jetzt wieder abgeht hier im Thread und die Emotionen hochschlagen: Bitte die Themen trennen in verschiedene Threads! Das Thema dieses Threads ist nicht die Treiberpolitik der Firma Sundtek. Dafür bitte einen eigenen Thread aufmachen, wenn nötig.

    Gruß
    hepi

    Aktuelle Kanallisten findet Ihr in der Channelpedia

  • Bevor es jetzt wieder abgeht hier im Thread und die Emotionen hochschlagen: Bitte die Themen trennen in verschiedene Threads! Das Thema dieses Threads ist nicht die Treiberpolitik der Firma Sundtek. Dafür bitte einen eigenen Thread aufmachen, wenn nötig.

    Gruß
    hepi

    Sehe ich genauso.
    Ich denke ein ganz guter Anfang ist sich mal so ein SAT>IP Server zu besorgen und auszuprobieren, was denn bisher damit schon möglich ist. Die DSI 400 von Grundig Sat Systems ist inzwischen für 131,90 inkl. Versand zu haben und stellt SAT>IP zertifiziert 4 Tuner ins Netz. Mal sehe, vielleicht fallen die Preise noch ein bischen dann werd ich mir mal was zum basteln kaufen.

    PS: braucht jemand noch eine Dockstar mit USB DVB-S2 Empfänger in einem eigenen Gehäuse :D ?

    Hardware: Seagate Dockstar@1500MHz, GSS Box DSI 400 SAT>IP Server, VDR 2.1.6 mit Streamdev-Server
    Videoausgabe: RaspberryPi mit MLD-4.0.1-RPi an LG 42LM660

  • Das Thema dieses Threads ist nicht die Treiberpolitik der Firma Sundtek. Dafür bitte einen eigenen Thread aufmachen, wenn nötig.


    Das sehe ich überhaupt nicht so. Wenn die Sundtek-Hardware wegen falscher Behauptungen aus diesem Thread gedrängt werden soll, dann kann man das sehr wohl in diesem Thread nicht gut finden.
    Technisch ist es überhaupt kein Problem einen Daemon zu schreiben der auf der einen Seite ein SAT>IP-Interface zur Verfügung stellt und auf der anderen Seite das DVB-API benutzt um an die Daten zu kommen.
    Solch ein Daemon hätte eben den Vorteil, dass er dann einfach mit jedem von Linux unterstützten Tuner läuft. Auch mit closed source Treibern! Hier überhaupt closed source zum Thema zu machen ist einfach lächerlich.

    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470


  • Das sehe ich überhaupt nicht so. Wenn die Sundtek-Hardware wegen falscher Behauptungen aus diesem Thread gedrängt werden soll, dann kann man das sehr wohl in diesem Thread nicht gut finden.

    Lies bitte meine Formulierung: Ich versuche nicht, die Diskussion über Sundtek-Hardware oder die SAT>IP-Fähigkeit des Sundtek-Treibers aus dem Thread zu drängen, sondern die politische Diskussion darüber, ob es gut oder schlecht ist, dass der Sundtek-Treiber nicht open source ist, also geht es mir nur um das Posting von Copperhead.

    Gruß
    hepi

    Aktuelle Kanallisten findet Ihr in der Channelpedia

  • Lies bitte meine Formulierung: Ich versuche nicht, die Diskussion über Sundtek-Hardware oder die SAT>IP-Fähigkeit des Sundtek-Treibers aus dem Thread zu drängen, sondern die politische Diskussion darüber, ob es gut oder schlecht ist, dass der Sundtek-Treiber nicht open source ist, also geht es mir nur um das Posting von Copperhead.


    Alles klar und ich habe nicht dich gemeint, sondern Mreimer und Copperhead, weil sie diese völlig irrelevante Diskussion über closed source überhaupt zum Thema gemacht haben. Die wollen closed source wegen dieser fadenscheinigen Begründung herausdrängen.

    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Man koennte das Pferd natuerlich gleich beidseitig aufzaeumen:

    1. SAT>IP Server fuer Linux (SAT>IP-Client spricht mit einem satipd auf einem Linux-Rechner mit DVB-Karte)
    2. DVBAPI Proxy zum Zugriff auf SAT>IP-Server (native DVBAPI-Applikation greift ueber ein pseudo-Device auf einen SAT>IP-Server zu)

    (1) haette den Vorteil, dass man z.B. der erwaehnten Dockstar mit USB DVB-S2 das SAT>IP-Protokoll beibringen koennte. Testen kann man das ganze dann recht einfach mit einem zertifizierten SAT>IP-Client z.B. mit dem dvbviewer light unter Windoofs.

    (2) wuerde dann die Anbindung an vdr, Myth-tv und Konsorten bringen.

    Beides zusammen haette dann den Charme, dass man das ganze auch testen kann, ohne dedizierte Hardware dafuer kaufen zu muessen.

  • 1. SAT>IP Server fuer Linux (SAT>IP-Client spricht mit einem satipd auf einem Linux-Rechner mit DVB-Karte)


    Genau das habe ich gemeint.

    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • 2. nennt sich vtuner .... (hat das mal jemand in letzter Zeit probiert ?)

    Zum Guggen: yavdr0.6 + Silverstone GD04 + Intel DH57DD + Intel G6950 + Nvidia GT630 + Unicable/Jess-Sat (JPS0501-12) mit DD/L4M Max8 + 4TB WD-red + bequiet SFX300W
    Zum Testen : yavdr-Ansible + GMC Toast + B365M+i3-8100+ Nvidia GT1030 + L4M CineS2v6 o. SAT>IP Plugin mit DD-O'net
    VaaS (VDR-as-a-Service): yavdr06 + ML03+DH67BL+G530+2GB RAM + 2TB WD-EARX + Zotac GT610 + L4M v5.4 + bequiet SFX300W
    Squeezeboxserver: DN2800ML im Streacom F1CS NAS: HP ProLiant MicroServer NL36+ Smart Array P212

  • 2. nennt sich vtuner .... (hat das mal jemand in letzter Zeit probiert ?)


    Eigentlich ist das eher 1., nur mit eigenem Protokoll, also der vtunerd. Erst der dazugehörige client macht es zu einem Proxy. Ich habe mal damit rumprobiert und auch ein paar Patches geliefert, aber die Lust verloren.
    Es gibt Pakete bei uns, aber den aktuellen Zustand kenne ich nicht.

    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470


  • Damit redet ihr euch doch nur raus. Andere haben komischerweise keine Probleme mit den Kernel-Maintainern.

    Mir sind bisher drei Hersteller bekannt, die sich weigern die Treiber an den Kernel durchzureichen.
    DVBSky (Treiber als Kernelpatch)
    Linux4Media (Alte Treiber sind schon im Kernel. Über ein Update dort wurde schon viel geredet, aber bisher ist nichts passiert)
    und Sundtek.

    Wobei die oberen beiden noch den Anstand haben, ihre Treiber unter GPL zu stellen.

    Dazu kommt ja noch, dass Hardwaretreiber grundsätzlich mal nichts im User Mode zu suchen hat. Das ist einfach falsch.

    Hast Du überhaupt die LKML Posting gelesen? Es geht hier um Netzwerktuner. Dafür sind erstmal keine "Hardwaretreiber" nötig, dafür hat man schon die Netzwerkkarte. Der Kerneltreiber macht im Moment nichts anderes (sowohl bei vtuner als auch Netceiver) als Pakete die aus dem Userspace kommen (vtunerd, mcli) auf ein virtuelles Interface (/dev/dvb) in den Kernelspace zu mappen um dann die Daten wieder einen Userspace-Prozess (vdr, mplayer, whatever) zugänglich zu machen. Warum? Nicht Perfomance (Wechsel zwischen User und Kernel sind eher resourcenintensiver) sondern schlicht und ergreifend Kompatibilität mit der DVBAPI. Ob ich jetzt Mauro in seiner Argumentation zustimme oder nicht (eher nicht, insbesondere finde ich die Begründung dämlich), *mir* ging es diesem Thread darum eine Langzeit-Stabile Lösung für Netzwerktuner zu finden. Wenn sich eine Firma findet die Linux-Treiber für ihr Produkt anbietet, egal ob Open Source oder nicht, tut sie das erstmal um ihr eigenes Produkt zu unterstützen. (Falls Du ein generelles Problem mit der Treiberpolitik von Sundtek hast, dann bitte einen eigenen Thread aufmachen)

    Wie man im Fall Netceiver sieht, kann man aber mal schnell in die Röhre gucken wenn die Firma Pleite ist (bzw. hielt sich vorher der Support auch schon arg in Grenzen) oder wenn eben wir bei Sundtek keine Open Source Treiber verfügbar sind. Ich will nicht (schon wieder) einige hundert Euro für eine Lösung investieren die dann mangels Treibersupport nicht mehr benutzbar ist! Deswegen hätte ich gern entweder einen Treiber im Mainline Kernel (fällt aus wegen Mauro) oder eben eine andere Lösung die das herstellerunabhängig und dann auch noch mit möglichst wenig Pflegeaufwand abbildet.

    Zum Thema "LD_PRELOAD ist blöd": Ja! Ist auch (wie von Mauro erwähnt) nur für Binary-only Software nötig, ansonsten kann man das ja prima per Library einbinden. Ich würde halt nur gerne eine universellere Library wählen anstatt einem vdr-plugin, Thema Benutzerbasis. Es spricht ja nichts dagegen, eine libdvbnet-wasauchimmer.so zu haben und dann wiederum ein vdr plugin was die Library einbindet. Dann erspart man sich LD_PRELOAD, hat aber trotzdem die Funktionalität potentiell für alle DVB-API kompatiblen Applikationen gewährleistet und nicht "nur" für den vdr.

    Sundtek würde ich übrigens hier auch als einen Kandidaten sehen. Wenn man die API kennt spricht ja nicht dagegen, dass unsere Universal-Library auch Sundtek unterstützt. Ebenso vtuner, könnte man auch als Quelle einbindern, wahrscheinlich sogar am einfachsten.

    Zum Thema Tuner-Intelligenz:
    Ich denke es gibt hier mehrere Anwendungsfälle, für einige kann es durchaus interessant sein Tuner auch ohne Intelligenz/Sharing-Möglichkeit zu zentralisieren. Mögliche Beispiele: fehlende Sat-Verkabelung am Einsatzort, Plattform ohne (vernünftiges) Interface zur Tuneranbindung, Virtualisierung.
    Daneben gibt es noch den Einsatz als hausinterne Kopfstation, da würde in der Tat Tuner/Transpondersharing Sinn machen. Das würde ich aber als Teil 2 sehen, weil das sicher (je nach Plattform) nicht unebdingt trivial zu implementieren ist.


    Wem die Idee nicht gefällt: Braucht sie auch nicht, insbesondere wer derartige Hardware nicht hat und nicht plant solche einzusetzen. Für alternative Vorschläge hingegen bin ich dankbar, aber die einzige "ernsthafte" die ich sehe ist noch ein (neben plain-dvbloop, Baytech-dvbloop, vtuner) out-of-tree Kerneltreiber der dann beim Update von 3.5 auf 3.6 oder 4.0 wieder nicht geht.

  • Ich hab letzte Nacht mal ein wenig mit CUSE rumprobiert.

    Das Kernelmodul laedt man mit

    Code
    modprobe cuse

    Hier ist ein Testprogramm, zum uebersetzen braucht man u.a. build-essential, kernel-headers und fuse-dev.

    Dann kann man das mit make uebersetzen und mit make devs die device-nodes fuer ein Userspace-Device anlegen (ich benutze hier major 250 minor 1 fuer /dev/dvb/adapter0/frontend0 und minor 2 fuer demux0).

    Anschliessend den Daemon mit

    ./dvbdevice -f

    starten und z.B. mit w_scan drauf zugreifen.

    Im Test ist das ioctl FE_GET_INFO schon funktionsfaehig integriert. FE_GET_PROPERTY und FE_SET_PROPERTY hab ich noch nicht ganz durchschaut. die anderen DVBAPI3-ioctls fuer das frontend zu implementieren ist jetzt erstmal Fleissarbeit.

    Die DVBAPI3 findet man hier: http://www.linuxtv.org/docs/dvbapi/dvbapi.html

    Ziel waere es natuerlich, dass der Daemon sowohl mit DVBAPI3 als auch DVBAPI5 funktioniert.

  • Hier ist ein Testprogramm, zum uebersetzen braucht man u.a. build-essential, kernel-headers und fuse-dev.


    Sehr cool! Packst du das eventuell nach github? Hätte große Lust das zu abonnieren.

    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Im Test ist das ioctl FE_GET_INFO schon funktionsfaehig integriert. FE_GET_PROPERTY und FE_SET_PROPERTY hab ich noch nicht ganz durchschaut. die anderen DVBAPI3-ioctls fuer das frontend zu implementieren ist jetzt erstmal Fleissarbeit.

    Die DVBAPI3 findet man hier: http://www.linuxtv.org/docs/dvbapi/dvbapi.html

    Ziel waere es natuerlich, dass der Daemon sowohl mit DVBAPI3 als auch DVBAPI5 funktioniert.


    Hi,
    gibts schon was Neues zum ausprobieren? Wenn man bei der "Fleißarbeit" mithelfen könnte, sag Bescheid.

    Meine ersten Versuche mit meinem neuen SAT>IP Receiver (GSS Box DSI 400) verliefen leider nicht komplett erfolgreich. Ein Transportstream läßt sich zwar mit dem IPTV Plugin über HTTP empfangen, aber leider fehlen die EPG Daten im Transportstream, der vom Gerät geliefert wird. Teletext und Untertitel werden einwandfrei angezeigt. Ich muss nochmal ausprobieren was passiert, wenn man nicht einzelne PIDs anfordert sondern das gesamte Bouquet streamen lässt. Ich denke ich werde mal versuchen einen kleinen RTSP client aus dem Internet so zu modifizieren, dass er mit meinem Sat>IP Server zusammenspielt. Wenn das funktioniert kann man sich mal überlegen, wie die RTSP Kommandos für den Sat>IP Server auf die DVBAPI gemappt werden können, so dass dieser sich transparent über einen solchen Treiber ansprechen läßt.

    Gruß Darkstar.

    Hardware: Seagate Dockstar@1500MHz, GSS Box DSI 400 SAT>IP Server, VDR 2.1.6 mit Streamdev-Server
    Videoausgabe: RaspberryPi mit MLD-4.0.1-RPi an LG 42LM660

  • Ziel waere es natuerlich, dass der Daemon sowohl mit DVBAPI3 als auch DVBAPI5 funktioniert.

    Hi,
    bist Du da schon weiter gekommen? Ich hab mir seit längerer Zeit das ganze mal wieder angesehen und mir auch Dein dvbdevice mal runtergeladen. Um zu verstehen wie die DVB Treiber funktionieren habe ich mir die Dokumentation auf linuxtv.org mal angesehen (http://www.linuxtv.org/downloads/v4l-dvb-apis/). Ich kann zwar nicht wirklich gut programmieren, aber so langsam habe ich das Gefühl, dass ich ein bischen durchblicke. Könnte man nicht das dummy dvb device aus dem v4l sourcetree nehmen als basis für die ganzen funktionsrümpfe? Soweit ich das sehe, sind da schon die ganzen ioctl als Funktionen definiert die dann in der fe_ioctl() Funktion nur noch dem Kommando entsprechend aufgerufen werden müssen. So hätte man zumindest schon mal die komplette Struktur und könnte diese dann mit Code füllen. Ich werde mal versuchen, ob ich das die nächsten Tage mal zum laufen bekomme.

    Gruß Darkstar.

    Hardware: Seagate Dockstar@1500MHz, GSS Box DSI 400 SAT>IP Server, VDR 2.1.6 mit Streamdev-Server
    Videoausgabe: RaspberryPi mit MLD-4.0.1-RPi an LG 42LM660

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!