Beiträge von durchflieger

Zitat von MarkusE

Hi,

Anbei ein Update des Patches. Damit funktioniert es auch zusammen mit dem dynamite Patch.

Bitte testen.

~ Markus

Alles anzeigen

Ja das funktioniert jetzt auch zusammen mit dem dynamite Patch bei mir.

@Seahawk Ich denke du kannst das jetzt in den vdr-2.6.7 übernehmen.

Verändert des Patch eigentlich das ABI des vdr?

Habe den Patch mal getestet und funktioniert bei mir gut! Danke MarkusE!

Kombination headless vdr / vtuner-ng / kathrein EXIP mit 4 devices.

Getestet mit selbst compilierten vdr auf Basis seahawk Packete.

Plugins epgsearch, live, streamdev, devstatus, dummydevice, vdrposd, vdrpservice, vdr-plugin-markad.

Es gibt aber Probleme wenn der dynamite-Patch und der closeFrontendEnd-Patch gleichzeitig angewendet werden.

Der vdr lässt sich compilieren und läuft auch aber die devices verbleiben nicht im idle (closed) Zustand.

Das dynamite-Plugin ist bei diesem Test nicht installiert!

Im Auszug aus dem Log (siehe Anhang) sieht man wie der closeFrontendEnd-Patch alle devices nach einem EPG-Scan schliesst.

Doch 3 Sekunden später greift irgendetwas wieder auf die devices zu.

Wie gesagt ohne dynamite-Patch tritt dieses verhalten nicht auf.

Ich kann damit leben da ich das dynamite plugin nicht benötige.

Aber @seahawk wird das vermutlich nicht so schön finden.

Zitat von durchflieger

Also das aktuelle vtuner-ng package aus dem seahawk repository ist bezüglich der systemd scripts kaputt.

Ich hab das mal überarbeitet und den Inhalt des debian-Verzeichnis im Anhang bereitgestellt.

Es werden jetzt wieder zwei Packete gebaut vtuner-ng-dkms und vtuner-ng-satip wobei diese ihre zugehörigen systemd Komponenten enthalten.

Die Konfiguration findet im Verzeichnis /etc/vtuner-ng statt.

Steuerung mit systemctl start|stop|enable|disable vtuner-ng

Hier noch eine wichtige Verbesserung des systemd script zum vtunerc-ng service.

Der vdr service wurde insbesondere beim booten des linux manchmal zu früh gestartet und hat deshalb nicht alle devices verwendet.

Im vtuner-ng service wird jetzt gewartet bis alle vtunerc devices "used" sind (satip daemon connected).

Implementierung leider nicht per systemd event sondern sleep loop. Mir ist nichts besseres eingefallen

Weiterhin wird der vdr service jetzt mit beendet wenn der vtuner-ng service beendet wird.

[Unit]
Description=vtuner-ng kernel module loader
Before=vdr.service

[Service]
Type=exec
EnvironmentFile=/etc/vtuner-ng/vtunerc.conf
ExecStart=/usr/sbin/modprobe vtunerc devices=${DEVICES} $OPTS
ExecStartPost=/bin/bash -c "while [ ! -e /proc/vtunerc$(($DEVICES - 1)) ] || grep -q -e 'vtunerc. used by : 0' /proc/vtunerc? ; do sleep 0.2; done"
ExecStop=/usr/sbin/modprobe -r vtunerc
RemainAfterExit=true

[Install]
RequiredBy=vdr.service

Zitat von Zabrimus

Ich habe den Aufruf in das Start-Script aufgenommen. Schaden tuts ja nicht

Habe ich mich verrechnet/verguckt? Der aktualisierte Patch ist drin.

Manche info-Variablen erwarten beim alten Kernel die Werte in KHz anstatt Hz.

Anbei ein korrigierter vtuner-ng Patch zum Betrieb mit CE-Kernel 4.9 der den folgenden Fehler fixed:

Mai 21 21:51:49 sat1 vdr[9131]: [9149] ERROR: frontend 0/0: Invalid argument (dvbdevice.c:1677)
Mai 21 21:51:49 sat1 kernel: (NULL device *): DVB: adapter 1 frontend 0 frequency 1052000 out of range (51000000..2150000000)

Aufgrund des Fehler fehlten auf einigen Kanälen die EPG-Daten bei mir.

Zitat von Joe_D

Was aber gar nix macht, andersrum wäre es schon schlimmer, es sei denn der Patch von #309 wird angewandt

Gibt es mehr als 6 sinnvolle DeliverySystems gleichzeitig?

Ich denke ohne Patch #309 wirds in diesem Fall ein Problem da aus der Quellstruktur zu viele Bytes gelesen werden.

Der Patch ist schon sinnvoll da:

struct vtuner_delsys {
    u8 value[VTUNER_MAX_DELSYS];
} __attribute__ ((packed));

Vieleicht sollte man vor dem copy noch das einfügen:

            memset(&ctx->fe->ops.delsys, 0, MAX_DELSYS*sizeof(u8));

Joe_D

Kennst du den Patch:

diff -ru8bBw a/kernel/vtunerc_ctrldev.c b/kernel/vtunerc_ctrldev.c
--- a/kernel/vtunerc_ctrldev.c    2024-01-07 18:35:31.000000000 +0100
+++ b/kernel/vtunerc_ctrldev.c    2024-01-08 19:53:15.153355828 +0100
@@ -272,17 +272,17 @@
         // sanity check, we dont allow all
         for (i=0; i<VTUNER_MAX_DELSYS; i++)
         {
             if (delsys.value[i]==4 || (delsys.value[i]>6 && delsys.value[i]<16) || delsys.value[i]>19)
                 ret = -EINVAL;
         }
         if (ret==0 && !ctx->fe) ret=-EFAULT;
         if (ret==0) {
-            memcpy(&ctx->fe->ops.delsys, &delsys.value, MAX_DELSYS*sizeof(u8));
+            memcpy(&ctx->fe->ops.delsys, &delsys.value, VTUNER_MAX_DELSYS*sizeof(u8));
             printk(KERN_INFO "vtunerc%d: setting delsys to", ctx->idx);
             for (i=0; i<VTUNER_MAX_DELSYS; i++) {
                 switch (delsys.value[i])
                 {
                     case 1:
                       printk(KERN_CONT " DVBC");
                       break;
                     case 2:

Also das aktuelle vtuner-ng package aus dem seahawk repository ist bezüglich der systemd scripts kaputt.

Ich hab das mal überarbeitet und den Inhalt des debian-Verzeichnis im Anhang bereitgestellt.

Es werden jetzt wieder zwei Packete gebaut vtuner-ng-dkms und vtuner-ng-satip wobei diese ihre zugehörigen systemd Komponenten enthalten.

Die Konfiguration findet im Verzeichnis /etc/vtuner-ng statt.

Steuerung mit systemctl start|stop|enable|disable vtuner-ng

Zitat von Joe_D

• timeout Parameter hinzugefügt, nach dieser Zeit werden Frontends freigegeben wenn nur Section-Pids übertragen werden. Der EIT-Scan belegt ein Frontend 20 Sekunden, bei VPS könnte das ein Problem sein/werden - eventuell muss dann diese Funktion stillgelegt werden...

Wenn der Sender aufgrund des erreichen der VPS-Margin-Zeit getuned wird dann werden hier laut meiner Beobachtung auch nur die Standard-Section-Pids <= 20 für die Auswertung des running Status gesetzt.

Das wird schwierig mit dem Timeout.

Was passiert denn eigentlich wenn eine Sendung z.B. um 20 Minuten verspätet beginnt.

Wird da eine neue VPS-Startzeit übermittelt oder muss der vdr jetzt die 20 Minuten auf den running-Status warten?

In dem Fall wäre das bestimmen der Timeoutzeit schon nicht so einfach.

Hallo,

zu meinen Beitrag #281 in diesem Thread:

Ich habe mal den vdr auf Version 2.6.6 downgraded.

Mit der Version startet der vdr auch Aufnahmen zu Timern mit zugeschalteten VPS.

Allerdings ist der Log und der angezeigte Tunerstatus am exip auch hier sonderbar!

Es ist ein VPS-Timer auf die Sendung "Um Himmels Willen (163)" geplant 14:35 gesetzt:

Bis 14:32 sind die Tuner am exip wegen eit-Scan belegt der ja in dieser vdr-Version noch ohne grosse Pausen durchläuft.

Um 14:32 wird auf den Sender getuned weil der Timer den vps margin erreicht.

Kurz danach wechseln alle Tuner am exip auf unbelegt!!!

Um 14:35:08 startet tatsächlich die Aufnahme. Tuner aum exip auch wieder belegt. Weitere Tuner mit eit-Scan belegt.

Um 14:35:11 stoppt der Aufnahme-Thread???

Um 14:36:08 wird die Aufnahme dann wieder gestartet und läuft dann auch durch.

Log ist im Anhang.

Hallo,

ich habe zu meinem Anliegen schon hier gepostet: RE: [vtuner-ng] Aktualisierter vtuner für kernel >= 4.16

aber leider noch keine Antworten bekommen.

Anwender mit der Kombination vdr 2.6.7 + vtuner-ng + Kathrein EXIP418: Funktionieren bei euch Aufnahmen bei Timern bei denen VPS zugeschaltet ist?

seahawk1986

um mögliche weitere daemons (iptv?) zu integrieren schlage ich folgende Änderung vor:

Konfigurationsverzeichnis /etc/vtuner. Das /etc/default finde ich nicht so passend da ja potentiell mehrere Konfigurationsdateien entstehen können.

Die Basiskonfiguration in base.conf oder alternative als Name main.conf:

# basic configuration loaded by vtuner and vtuner-daemon service units
# within devices specific configuration files e.g. vtunerc1.conf these values could be overridden

# Number of vtuner devices
DEVICES=4

# Hostname/IP-Adress of SATIP-Server
SATIP_SERVER=192.168.50.9

# basic additional command line options for satip daemon
SATIP_BASE_OPTS=-u vdr -l 1

# additional command line options for satip daemon. Should be overridden in device specific configuration files
SATIP_OPTS=

Eine zukünftige fiktive Erweiterung für einen iptv daemon würde dann IPTV_xxx Variablen definieren, iptv unit template hinzufügen und eine Erweiterung der udev rules:

# assign group video to vtunerc device and trigger systemd satip daemon service instance
ACTION=="add", SUBSYSTEM=="vtuner", KERNEL=="vtunerc[0-1]", GROUP="video", MODE="0660", TAG+="systemd", ENV{SYSTEMD_WANTS}="satip@$name.service"
# assign group video to vtunerc device and trigger systemd iptv daemon service instance
ACTION=="add", SUBSYSTEM=="vtuner", KERNEL=="vtunerc[2-3]", GROUP="video", MODE="0660", TAG+="systemd", ENV{SYSTEMD_WANTS}="iptv@$name.service"

Ich hab seit ein paar Tagen bei mir auch einen Kathrein exip 418 am start der die derzeitige DVB-Karte (dvbsky s952) in meinem headless vdr server ersetzen soll.

Das ganze läuft mit vdr 2.6.7 + vtunerc + satip grundsätzlich recht ordentlich ( Joe_D: Danke das du das auf vordermann gebracht hast!).

Allerdings habe ich doch jetzt ein ernstes Problem festgestellt. Der vdr startet keine Aufnahme bei Timern bei denen vps zugeschaltet ist!

Hat da schon jemand ähnliche Erfahrungen gemacht?

Im Anhang der Log zu vdr/satip für einen timer zu 3sat HD Ländermagzin geplannter start 14:11.

Man sieht wie der vdr bei 14:08 den Kanal tuned (ich habe 180s vps Vorlaufzeit konfiguriert) vermutlich um jetzt den stream auf das vps

start event zu beobachten.

Um 14:09 wird der stream warum auch immer wieder geschlossen. Da kann der vdr dann auch kein start event mehr sehen und

dann gibt es auch keine Aufnahme. Was läuft da schief?

Greift da vieleicht ein inaktivitäts timeout'?

Zitat von seahawk1986

Ich würde die Dateien etwas umbenennen, damit die besser ins Debian-Paketschema passen:

Ist das so in Ordnung?

Die Umbenennung ist ja letztendlich geschmacksache. Falls mal jemand einen anderen Daemon für das vtunerc device entwickelt würde mein Namensschema für die Units dann vieleicht besser passen.

Die device spezifische Konfigurationsdatei in deiner Version bekommt den Namen /etc/default/vtuner-ng-satip_vtuner0 da %i den ganzen devicce-Namen ersetzt!

Nachfolgend meine systemd scripts für den vtuner-ng die ich auf meinen Server zusammen mit den vdr/vtuner-ng Packeten aus dem seahawk repositorys verwende.

Unit /etc/systemd/system/vtunerc.service verwaltet das Kernel module.

Es verwendet die Variable DEVICES aus der Konfigurationsdatei /etc/satip-vtuner/base.conf

[Unit]
Description=vtuner kernel module loader
Before=vdr.service

[Service]
Type=exec
EnvironmentFile=/etc/satip-vtuner/base.conf
ExecStart=/usr/sbin/modprobe vtunerc devices=${DEVICES}
ExecStop=/usr/sbin/modprobe -r vtunerc
RemainAfterExit=true

[Install]
WantedBy=vdr.service

Template unit /etc/systemd/system/satip@.service verwaltet die satip daemon(s).

Es verwendet die Variablen SERVER, BOPTS, OPTS aus der Konfigurationsdatei /etc/satip-vtuner/base.conf sowie optional aus

/etc/satip-vtuner/vtunercX.conf

[Unit]
Description=satip vtuner daemon
PartOf=vtunerc.service
Wants=network-online.target
After=network-online.target
Before=vdr.service

[Service]
Type=exec
EnvironmentFile=/etc/satip-vtuner/base.conf
EnvironmentFile=-/etc/satip-vtuner/%i.conf
ExecStart=/usr/bin/satip -s ${SERVER} -d /dev/%i $BOPTS $OPTS
Restart=always
RestartSec=5

und als Bindeglied der beiden Services die udev rules Datei /etc/udev/rules.d/50-vtunerc.rules

# assign group video to vtunerc device and trigger systemd satip daemon service instance
ACTION=="add", SUBSYSTEM=="vtuner", KERNEL=="vtunerc[0-7]", GROUP="video", MODE="0660", TAG+="systemd", ENV{SYSTEMD_WANTS}="satip@$name.service"

Die Konfiguration in der Datei /etc/satip-vtuner/base.conf

# basic configuration loaded by vtuner and satip service units
# within devices specific configuration files e.g. vtunerc1.conf these values could be overridden

# Number of vtuner devices
DEVICES=4

# Hostname/IP-Adress of SATIP-Server
SERVER=192.168.50.9

# basic additional command line options for satip daemon
BOPTS=-u vdr -l 1

# additional command line options for satip daemon. Should be overridden in device specific configuration files
OPTS=

Gesteuert werden kann das ganze mit:

systemctl start|stop|enable|disable vtunerc

Have fun!

Hallo,

der Patch im Anhang ergänzt den satip daemon um die Option -u <user> damit dieser nicht immer unter dem user root laufen muss.

Zum compilieren wird zusätzlich die libcap (deb Packet libcap-dev) benötigt.

Zitat von kfb77

OK, den Rest habe ich jetzt im Branch V03 drin.

Nochmals sorry für übersehen von deinem Post.

Hab die neue Version aus Branch V03 jetzt einige Tage getestet. Funktioniert einwandfrei. Danke für die Übernahme des Patch.

Alternative gibt es da noch eine Reihe von STB's mit dem HiSilicon Hi3798MV20. Der hat eine Mali G450 GPU.

https://www.hdfreaks.cc/index.…hips-arm-und-HDF-Support/

https://www.hdfreaks.cc/index.…hips-arm-und-HDF-Support/