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

    Hallo Zusammen,


    da ich meine liebe Not mit dem vdr-plugin-satip hatte (Beitrag) und auch die gleichen Probleme mit Aufnahmen wie andere (Beitrag) hatte, habe ich mich nach Alternativen dazu umgeschaut.


    Gefunden habe ich den 13 Jahre alten vtuner von Honza Petrous und das 9 Jahre alte satip von mc.fishdish. Netterweise wurde der alte vtuner schonmal von jemand anders auf linux 4.x / 5.x portiert. Und auch das satip Programm war so schön standardkonform geschrieben das es sich ohne Probleme übersetzten lies.


    Ich habe das mal als Grundlage genommen und mir genauer angeschaut. Vieles war total umständlich umgesetzt, keine Ahnung warum - ich denke es war dem DVBAPI3 geschuldet.

    Viele Aufrufe wurden 1:1 durchgereicht was zu 16 internen Meldungen und 7 ioctls führte. Auch im satip-Programm wurde deshalb ein Bitfeld eingebaut mit dem dann geprüft wurde ob schon alle Parameter empfangen wurden =O


    Daraus ist nun vtuner-ng, vtuner 2.0 geworden. Ich habe dort mal mit der Axt ziemlich gewütet, den Support für kernels < 4.16 entsorgt und die Meldungen auf 2 (MSG_SET_FRONTEND, MSG_PIDLIST) und die ioctls auf 3 (VTUNER_GET_MESSAGE, VTUNER_SET_RESPONSE, VTUNER_SET_SIGNAL) gekürzt. Im satip-Programm ist das tunen auch um einiges vereinfacht worden, denn nun werden alle Parameter auf einmal mit MSG_SET_FRONTEND übergeben. Zudem empfängt das satip-Programm manchmal leere RTP-Pakete mit 12 Bytes. In dem Fall schiebe ich dann ein selbstgebasteltes Filler-Paket ohne Payload mit AdaptionOnly (keine Fields), der PID 0x1FFF und 0xFF als Adaptionfiller. Besonderheit solcher Pakete ist, das der Continuity-Counter nicht hochgezählt werden muss. Im VDR habe ich zuvor noch des öfteren "TS-Stream broken" gesehen... bislang nicht mehr..


    Anstatt wie früher das Frontend erst beim Öffnen des vtuner-Devices anzulegen wird es nun als Multi-DVB Frontend nach dem Laden des Moduls angelegt.


    Im VDR wird das dann so erkannt:

    Code
    Dec  9 18:02:32 server vdr: [1229] frontend 0/0 provides DVB-T,DVB-C,DVB-S,DVB-S2 with QPSK,QAM16,QAM64,QAM128,QAM256 ("vTuner proxyFE DVB-Multi")
