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

    Hallo,


    ich wollte vtuner nun auch mal zumindest auf dem Client testen.

    Hier läuft ein aktuelles yavdr (22.04) mit vdr-2.6.3 und eine OctopusNet.

    Starte ich mit

    Code
    /usr/sbin/modprobe vtunerc devices=1
/usr/local/bin/satip -s 192.168.178.12 -d /dev/vtunerc0 -m 2 -l 4 2> /tmp/satip0.log &

    bekomme ich weder Bild noch Ton.

    Auch umschalten bringt nichts.

    Schalte ich direkt auf RTL bekomme ich Ton, aber das Bild bleibt schwarz.

    ofenheizer

    mit welchem Kernel bist Du unterwegs?

    Code
    root@vdr:~# uname -a
Linux vdr 5.15.0-91-generic #101-Ubuntu SMP Tue Nov 14 13:30:08 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

    ofenheizer

    ist wirklich nur ins Blaue, aber ich bekam mit dem 5er Kernel vtuner-ng bei mir nicht zum Laufen. Das Update auf 6.2.0-37-generic führte dann hier zum Erfolg! Aber nicht hauen wenn die Problematik bei Dir anders liegt...


    Außerdem starte ich aus der vdr.service heraus mit (sudo systemctl daemon-reload nicht vergessen):

    startvtuner.sh

    stopvtuner.sh

    Ich starte auch über die vdr.service (reload wurde auch gemacht).

    Ich schaue mal wegen des Kernels.

    Zitat von ofenheizer

    Linux vdr 5.15.0-91-generic #101-Ubuntu SMP Tue Nov 14 13:30:08 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

    Update auf 6.2.0-39 und es läuft.

    Das ist echt schräg. Bei mir läuft es unter:

    Code
    Linux server 5.15.0-odroid-arm64 #1 SMP PREEMPT Ubuntu 5.15.118-202306231801~jammy (2023-06-23) aarch64 aarch64 aarch64 GNU/Linux

    Sollte PREEMPT oder die Architektur einen Unterschied machen?

    Ich hab es nicht weiter untersucht. Liess sich ja auch alles fehlerfrei starten. Nur Bild mit softhdvaapi blieb wie beschrieben schwarz. Fehlermeldungen im VDR gab es keine. Da Taipan ja auch Problem mit dem Kernel hatte, hab ich einfach auf den aktuellen gewechselt.

    So, gab noch eine Ergänzung:


    Mit dem Parameter -D kann nun im satip-Programm das Frontend auf ein oder mehrere DeliverySystems festgelegt werden:

    Code
      -D    vtuner frontend delivery system, values: DVBS DVBS2 DVBT DVBT2 DVBC DVBC_B DVBC_C (defaults to all)


    Das ist nützlich wenn man unterschiedliche Quellen hat (z.B. DVBS/S2 und DVBC) dann kann man nun den jeweiligen Frontends "Ihre" DeliverySysteme zuweisen.


    Wird in dmesg protokolliert:

    Code
    [10914.269730] vtunerc: registered /dev/vtunerc0
[10914.273918] vtunerc0: setting delsys to DVBS DVBS2


    Und erscheint auch im vdr:

    Code
    Jan  3 12:45:03 server vdr: [8553] frontend 0/0 provides DVB-S,DVB-S2 with QPSK,QAM16,QAM32,QAM64,QAM128,QAM256,VSB8,VSB16,TURBO_FEC ("vTuner proxyFE DVB-Multi")


    Ich fände es ja toller wenn das DVBAPI eine Funktion hätte wie z.B. "CanTune" oder "IsTunable" bei der man einfach die Parameter übergibt und ein simples true/false zurückbekommt. Dann könnte ein Frontend sogar nur einzelne Kanäle oder Transponder liefern und man müsste nicht so dümmlich DeliverySystems oder die Modulation abfragen/einstellen um im Endeffekt immer noch nicht genau zu wissen ob der Kanal empfangen werden kann...

    Zitat von rell

    Also, egal wen ich vorher starte... Sundtek schnappt sich die beiden ersten frontends...


    vdr startet mit dem LD_PRELOAD für die sundteks. vtunerc ist mit 6 devices geladen und mit satip sind die 6 devices zugewiesen. Am Ende hätte ich gerne 8 tuner ;)

    Du brauchst first_adapter=N in /etc/sundtek.conf das weist unserem Stack den ersten freien Adapter zu. N sollte die Nummer des ersten Adapters sein welcher von unserem Stack benutzt werden darf.

    Grundsätzlich versucht der Stack abzuwarten bis andere Treiber geladen sind aber das ist halt nicht wirklich vorhersehbar wann was geladen wird deshalb die first_adapter Option.

    Ich habe nun auch den Fehler gefunden warum das mit dem PUSI bei mir nicht läuft. Ich musste dazu im vtunerc_priv.h folgendes ändern:

    Code
    -- char *kernel_buf;
