Posts by durchflieger
-
-
apt policy vdr-plugin-live-ng
vdr-plugin-live-ng:
Installiert: (keine)
Installationskandidat: 3.3.10-0yavdr0~jammy
Versionstabelle:
3.3.10-0yavdr0~jammy 600
600 https://ppa.launchpadcontent.net/seahawk1986-ho…dr-2.7.3/ubuntu jammy/main amd64 Packages
sudo apt-get install vdr-plugin-live-ng
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Die folgenden NEUEN Pakete werden installiert:
vdr-plugin-live-ng
0 aktualisiert, 1 neu installiert, 0 zu entfernen und 2 nicht aktualisiert.
Es müssen noch 0 B von 1.326 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 3.679 kB Plattenplatz zusätzlich benutzt.
Vormals nicht ausgewähltes Paket vdr-plugin-live-ng wird gewählt.
(Lese Datenbank ... 271361 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../vdr-plugin-live-ng_3.3.10-0yavdr0~jammy_amd64.deb ...
Entpacken von vdr-plugin-live-ng (3.3.10-0yavdr0~jammy) ...
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von vdr-plugin-live-ng:
vdr-plugin-live-ng hängt ab von vdr-abi-2.6.9-0yavdr; aber:
Paket vdr-abi-2.6.9-0yavdr ist nicht installiert.
dpkg: Fehler beim Bearbeiten des Paketes vdr-plugin-live-ng (--configure):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
Es wurde kein Apport-Bericht verfasst, da die Fehlermeldung darauf hindeutet, dass dies lediglich ein Folgefehler eines vorherigen Problems ist.
Fehler traten auf beim Bearbeiten von:
vdr-plugin-live-ng
E: Sub-process /usr/bin/dpkg returned an error code (1)
-
-
Hallo,
nach update des vdr-plugin-live-ng von 3.3.7 -> 3.3.10 aus @seahawk repos für jammy habe ichAnzeigeprobleme im Browser:In Tabe "Programm" erscheinen keine EPG-Einträge. Die Tabe "Was läuft" funktioniert aber.In Tabe "Aufnahmen" werden nur noch die Unterverzeichnisse angezeigt jedoch keine Aufnahmen. In "Aufnahmen flach" erschein auch keine Aufnahme.Alles aus seahawk vdr-2.6.9 repos für jammy.libtntnet ist 2.2.1-4build2, libcxxtools ist 2.2.1-4, libpcre3 ist 2:8.39-13ubuntu0.22.04.1, libpcre2 ist 10.39-3ubuntu0.1Nach update auf vdr-2.7.3 gleiches Problem.Musste allerdings das Packet selber compilieren da aus dem Repo die Installation mit fehlender Abhängigkeit zu vdr-abi-2.6.9 fehlschlägt.Hat jemand auch diese Anzeigeprobleme?- durchflieger
-
Hi,
Anbei ein Update des Patches. Damit funktioniert es auch zusammen mit dem dynamite Patch.
Bitte testen.
~ Markus
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.
-
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.
Code: vtuner-ng.service
Display More[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
-
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:
CodeMai 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.
-
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.
-
-
Kennst du den Patch:
Diff
Display Morediff -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
-
- 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?
-
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:
Code
Display More# 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:
Code# 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'?
-
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!