[vtuner-ng] Aktualisierter vtuner für kernel >= 4.16

Zitat von M-Reimer

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!

Zitat von rell

Zu 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!

Zitat von pluto

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

Zitat von heifisch

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.

Die Anzahl der Tuner ist im vtuner Makefile hinterlegt und wurde schon vor einer Weile auf 8 gesetzt

Zitat von M-Reimer

Ä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"

Zitat von SHF

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 help

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

Zitat von M-Reimer

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.

Zitat von M-Reimer

Irgendeine 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!"

Zitat von M-Reimer

Und 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"

Zitat von SHF

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 vtunerc

Einfach 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.30

Einfach 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?