Dec  9 18:02:32 server vdr: [1229] frontend 1/0 provides DVB-T,DVB-C,DVB-S,DVB-S2 with QPSK,QAM16,QAM64,QAM128,QAM256 ("vTuner proxyFE DVB-Multi")
Dec  9 18:02:32 server vdr: [1229] frontend 2/0 provides DVB-T,DVB-C,DVB-S,DVB-S2 with QPSK,QAM16,QAM64,QAM128,QAM256 ("vTuner proxyFE DVB-Multi")
Dec  9 18:02:32 server vdr: [1229] frontend 3/0 provides DVB-T,DVB-C,DVB-S,DVB-S2 with QPSK,QAM16,QAM64,QAM128,QAM256 ("vTuner proxyFE DVB-Multi")


    Was natürlich auch ginge aber bislang nicht so programmiert ist, das Frontend ohne bestimmtes DeliverySystem anzulegen und das dann inkl. Parameter (oder Defaults) per ioctl auszuwählen.

    Theoretisch wären dann so Sachen möglich einem Frontend min./max. Frequenzen zuzuweisen die es im "normalen DVB-T/C/S/S2" nicht gibt. Dann einen Kanal dafür in der channels.conf erstellen und per satip z.B. einen RTSP-Webcam-Stream holen lassen (sind das auch TS-Streams oder was anders? Kenn' mich da nicht aus). Theoretisch müsste der bestimmte Kanal dann das Bild der Webcam anzeigen...


    Zur Zeit habe ich das aber nicht so gemacht damit die Frontends vom VDR erstmal angenommen werden auch wenn auf der "anderen Seite" noch niemand den virtuellen Tuner bedient...


    Das Device und die zugehörigen Verbindungen lasse ich vor dem Start vom VDR starten:

    Code
    /usr/sbin/modprobe vtunerc devices=4
/usr/local/bin/satip -h 10.15.10.30 -d /dev/vtunerc0 -m 2 -l 4 2> /tmp/satip0.log &
/usr/local/bin/satip -h 10.15.10.30 -d /dev/vtunerc1 -m 2 -l 4 2> /tmp/satip1.log &
/usr/local/bin/satip -h 10.15.10.30 -d /dev/vtunerc2 -m 2 -l 4 2> /tmp/satip2.log &
/usr/local/bin/satip -h 10.15.10.30 -d /dev/vtunerc3 -m 2 -l 4 2> /tmp/satip3.log &


    Im proc-Verzeichnis wird dann für jeden Adapter eine Datei angelegt:

    Code
    -r--r--r--   1 root                 0 Dec  9 18:05 vtunerc0
-r--r--r--   1 root                 0 Dec  9 18:05 vtunerc1
-r--r--r--   1 root                 0 Dec  9 18:05 vtunerc2
-r--r--r--   1 root                 0 Dec  9 18:05 vtunerc3


    Wenn der VDR dann läuft und das satip-Programm etwas zurückliefert sieht der Inhalt vom vtunerc0 z.B. so aus:

    Last change z.B. gibt an seit wievielen Sekunden der letzte MSG_SET_FRONTEND Befehl zum tunen kam, bei EPG-Frontends hab' ich hier noch nie mehr als 20 Sekunden gesehen ;)

    Ansonsten gebe ich halt die Tuning-Parameter aus die geschickt wurden. PID-Tabelle und TS data-Zähler gab es auch schon früher...


    Wenn das satip-Programm wie oben aufgerufen wird, werden die RTSP-Ausgaben ins tmp-Verzeichnis geloggt, das sieht dann in etwa so aus:

    Ich hab' das Log gekürzt, es ist im Original viel ausführlicher... Da hier kein curl verwendet wird sondern alles in Hand programmiert wurde (nicht von mir), werden auch sämtliche Antworten vom satip-Server gelesen. Bei Fehlern beim SETUP warte ich jetzt 65 Sekunden - oftmals war einfach der Receiver noch belegt. Beim Beenden von satip habe ich einen TEARDOWN eingebaut den es zuvor nicht gab. Der hat auch dazu geführt das der Receiver beim nächsten Start noch belegt war.


    Was auch geht ist den TS-Stream aus dem virtuellen Device auszugeben, dazu muss nur das vtuner-Device gelesen werden, z.B. so:

    Code
    cat /dev/vtunerc0 > /tmp/stream.ts


    Dann kann der Stream z.B. mit

    Code
    dvbsnoop -s ts -if /tmp/stream.ts -n [packetcount]

    analysiert werden.


    Bislang läuft das bei mir recht stabil, ab und an aber habe ich Probleme mit der Ausgabe - dann muss ich den Kanal wechseln. Aber das könnte auch am xineliboutput-Plugin liegen.


    Sogar Aufnahmen werden ohne Fehler gemacht (naja, war vielleicht Glück):

    Code
    Dec  9 18:40:00 server vdr: [1229] timer 78 (47 1730-1840 'Serien~Mord ist ihr Hobby~Der tödliche Stromschlag') finished with 0 errors


    Bei mir wurde der kernel leider mit folgender Option übersetzt:

    Code
    CONFIG_DVB_DEMUX_SECTION_LOSS_LOG=y


    Das führt im Log zu sehr vielen Meldungen dieser Art:

    Code
    [ 3318.131173] dvb_demux: dvb_dmx_swfilter_section_packet: discontinuity: 8 instead of 5. 188 bytes lost
[ 3318.295006] dvb_demux: dvb_dmx_swfilter_section_packet: discontinuity: 9 instead of 2. 188 bytes lost
[ 3318.527785] dvb_demux: dvb_dmx_swfilter_section_packet: discontinuity: 11 instead of 9. 188 bytes lost
[ 3319.059178] dvb_demux: dvb_dmx_swfilter_section_packet: discontinuity: 5 instead of 11. 188 bytes lost
[ 3319.405629] dvb_demux: dvb_dmx_swfilter_section_packet: discontinuity: 6 instead of 12. 188 bytes lost
[ 3319.450269] dvb_demux: dvb_dmx_swfilter_section_packet: discontinuity: 8 instead of 6. 188 bytes lost

    Das liegt daran das die TS-Pakete einfach durchgeschoben werden. Eine Abhilfe könnte sein für jede empfangene PID auf den PUSI-Marker zu warten und zwischendurch Filler-Pakete zu senden. Dann müsste ich mir aber für jede PID merken ob schon mal der PUSI-Marker da war. Mal schauen ;)


    [Edit] Abgelegt ist das Ganze hier auf github

    Hi,

    das läuft hier bei mir tatsächlich problemlos auf Anhieb. Ich starte seit gestern meinen headless mit 3 Tunern und den Client mit einem und erspare mir das vdr-plugin-satip, die Zwischeninstanz "minisatip" und spreche nun die OctopusNet direkt an. Ich nutze das "böse Plugin für bestimmte Sender".


    Läuft im Moment sehr sauber ich teste damit weiter! :thumbup:


    Was macht der Parameter -m?


    Starten tut das Ganze ja auch ohne:

    Code
    /usr/local/bin/satip -h 10.15.10.30 -d /dev/vtunerc0 &

    Ich fürchte, dass ich das alles nicht richtig verstehe...

    Das satip binary übernimmt die Aufgabe von minivdr und stellt satip-Streams unter den virtuellen dvb-devices bereit ?

    Wie sieht die Lösung für eine Einbindung in den vdr ohne das satip-Plugin konkret aus? Wie sehen die Einträge in der channels.conf aus, wie wird dem satip-Programm mitgeteilt, welchen Sender es bereitstellen soll?

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    Wenn das Modul geladen ist und die einzelnen satip-Instanzen gestartet sind ist/war hier nichts weiter an Änderungen notwendig... - Läuft!

    Es besteht aus 2 Komponenten, das vtunerc Kernelmodul und das Programm satip


    Zitat

    /usr/sbin/modprobe vtunerc devices=4

    /usr/local/bin/satip -h 10.15.10.30 -d /dev/vtunerc0 -m 2 -l 4 2> /tmp/satip0.log &

    /usr/local/bin/satip -h 10.15.10.30 -d /dev/vtunerc1 -m 2 -l 4 2> /tmp/satip1.log &

    /usr/local/bin/satip -h 10.15.10.30 -d /dev/vtunerc2 -m 2 -l 4 2> /tmp/satip2.log &

    /usr/local/bin/satip -h 10.15.10.30 -d /dev/vtunerc3 -m 2 -l 4 2> /tmp/satip3.log &


    Aber ich möchte mich nicht mit Halbwissen reindrängeln ;) Joe_D kann es besser erläutern und sollte es auch...

    Funtioniert aber sehr sauber. Mal sehen was der Langzeittest zeigt (Serienaufnahmen)

    Ja ich dachte vtuner wäre Allgemeinwissen :)


    vtuner ist ein kernel device Treiber der virtuelle DVB-Devices zur Verfügung stellt - also z.B.:

    Code
    /dev/dvb/adapter0/frontend0