++ unsigned char *kernel_buf;

    Jetzt habe ich allerdings noch das Problem das irgendwer mit der PID Liste durcheinander kommt. Wenn ich schnell zwischen 2 Programmen umschalte dann fehlt auf einmal die PID für das Video. Sie wird zwar zuerst gesetzt, aber dann ein paar Millisekunden später wieder gelöscht und bleibt dann weg.

    Lustigerweise passiert das ab dann bei jedem umschalten, sodas ich den vdr neu starten muss.

    Mit dem Satip Plugin passiert das nicht.

    Super! Mit  unsigned char *kernel_buf;  laufen jetzt auch bei mir alle Sender!


    Damit die github-Version vom 3.1. kompiliert musste ich zwei Deklarationen an den Anfang der Rotuine verschieben:


    Edit: Und sollte pusi_seen nicht besser mit 0 als mit false initialisiert werden?

    Code
    for (i=0; i<MAX_PIDTAB_LEN; i++)
    if (ctx->feedtab[i]!=NULL) ctx->feedtab[i]->pusi_seen=false;
    Zitat von jojo61

    Ich habe nun auch den Fehler gefunden warum das mit dem PUSI bei mir nicht läuft. Ich musste dazu im vtunerc_priv.h folgendes ändern


    -- char *kernel_buf;

    ++ unsigned char *kernel_buf;

    Ok, baue ich ein. Interessant das (ctx->kernel_buf[i+1] & 0x40) scheinbar nur funktioniert wenn kernel_buf unsigned ist...


    add pid und del pid kommen direkt aus dem demux0-Device:

    Das schiebe ich sozusagen nur weiter... keine Ahnung warum das abgemeldet wird.


    Zitat von jojo61

    Mit dem Satip Plugin passiert das nicht.

    Potzblitz! Das gute Satip-Plugin, warum nochmal verwende ich nicht einfach das? :/


    Zitat von FireFly

    Damit die github-Version vom 3.1. kompiliert musste ich zwei Deklarationen an den Anfang der Rotuine verschieben
    Edit: Und sollte pusi_seen nicht besser mit 0 als mit false initialisiert werden?

    Hab' ich so übernommen. Danke!


    Für das PID-Handling habe ich zusätzlich eine Semaphore eingebaut um Nebeneffekte zu verhindern. Ein Umschalten von ARD-HD zu ZDF-HD sieht jetzt gerade so aus:

    Da die Meldung MSG_PIDLIST asynchron an satip geliefert wird und es sich im Endeffekt um einen Puffer aller Aktionen handelt führt nicht jede MSG_PIDLIST zu einer Aktion in satip. Das ist auch gut so:


    Code
    PLAY rtsp://satip.lan/stream=299?delpids=5101 RTSP/1.0
PLAY rtsp://satip.lan/stream=299?src=1&fe=4&freq=11361&pol=h&msys=dvbs2&mtype=8psk&sr=22000&fec=23&ro=0.35&plts=on&pids=6110,6120,6121,6123,6122,6131 RTSP/1.0
PLAY rtsp://satip.lan/stream=299?addpids=18,20,0,17,16 RTSP/1.0
PLAY rtsp://satip.lan/stream=299?addpids=6100 RTSP/1.0
PLAY rtsp://satip.lan/stream=299?addpids=6300 RTSP/1.0
PLAY rtsp://satip.lan/stream=299?delpids=6300 RTSP/1.0


    Ganz dolle finde ich das aber mit den gemischten Pids noch nicht und prüfe ob ich irgendwie erkennen kann was zu wem gehört...

    Zitat von Joe_D

    Für das PID-Handling habe ich zusätzlich eine Semaphore eingebaut um Nebeneffekte zu verhindern.

    Leider hat das nicht geholfen. Nach einigem schnellen hin und herzappen wird die Video PID wieder gelöscht und das dann bei jedem umschalten.


    In satip_rtsp.c machst du keinen teardown bei StreamID == 0. Die 0 ist aber eine gültige StreamID und mein Satipserver nutzt die auch.

    Code
    static int send_teardown(t_satip_rtsp* rtsp)
{
>>>>>> if (rtsp->streamid==0) return SATIP_RTSP_OK;
  int printed;

    Wenn ich das auskommentiere dann funktioniert es auch mit dem Kathrein nach einem boot.

    Sorry if I write in english, I don't speak german.

    I am trying to use the plugin on Arch Linux (kernel 6.6.10).


    This is what I do


    sudo modprobe vtunerc devices=1

    sudo satip -h 192.168.1.10 -d /dev/vtunerc0 -m 2 -l 4 2> /tmp/satip0.log &


    In /dev/dvb there is no frontend


    ls /dev/dvb/adapter0/ (base)

    demux0 dvr0


    I would like to connect vtuner-ng to my SAT>IP server (minisatip) and watch tv on Kaffeine.


    Thanks for your help.

    Zitat von jojo61

    wird die Video PID wieder gelöscht

    Nur zur Info: Das macht nicht vtuner. vtuner löscht keine PIDs. Das kommt von außen und zwar von hier:

    https://elixir.bootlin.com/lin…dvb-core/dvb_demux.c#L761 (Beim Aufruf von stop_feed wird die Funktion vtunerc_stop_feed aufgerufen die dann wunschgemäß die PID beim SAT>IP Receiver abmeldet)


    Interessant wäre jetzt halt mal ein dmesg-Output der aktuellsten Version mit debug=1 und noch eine Info über den verwendeten kernel..


    Zitat von jojo61

    Wenn ich das auskommentiere dann funktioniert es auch mit dem Kathrein nach einem boot.

    Habe ich so übernommen.

    So hier nochmal ein log mit dem aktuellen vtunerc:

    Mir ist schon klar das dies vom dvb_demux Modul gesteuert wird. Aber irgend etwas bringt es wohl durcheinander. Vielleicht sind es die Stati (LOCK, SYNC etc). Da ist übrigens auch eine pusi_seen Logik drin, aber nur für Section PIDs.

    Ich nutze den debian Kernel 6.1.0-17 von bookworm.

    Noch ein Tipp für ne Optimierung. In der structur dvb_demux_feed wird immer ein Index zur PID mitgeliefert. Die kannst du direkt als Index in deine Pidliste nutzen und musst die Pid nicht suchen. Der Index wird vom dvb_demux Module verwaltet.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden