Nur der Vollständigkeit halber: Es geht rein theoretisch auch ohne zusätzliches Kernel-Modul. Hier hat sich mal jemand damit befasst:
https://github.com/not1337/libsatip
Fragt aber nicht wie der Stand dort ist und wie sich das Projekt im Vergleich zum hier diskutierten "vtuner" schlägt. Technisch gesehen ist "CUSE" eine Schicht unter "FUSE". Während FUSE nur für Filesystem-Treiber gedacht ist kann mit CUSE ein beliebiges "Character-Device" aus dem User-Mode heraus erzeugt werden.
Nur der Vollständigkeit halber: Es geht rein theoretisch auch ohne zusätzliches Kernel-Modul. Hier hat sich mal jemand damit befasst:
https://github.com/not1337/libsatip
Fragt aber nicht wie der Stand dort ist und wie sich das Projekt im Vergleich zum hier diskutierten "vtuner" schlägt. Technisch gesehen ist "CUSE" eine Schicht unter "FUSE". Während FUSE nur für Filesystem-Treiber gedacht ist kann mit CUSE ein beliebiges "Character-Device" aus dem User-Mode heraus erzeugt werden.
Danke für den Link, habe ich mir (teilweise) angeschaut. Dort läuft es im Endeffekt ähnlich wie beim vtuner - nur wird eben CUSE verwendet, also die Daten gehen kurz in die Kernelebene um dann diese wieder zu verlassen. Nur das bei Verwendung von CUSE auch das komplette Frontend-Handling und der Demuxer in Userspace läuft. Etwas negativ überrascht war ich von einem Bug in CUSE von kernel v5.0 bis v5.3 (!) der scheinbar keinem aufgefallen ist. Scheint also nicht sonderlich weit verbreitet zu sein dieses CUSE.... Aber ausprobieren werde ich das schonmal!
Quote from rellZu welchem Setup mit vtuner würdet ihr mir raten? Brauchts das auf allen Maschinen oder reicht der Server und ich verteil dann wieder?
Bei deinem Setup wird es mir ganz schwindelig. Also vtuner ersetzt im Endeffekt nur das satip-plugin - und zwar nur die standardkonforme Variante ohne minisat oder octopus Erweiterungen. Wer mit dem satip-plugin zufrieden ist sollte IMHO einfach alles so lassen wie es ist!
Quote from plutoSollte ich bei DVB-C noch etwas beachten?
Ja, die Unterstützung dafür gibt es erst seit heute Abend 21:00 Uhr 
Bin diesmal mit der Axt durch das satip-Programm gegangen und habe die Art und Weise wie die Parameter zusammengeklaubt wurden komplett vereinfacht. Das kam noch durch die alte vtuner Struktur. Dort wurde einfach jeder einzelne Befehl (SET_TONE, SET_VOLTAGE, etc. pp.) durchgereicht. Die habe ich schon vor ein paar Tagen im vtuner beerdigt. Jetzt kommt im Endeffekt noch ein SET_FRONTEND und danach noch ein paar MSG_PIDLISTs und das war es auch schon. Schön schlank und schnell.
Zusätzlich ist es jetzt möglich das satip-Programm zu beenden und erneut zu starten. Der vdr sychronisiert sozusagen wieder auf, zuvor wurde im vtuner nicht mehr richtig getuned.
Wer bestimmte Ports für die RTP/RTSP-Verbindungen braucht um die durch eine Firewall zu schicken kann das jetzt bei satip mit -r angeben. Dann wird der angegebene Port (und Port +1) für die RTP/RTSP-Verbindungen verwendet.
Überhaupt habe ich dem Programm mal eine usage spendiert die ausgegeben wird wenn man es ohne Argumente aufruft.
Ja, die Unterstützung dafür gibt es erst seit heute Abend 21:00 Uhr
Ja, die Unterstützung dafür gibt es erst seit heute Abend 21:00 Uhr
Hier gibt es mit der Version einen Fehler beim kompilieren:
rm /usr/local/bin/satip
rm -f satip *.o *~
cc -Wall -g -c -o satip_rtp.o satip_rtp.c
cc -Wall -g -c -o satip_vtuner.o satip_vtuner.c
cc -Wall -g -c -o satip_config.o satip_config.c
satip_config.c: In Funktion »satip_prepare_tuning«:
satip_config.c:301:36: Fehler: »SYS_DVBC2« nicht deklariert (erstmalige Verwendung in dieser Funktion); meinten Sie »SYS_DVBT2«?
301 | cfg->delsys == SYS_DVBC2 ? "dvbc2" : "dvbc",
| ^~~~~~~~~
| SYS_DVBT2
satip_config.c:301:36: Anmerkung: jeder nicht deklarierte Bezeichner wird nur einmal für jede Funktion, in der er vorkommt, gemeldet
make: *** [<eingebaut>: satip_config.o] Fehler 1Nur der Vollständigkeit halber: Es geht rein theoretisch auch ohne zusätzliches Kernel-Modul. Hier hat sich mal jemand damit befasst:
https://github.com/not1337/libsatip
Fragt aber nicht wie der Stand dort ist und wie sich das Projekt im Vergleich zum hier diskutierten "vtuner" schlägt. Technisch gesehen ist "CUSE" eine Schicht unter "FUSE". Während FUSE nur für Filesystem-Treiber gedacht ist kann mit CUSE ein beliebiges "Character-Device" aus dem User-Mode heraus erzeugt werden.
Zu Cuse - wir haben es mal getestet und es war instabil außerdem war's nicht überall per default verfügbar, mag sein dass es mittlerweile gefixt wurde aber zu der Zeit als wir es getestet haben war es unbrauchbar. Im Allgemeinen wäre es besser ein DVB Library zwischen device Nodes und Applikationen zwischenzuschieben dann wird der Code auch nahezu automatisch Betriebssystem-unabhängig.
Wir haben in unseren Treiber Hooks welche es erlauben die Transportstream Daten innerhalb der Treiberdomain an libraries weiterzuleiten und dann wieder in den Treiber zurückzuschleifen.
Soweit ich mich erinnere wurde das vor langer Zeit für ISDB-T in Japan implementiert, der Tuner empfängt die verschlüsselten Daten und der Transportstream wird im Treiberprozess direkt dekodiert.
Wenn jemand nen Sundtek Tuner hat, und sich dafür interessiert kann ich das Gerüst für so n Library gern mal ausgraben. Zudem das auch wieder Kernel-Version unabhängig ist.
Hier gibt es mit der Version einen Fehler beim kompilieren
Interessant, bei mir ist das trotz kernel 5.4.118 in /usr/include/linux/dvb/frontend.h enthalten obwohl es erst ab kernel 6.2 hinzugefügt wurde. Lustig auch das sich die DVB-Api Version nicht geändert hat. Da darf man dann selber auf Suche gehen seit wann es das gibt. Na egal, ich hab' ein #define dazugebastelt, müsste jetzt durchlaufen.
Eine Frage habe ich noch die den Server betrifft. Ist die Anzahl der Tuner fest auf 4 'in Stein gemeißelt' oder kann man ggflls. auch 8 Tuner nutzen?
Eine Frage habe ich noch die den Server betrifft. Ist die Anzahl der Tuner fest auf 4 'in Stein gemeißelt' oder kann man ggflls. auch 8 Tuner nutzen?
Ich antworte mal, Du kannst mit dem Laden des Kernel-Modules die Anzahl der vtuner-Devices festlegen, musst aber dann auch entsprechend viele satip-Prozesse starten. Ich habe es hier mal mit 8 probiert.
Ob es eine Grenze gibt, kann sicher Joe_D beantworten.
Technisch gesehen ist "CUSE" eine Schicht unter "FUSE". Während FUSE nur für Filesystem-Treiber gedacht ist kann mit CUSE ein beliebiges "Character-Device" aus dem User-Mode heraus erzeugt werden.
Danke, das ist das Stichwort! Das war's, was ich die ganze Zeit im Hinterkopf hatte.
Keine Ahnung, warum ich da nicht schon längst drauf gekommen bin, wo ich FUSE doch beinahe täglich benutze.
Dort läuft es im Endeffekt ähnlich wie beim vtuner - nur wird eben CUSE verwendet, also die Daten gehen kurz in die Kernelebene um dann diese wieder zu verlassen. Nur das bei Verwendung von CUSE auch das komplette Frontend-Handling und der Demuxer in Userspace läuft.
Der Unterschied für mich ist, dass es vtuner bedauerlicherweise nicht in den Kernel geschafft hat.
Auch wenn Joe_D sicher gute Arbeit geleistet hat und ich für die vtuner-Option auch dankbar bin (und ich es in der Situation wohl genauso angegangen wäre 
), wirkt die Aussicht immer Kernelmodule bauen zu müssen halt etwas abschreckend.
Etwas negativ überrascht war ich von einem Bug in CUSE von kernel v5.0 bis v5.3 (!) der scheinbar keinem aufgefallen ist. Scheint also nicht sonderlich weit verbreitet zu sein dieses CUSE....
Zur Verbreitung von CUSE kann ich nichts sagen, aber FUSE Filesysteme nutze ich schon einen Ewigkeit und hatte nie irgendwelche Probleme damit.
Da gibt es auch einige Anwendungen, schon Truecrypt nutzte es Beispielsweise.
Die Kernel v5.0 bis v5.3 scheinen aber generell nicht besonders verbreitet gewesen zu sein. Keiner ist LTS und Debian ist von 4.19 direkt auf 5.10 gegangen.
Und ausserdem nutzt man doch so eine stabile Schnittstelle wie CUSE um nicht dauernd die Kernelentwicklung verfolgen zu müssen.
Könnte man das vtuner Kernelmodul nicht DKMS'isieren? Könnte dem Build den Schrecken nehmen ...
Ändert halt nichts daran das die Kernelschnittstellen nicht stabil sind. Zumindest bei Arch sehe ich von zusätzlichen Kernelmodulen immer ab. Man könnte auf den LTS Kernel wechseln, was die Situation natürlich entschärft, aber ich nutze lieber den aktuellsten Kernel.
Ändert halt nichts daran das die Kernelschnittstellen nicht stabil sind. Zumindest bei Arch sehe ich von zusätzlichen Kernelmodulen immer ab. Man könnte auf den LTS Kernel wechseln, was die Situation natürlich entschärft, aber ich nutze lieber den aktuellsten Kernel.
Hier bin ich sehr überrascht das es seit dem Kernel 4.16 (1.4.2018) bis heute nur 3 Änderungen gab: bei 5.6 (Umbenennung im chardev), 5.17 (Groß-/Kleinschreibung im chardev) und 6.4 (Parameteränderung im chardev).. im DVB-Teil hat sich seit 4.16 nix "getan"
Zur Verbreitung von CUSE kann ich nichts sagen, aber FUSE Filesysteme nutze ich schon einen Ewigkeit und hatte nie irgendwelche Probleme damit.
CUSE ist sozusagen der bucklige Verwandte von FUSE. Während FUSE aktiv von vielen Leuten verwendet wird ist CUSE IMHO eine "mitgeschleiftes" Feature das eben bei FUSE links hinten rausfiel. CUSE kenne ich, obwohl ich schon ewig mit linux "rummache" erst seit zwei Tagen 
Im Gegensatz zu FUSE, das mir seit NTFS-3G von 2007 ein Begriff ist.
Ich habe mir auch mal libsatip angeschaut. Eigentlich schade um die viele Mühe, die dort hineingesteckt wurde. Kompilieren konnte ich das auf meiner arch64-Umgebung fast ohne Eingriffe, bis auf die libffdecsa die hier mitgeliefert wurde (müsste eben durch die libdvbcsa ersetzt werden) - habe ich aber einfach links liegen gelassen.
Im Gegensatz zu vtuner und satip ist hier leider nichts mit "ich starte mal und schaue was passiert". Also z.B. in dmesg oder syslog. Oder, ich schau' mal kurz in den Code und weiß für was es ist (so bin ich z.B. bei vtuner und satip vorgegangen als satip z.B. nur ausgab: "missing host name").
Nach dem kompilieren erhält man einen Sack voll Programme deren Sinn und Zweck aus dem Namen erraten werden muss: satiploopd, satipprog, satipscan, satipd, satipdctl, satipdetect, satipinfo, satipmcast, satipipe, satipsink, satipzap. satipdetect hat tatsächlich meinen Satip-Receiver gefunden. Das sowas im satip-Programm nicht drin ist finde ich ziemlich unwichtig.
Ich denke satiploopd erstellt die DVB-Adapter, aber aus der usage ist das nicht zu erkennen:
Usage: satiploopd [-c <config-file>] [-d] [-x] [-h]
-c <config-file> configuration file, default /etc/satiploopd.conf
-d daemonize
-x print overrun statistics (disables '-d')
-h this helpMan braucht zwingend ein Configfile, das nur so vorliegt (gekürzt!):
#satiploopd configuration file.
#
#There must be one [global] section.
#There must be one to thirtytwo [device] sections.
#There must be zero to thirtytwo [tuner] sections.
#
#[global]
#rtprio=0-99 streaming thread priority, 0=off, 1-99 real time
#level=0-2 0=IPv4, 1=0+IPv6 link layer, 2=1+IPv6 ULA addresses
#dev=device ethernet device, no default
#mttl=1-255 multicast ttl, default 2
#portmin=1024-65534 udp minimum port number, even<portmax, default 1024
#portmax=1025-65535 udp maximum port number, odd>portmin, default 65535
#rtpbuffer=32768-1048576 rtp buffer size in bytes, default is system default
#strict=0-1 enforce strict SAT>IP query syntax compliance if 1
#fast=0-1 network receive without small delay if 1 (costs cpu)
#
#[tuner]
#deviceid=1-65535 SAT>IP tuner device id, mandatory
#adapter=0-255 dvb adapter number, default 0
#frontend=0-255 dvb frontend device number, default 0
#demux=0-255 dvb demux device number, default 0
[...]
#noshare=0-1 do not allow multiple clients for same transponder if 1
#fast=0-1 tuner read without small delay if 1 (costs cpu)
#source=1-255[,...] source group(s) the tuner belongs to
#
#[device]
#adapter=0-255 CUSE dvb adapter number, default 0
#major=0-8191 CUSE device major
#minbase=0-252 CUSE device minor base, multiple of 4
#owner=0-65535 CUSE device owner, default 0 means no change
[...]
#lnbpower=0-1 if 1 stop streaming if lnb powerdown ioctl received
#local=0-1 if set use local tuner device as frontend
#port=1-65535 SAT>IP server rtsp port, default 554
#uuid= SAT>IP server UUID, overrides 'host=', see satipdetect
#host= SAT>IP server host name or IP
#plugin= optional plugin library pathname
#plugcfg= optional plugin library configuration file
#list of SAT>IP transponder queries with leading '?' and 'pids=none' for which
#no pids are passed to the device user, example:
#?src=1&freq=11611.750&pol=h&msys=dvbs&mtype=qpsk&sr=22000000&fec=56&pids=none
#
#Signals:
#HUP,INT,TERM terminates the program
#USR1 prints current tuning data to stderr
#Supergeil, kann ich mir zu jeder Einstellung selbst überlegen was ich da eintragen soll oder was nicht, oder für was ich das brauche. Oder ob ich die Einstellung überhaupt brauche, viel Spass beim Ausfüllen von sowas. Wenn ich total viel Zeit habe werde ich das mal ausprobieren. Aber eher nicht. 
Was ich zusätzlich nicht so dolle finde ist die enge Bindung an satip. Warum? Wieso? Weshalb? Warum gibt es nicht ein Progrämmchen das nur Standard-Adapter und eine schlanke Schnittstelle zur Verfügung stellt und die Möglichkeit "auch" satip-Receiver anzubinden? Oder eben einen HLS-Stream (habe ich noch vor!)..
Warum gibt es hier nicht Default-Settings wie bei vtuner/satip? 
Da bleibe ich erstmal bei vtuner und satip 
- trotz Kernel Modul...
Nach dem kompilieren erhält man einen Sack voll Programme deren Sinn und Zweck aus dem Namen erraten werden muss: satiploopd, satipprog, satipscan, satipd, satipdctl, satipdetect, satipinfo, satipmcast, satipipe, satipsink, satipzap.
Da hat aber jemand das Unix-Prinzip von "ein Programm soll nur eine einzelne Aufgabe erledigen" auf die Spitze getrieben. 
CUSE ist eigentlich ganz gut nutzbar, aber das Problem ist, dass nicht jede Distri dafür per default Unterstützung im Kernel hat, zumindest war das früher so.
Ich habs seinerzeit mal ausprobiert, als ich mit Satip angefangen hab, aber man programmiert ja quasi alles neu..
Sehe schon ein das man da Aufwand einspart, weil Mechanismen aus dem Kernel dann vom Usermode-Treiber genutzt werden können.
Bevor ich aber mit "Out Of Kernel-Treibern" arbeite würde ich mir bei Bedarf vermutlich eher das satip-Plugin mal näher anschauen. Irgendeine Library wird das hier genutzte "satip" ja wohl auch nutzen. Und ziemlich sicher kann man das satip-Plugin auch darauf umstellen.
Hallo,
Ich hebe den vtuner aktuell im Einsatz, vorher satip plugin.
Läuft ohne auffälligkeiten, Umschaltzeiten sind bei mir im Vergleich zum Plugin gleich geblieben.
Beim Plugin hatte ich ab und zu das Problem das beim Umschalten kein Bild kam, das ist hier bisher nicht aufgetreten.
Als Server nutze ich minisatip.
Peter
Bevor ich aber mit "Out Of Kernel-Treibern" arbeite würde ich mir bei Bedarf vermutlich eher das satip-Plugin mal näher anschauen.
Ja das habe ich - und ich habe dort ja schon auskommentierten Code wieder einkommentiert, wie ja schon hier beschrieben.
Quote from M-ReimerIrgendeine Library wird das hier genutzte "satip" ja wohl auch nutzen.
Denkste! mc.fishdish hat das tatsächlich nur mit socket, send, recv und poll gemacht. Dermaßen genial. Es funktioniert einfach. Und es wurde für das SAT>IP Protokoll geschrieben. Nicht wie bei curl wo man mir gleich mal sagte "hey, wir unterstützen eigentlich RTSP nach RFC7826 und nicht SAT>IP". Und nachdem ich extra Programme basteln musste um den Fehler nachzuweisen gab es erstmal ein Schulterzucken ("I don't sense a lot of interest from peeps to work on this") und ein "known Bugs" Label anstatt, "Hey ist ja nur eine Zeile ändern - wird sofort gefixed!"
Quote from M-ReimerUnd ziemlich sicher kann man das satip-Plugin auch darauf umstellen
Ehrlich, um eine Version zu erhalten die SETUP -> PLAY -> [keepAlive OPTION] PLAY [bei Kanalwechsel] macht anstatt SETUP -> PLAY -> OPTION [wie wild] -> DESCRIBE [immer wieder] -> TEARDOWN [bei jedem Kanalwechsel].. müsste ich meinen Code in alten Code hineinwurschteln der Quirks hier und da hat und für meine Version sozusagen einige neue Quirks einfügen. Dabei immer schön darauf achten das ich dabei nix kaputt mache... Das kann gerne jemand anders machen, mir ist das "way too much"
Könnte man das vtuner Kernelmodul nicht DKMS'isieren? Könnte dem Build den Schrecken nehmen ...
Das sollte an sich kein großes Ding sein. Vor Jahren hatte ich das schon mal mit den DVB-Sky-Treibern gemacht, bevor die im Kernel waren .
Lästig ist, dass es nach meiner Erfahrung immer mal wieder, aus den unterschiedlichsten Gründen, hakt, wenn man es überhaupt nicht brauchen kann.
(Aktuelle Kernelquellen beim Update nicht mit installiert, Compiler aus den Backports macht Probleme, ...)
CUSE kenne ich, obwohl ich schon ewig mit linux "rummache" erst seit zwei Tagen
Ich dachte, das ist bekannter. Ich kenne es aus einem Artikel oder Vortrag über Userspace Device Drivers, den ich vor Urzeiten mal gelesen/gehört habe. Thematik waren die Möglichkeiten, FUSE, CUSE, UCI, ... bieten. Lediglich der Begriff war mir zwischenzeitlich entfallen.
Was ich zusätzlich nicht so dolle finde ist die enge Bindung an satip. Warum? Wieso? Weshalb? Warum gibt es nicht ein Progrämmchen das nur Standard-Adapter und eine schlanke Schnittstelle zur Verfügung stellt und die Möglichkeit "auch" satip-Receiver anzubinden? Oder eben einen HLS-Stream (habe ich noch vor!)..
Die Bindung an SATIP scheint der Focus dieser Lib zu sein.
Die Progrämmchen sind laut der (ausbaufähigen ) Doku auch nur "example applications".
satiploopd scheint die komplette, nach programmierte DVB Frontend/Demux Ansteuerung zu beinhalten. (Zumindest sah es bei meinem überfliegen recht vollständig aus.)
Evtl. macht es mehr Sinn auf der Basis einen vtuner-daemon zu bauen?
Evtl. macht es mehr Sinn auf der Basis einen vtuner-daemon zu bauen?
Ja, nur zu - jetzt haben ja die meisten Weihnachtsurlaub. Bis wann kann ich mit einer Version rechnen? Ich passe dann die satip-Schnittstelle darauf an!
Versteht mich nicht falsch aber langsam finde ich es echt drollig wieviele Beiträge sich hier nicht mit vtuner-ng befassen sondern ausschließlich darum wie man "irgendwas mit DVB" im Userspace umsetzen kann. Ja Leute auf! Der gute Herr Steinmetz hat das in einem Monsterfile names satiploopd.c mit 132k Sourcecode gemacht. Leider nicht mit offener Schnittstelle wie bei vtuner (vtuner hat gerade mal zwei ioctls: MSG_SET_FRONTEND, MSG_PIDLIST) sondern eng verbandelt mit irgendwelchem satip Zeug.
Also wenn ich mir dann was wünschen darf, dann sollte das DVB-Userspace-Zeug auch mit sinnvollen Default-Einstellungen daherkommen. Wie z.B. bei vtuner-ng:
modprobe vtunercEinfach Aufrufen und schon hat man einen Adapter unter /dev/dvb, kein großen Gerätsel wie bei satiplib mit was und wo...
satip -h 10.15.10.30Einfach Aufrufen und schon wird der Adapter unter /dev/dvb mit Daten vom satip-Receiver mit der ip 10.15.10.30 beliefert.
Kann für "DVB userspace" oder "DVB loop" oder wie Ihr das auch wollt nicht ein eigener Beitrag gemacht werden?
Don’t have an account yet? Register yourself now and be a part of our community!