/dev/dvb/adapter0/demux0
/dev/dvb/adapter0/dvr0


    Zusätzlich erstellt vtuner noch ein Steuerungdevice:

    Code
    /dev/vtunerc0


    Anfragen an die virtuellen DVB-Devices werden dann intern an das Steuerungsdevice übergeben.


    Am Steuerungsdevice muss ein Programm die Anfragen entgegennehmen und einen TS-Stream per write ins Steuerungsdevice zur Verfügung stellen.


    Dafür ist das satip-Programm. Es verbindet sich auf der einen Seite mit einem SatIP-Receiver und auf der anderen Seite mit dem vtuner Steuerungsdevice. Wenn der Befehl zum Empfang eines Senders kommt versucht das satip-Programm das vom SatIP-Receiver zu holen und schickt den Stream zum DVB-Device.


    Und ja, dann braucht man kein satip-plugin mehr. Und ja das funktioniert auch mit irgendeinem Programm das DVB-Devices verwenden möchte (tvheadend, szap, ...)

    Zitat von Taipan

    Was macht der Parameter -m?


    Starten tut das Ganze ja auch ohne:

    Code
    /usr/local/bin/satip -h 10.15.10.30 -d /dev/vtunerc0 &

    Ja, satip hat keine usage-Ausgabe - die muss ich wohl mal hinzufügen.


    Mit -l kann das Debuglevel angegeben werden:

    Code
    #define MSG_ERROR	1
#define MSG_WARN	2
#define MSG_INFO	3
#define MSG_DEBUG	4

    Mit -m wird ein "Modul?" angegeben:

    Code
    #define MSG_MAIN	1
#define MSG_NET		2
#define MSG_HW		4
#define MSG_SRV		8
#define MSG_DATA        16

    In meinem Beispiel logge ich die RTSP Meldungen raus mit -m 2 (MSG_NET) und -l 4 (MSG_DEBUG)

    Beim Versuch vtuner für Kernel 6.6.5 zu kompilieren bekomme ich einen Fehler:

    Gentoo Linux ~ VDR 2.6.6 ~ DD Octopus NET V2 S2 Max - SAT>IP ~ LENOVO ThinkServer TS200V ~ Intel(R) Core(TM) i5 CPU680@3.60GHz ~ 16GB RAM ~ NVIDIA T400

    Ich habe noch immer Fragezeichen auf der Stirn. Ich denke, da wäre etwas mehr Doku hilfreich.


    Zitat von Joe_D

    Dafür ist das satip-Programm. Es verbindet sich auf der einen Seite mit einem SatIP-Receiver und auf der anderen Seite mit dem vtuner Steuerungsdevice. Wenn der Befehl zum Empfang eines Senders kommt versucht das satip-Programm das vom SatIP-Receiver zu holen und schickt den Stream zum DVB-Device.

    Wo kommt denn der SatIP-Receiver her, wenn minisatip nicht verwandt wird? Wird davon ausgegangen, dass es einen Hardware-SatIP-Receiver gibt? Sowas habe ich als DVB-C-Nutzer nicht und bin auf minisatip angewiesen. Also würde satip dann mit dem minisatip-Server kommunizieren?


    vtuner muss ja wohl auf dem gleichem Rechner laufen wie der vdr client. Das satip binary auch? Mit dem parameter -h wird dem dann die IP-Adresse des satip-Servers übergeben?


    Zitat von Joe_D

    den Support für kernels < 4.16 entsorgt

    Das ist schade. Ich hätte das gerne mal mit meinen amlogic-Boxen ausprobieren, aber die von softhdodroid unterstützten Geräte laufen nur mit 4.9er Kernel.


    Gibt es bezüglich der Zuteilung der satip-devices zu Clients hier irgendwelche Vorteile gegenüber der bisherigen Lösung mit dem satip-Plugin?

    Beispiel: Ich habe auf dem minisatip-Server 4 devices. Aktuell muss ich bei jedem der beiden Clients dem satip-Plugin jeweils vorgeben, dass es zwei frontends zur Verfügung hat. Sind auf einem Client beide frontends belegt, kann dann kein drittes genutzt werden - obwohl der zweite Client es vielleicht gar nicht braucht, weil er gerade gar nicht genutzt wird.

    Ist die Summe der für die Clients als verfügbar konfigurierten frontends höher als die Zahl tatsächlich am satip-Server vorhandener frontends, kann die Situation entstehen, dass vdr ein frontend nutzen will, dass der satip-Server nicht bereitstellen kann (weil von anderem Client benutzt). Dann liefert der satip-Server eine Fehlermeldung, vdr kann nicht umschalten und das satip-Plugin liefert endlos Fehlermeldungen wie SATIP-ERROR: Detected invalid status code 404. Der Grund ist, dass dass es im satip-Protokoll wohl nicht vorgesehen ist, zunächst eine Vorab-Anfrage zu beantworten, ob ein frontend für den angeforderten Kanal verfügbar ist. Deshalb können vdr und das satip-Plugin die vor einem Kanalwechsel erfolgenden Prüfungen auch nur auf Basis der dem Plugin mitgeteilten frontend-Anzahl durchführen und nicht die tatsächlich auf dem Server verfügbaren frontends berücksichtigen.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    heifisch: sieht aus wie ein Programmierfehler.

    Zitat von Dr. Seltsam

    Ich habe noch immer Fragezeichen auf der Stirn. Ich denke, da wäre etwas mehr Doku hilfreich.

    Zur Zeit gibt es genau soviel Doku wie diejenigen die den Kerneltreiber (Honza) und das satip Programm (mc.fishdish) geschrieben haben zur Verfügung stellten. Mein erstes Ziel war erstmal eine für mich funktionierende Umgebung für VDR2.6.4 -> EyeTV Netstream 4Sat (SATIP-Receiver). Und mit dem satip-Plugin hatte ich eben meine gewisse Not...


    Zitat von Dr. Seltsam

    Wo kommt denn der SatIP-Receiver her, wenn minisatip nicht verwandt wird? Wird davon ausgegangen, dass es einen Hardware-SatIP-Receiver gibt?

    Das satip Programm müsste ja eigentlich auch mit minisatip funktionieren, ist doch auch nur ein SatIP-Receiver.


    Zitat von Dr. Seltsam

    Das ist schade. Ich hätte das gerne mal mit meinen amlogic-Boxen ausprobieren, aber die von softhdodroid unterstützten Geräte laufen nur mit 4.9er Kernel.

    Ja, aber gerade bei Kernel 4.2, 4.15 und 4.16 wurde einges am DVB-API gedreht... und dafür waren tonnenweise #ifdefs im Code. Den konnte ich somit komplett entsorgen...

    Zitat von Dr. Seltsam

    Gibt es bezüglich der Zuteilung der satip-devices zu Clients hier irgendwelche Vorteile gegenüber der bisherigen Lösung mit dem satip-Plugin?

    Beispiel: Ich habe auf dem minisatip-Server 4 devices. Aktuell muss ich bei jedem der beiden Clients dem satip-Plugin jeweils vorgeben, dass es zwei frontends zur Verfügung hat.

    Ich habe keine Ahnung was gemeint ist. Das vtuner-Device stellt bis zu 4 Adapter mit jeweils einem Frontend zur Verfügung. Für jedes Frontend wird ein vtuner-Device erstellt. Für jedes vtuner-Device benötigt man ein Programm das dieses mit Streams versorgt.

    Hallo @Joe_D


    vtuner_ng läuft hier unter gentoo unauffällig gut. :thumbup: Danke!

    Ich konnte damit ausschließen, dass die Ursache für meine Umschaltprobleme das satip-Plugin ist, da der Fehler mit vtuner_ng auch aufgetreten ist. Die Octopus NET hat wohl eine Macke. Ich habe erst mal meine alte GSS.box aktiviert.


    Für Gentoo openrc, habe ich mir ein init-Script erstellt:


    hier die config-Datei dazu:

    Code: /etc/conf.d/satip
    # configuration of satip

DEVICES=4
SATIP_SERVER="192.168.139.201"

_EXTRAOPTS=""


    Pro vtuner muss dann ein symlink in /etc/init.d angelegt werden:

    Code
    vdr ~ # ll /etc/init.d/satip.*
304666 4 -rwxr-xr-x 1 root root 510 10. Dec 21:59 /etc/init.d/satip.init
304686 4 lrwxrwxrwx 1 root root  10 10. Dec 21:51 /etc/init.d/satip.vtunerc0 -> satip.init
304689 4 lrwxrwxrwx 1 root root  10 10. Dec 21:57 /etc/init.d/satip.vtunerc1 -> satip.init
304690 4 lrwxrwxrwx 1 root root  10 10. Dec 21:57 /etc/init.d/satip.vtunerc2 -> satip.init
304691 4 lrwxrwxrwx 1 root root  10 10. Dec 21:57 /etc/init.d/satip.vtunerc3 -> satip.init

    Damit werden die Prozesse sauber gestartet und auch wieder beendet.


    Ein kleines Problem habe ich, wenn ich den kernel update.

    Da im Makefile für das kernel-Modul mit uname -r nach der Kernelversion gefragt wird für die es gebaut wird, müsste man nach dem Kernel-Update erst ein reboot machen, bis das Modul gebaut werden kann.

    Damit das nicht notwendig ist, habe ich mich mal an einer Anpassung des Makefile versucht:



    Ich weiß nicht, ob das ein gute Lösung ist, dafür kenne ich mich mit Makefiles nicht gut genug aus.

    Aber es funktioniert erst einmal.


    Im Makefile für satip habe ich noch target uninstall hinzugefügt:

    Gentoo Linux ~ VDR 2.6.6 ~ DD Octopus NET V2 S2 Max - SAT>IP ~ LENOVO ThinkServer TS200V ~ Intel(R) Core(TM) i5 CPU680@3.60GHz ~ 16GB RAM ~ NVIDIA T400

    Einmal editiert, zuletzt von heifisch ()

    Zitat von Joe_D

    Ich habe keine Ahnung was gemeint ist.

    und dabei habe ich mir soviel Mühe mit der Beschreibung gegeben ;(


    Zitat

    Das vtuner-Device stellt bis zu 4 Adapter mit jeweils einem Frontend zur Verfügung. Für jedes Frostend wird ein vtuner-Device erstellt. Für jedes vtuner-Device benötigt man ein Programm das dieses mit Streams versorgt.

    Das habe ich jetzt mehrmals gelesen und verstehe es immer noch nicht. Die ersten beiden Sätze widersprechen sich irgendwie. Oder ist gemeint „Für jedes frontend auf dem satip-Server wird ein vtuner-device benötigt“?

    Mal konkret: Wenn der satip-Server (z.B. minisatip) 4 Tuner hat, von denen ich zwei für den vdr-Client reservieren will, dann brauche ich nach meinem Verständnis auf dem Client zwei vtuner-devices, die zwei virtuelle Adapter anlegen:

    Code
    /dev/dvb/adapter0/frontend0
/dev/dvb/adapter0/demux0
/dev/dvb/adapter0/dvr0

/dev/dvb/adapter1/frontend0
/dev/dvb/adapter1/demux0
/dev/dvb/adapter1/dvr0

    und müsste -ebenfalls auf dem Client- zwei Instanzen von satip laufen lassen: Eine für /dev/vtunerc0 und eine für /dev/vtunerc1.Richtig?

    Jede Instanz von satip belegt dann solange es läuft dauerhaft einen Tuner des satip-Servers? Oder immer nur dann, wenn vdr läuft und das virtuelle device geöffnet hat?

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    Zitat von Dr. Seltsam

    Das habe ich jetzt mehrmals gelesen und verstehe es immer noch nicht. Die ersten beiden Sätze widersprechen sich irgendwie. Oder ist gemeint „Für jedes frontend auf dem satip-Server wird ein vtuner-device benötigt

    Beim Frontend gehen die Befehle rein und irgendwo müssen diese ja "raus" gehen. Bei Hardwarekarten gehen diese in irgendwelche Chips, bei vtuner eben in das vtuner-Device.


    Bitte von der Vorstellung lösen das vtuner und satip nur im Bundle daherkommen. Man kann es so verwenden muss aber nicht. Das satip Programm benötigt in der jetzigen Form zwingend vtuner-ng, vtuner-ng kann aber auch ohne satip Programm Verwendung finden...


    Das eine (vtuner-ng) erstellt DVB-Adapter, das andere (satip) verbindet sich mit einem SatIP-Receiver und übergibt die Daten an vtuner.


    Zitat von Dr. Seltsam

    Mal konkret: Wenn der satip-Server (z.B. minisatip) 4 Tuner hat, von denen ich zwei für den vdr-Client reservieren will, dann brauche ich nach meinem Verständnis auf dem Client zwei vtuner-devices, die zwei virtuelle Adapter anlegen:

    und müsste -ebenfalls auf dem Client- zwei Instanzen von satip laufen lassen: Eine für /dev/vtunerc0 und eine für /dev/vtunerc1.Richtig?

    Richtig.


    Zitat von Dr. Seltsam

    Jede Instanz von satip belegt dann solange es läuft dauerhaft einen Tuner des satip-Servers? Oder immer nur dann, wenn vdr läuft und das virtuelle device geöffnet hat?

    So super genau habe ich das nicht untersucht. Bei mir starte ich satip und vtuner vor dem Starten des vdr und stoppe beides nach Beenden des vdr. Wenn satip nicht mehr läuft wird der Tuner des satip-Servers freigegeben.


    Ob ich über vtuner mitbekomme das ein frontend nicht mehr benutzt wird muss ich mir mal anschauen... Dann könnte ich theoretisch diesen Tuner freigeben...

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden