yavdr ansible

    Das Paket bringt ein SysV-Init Skript mit, das beim Booten und beim Herunterfahren kurz ausgeführt wird und dabei die letzte Aufweckzeit löscht bzw. eine neue setzt.

    Die Systemd-Unit wird dynamisch erzeugt und macht nichts anderes als das Skript mit start bzw. stop als Argument aufzurufen:

    Was es allerdings zumindest auf meinem Testsystem nicht mehr gibt, ist /proc/acpi/alarm (wohin das Skript die Aufweckzeit schreiben will). Damit schlägt der Aufruf von /etc/init.d/vdr-addon-acpiwakeup stop fehl.


    Bei modernen Kerneln sollte das jetzt /sys/class/rtc/rtc0/wakealarm für die erste RTC sein. Außerdem scheint man nicht mehr wiederholt eine Aufwachzeit schreiben zu können, ohne vorher den Wakealarm auf 0 zu setzen.


    Ich habe das Skript jetzt mal so angepasst, dass es die moderne Variante nutzt, um die Aufweckzeit zu setzen: https://launchpad.net/~yavdr/+…66/+listing-archive-extra

    Langfristig überlege ich https://github.com/seahawk1986/acpiwakeup-ng für yaVDR zu paketieren, das ist für Systemd vorbereitet und nutzt ausschließlich die neue Methode.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Vielen Dank, ist installiert und wird getestet.


    Und noch ein Problem:


    bei der Wiedergabe von Aufnahmen, die auf meinem NAS liegen und per NFS eingebunden sind, bekomme ich

    immer wieder Tonaussetzer. Hier mal das LOG:



    Irgendeine Idee, was das sein koennte?



    Cheers,

    Ole

    Zitat von seahawk1986

    Ich habe das Skript jetzt mal so angepasst, dass es die moderne Variante nutzt, um die Aufweckzeit zu setzen

    Getestet und für gut befunden. Der VDR wacht jetzt wieder zuverlässig zu den gesetzten Uhrzeiten auf. Vielen Dank seahawk1986 !


    Cheers,

    Ole

    Hallo,


    das hatte ich soeben im Log, als ich den VDR mit kill -9 beenden musste, da er nicht mehr reagierte, nachdem ich einen laufenden Timer per live deaktivieren wollte.

    Kann jemand damit etwas anfangen? Scheinbar hat live das Problem verursacht, oder?

    Beim kurzen Blick in den Code von live sieht es für mich so aus, als ob zumindest manchmal die Service-Schnittstelle von epgsearch mit gesetztem Channelslock aufgerufen wird. Das würde immer zum obigen report führen. Wäre aber im Normalfall nicht gleich tragisch, beim Deadlock muss ein anderer Task die Locks gleichzeitig in umgekehrter Reihenfolge anfordern. Das kann man nur analysieren, wenn man statt kill -9 einen core-Dump vom hängenden vdr erzeugt und auswertet.

    vdr-2.6.7

    softhddevice, dbus2vdr, dvd, epgsearch, femon, graphtftng, web, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver
    ubuntu focal, yavdr-ansible, linux-5.15 ,AsRock J4105, CIne CT-V7 DVB-C

    Diese Fehlersuche hat doch mit ansible nichts zu tun, da geht es um die Installation eines VDR's und nicht um spezifische Plugins wo Probleme verursachen.


    Vielleicht kann ein Mod das Thema auslagern :)

    Gruß utiltiy



    VDR Projekte VDR Projects

    Einmal editiert, zuletzt von utiltiy () aus folgendem Grund: Typo

    Zitat von OleS

    bei der Wiedergabe von Aufnahmen, die auf meinem NAS liegen und per NFS eingebunden sind, bekomme ich

    immer wieder Tonaussetzer.

    Sind die Aussetzer weg, wenn die selbe Aufnahme lokal abgelegt wurde? Falls nicht: hast du mal mit dem TS-Doctor oder einem ähnlichen Programm geschaut, ob es Fehler im TS-Stream gibt?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Lokal habe ich es noch nicht versucht, aber im Kodi auf der selben Box kann ich die Aufnahme fehlerfrei abspielen.

    Ich befürchte, dass da irgendetwas im pulseaudio schief läuft. Wie kann ich eigentlich wieder zurück auf alsa ohne

    pulseaudio, denn eigentlich benötige ich das nicht. Browser nutze ich am VDR nicht und ich habe auch keine

    unterschiedlichen Wege für Audio zu schalten.


    Cheers,

    Ole

    Ok, an pulseaudio liegt es auch nicht, mit reinem alsa bekomme ich auch die Fehler:

    Was mich etwas wundert ist folgende Zeile:

    Code
    Sep 10 13:44:14 htpc vdr: epg2vdr: Playing recording '�v0)�U'


    Der NFS-Export der Aufnahmen an mein Laptop gehängt und die Aufnahme per VLC abgespielt liefert auch keine Probleme.


    Cheers,

    Ole

    Einmal editiert, zuletzt von OleS ()

    Anbei eine Analyse mit TS-Doctor



    Cheers,

    Ole

    Für micht sieht das nach Fehlern in der Aufnahme aus. Wie gut ein Programm das wegsteckt, hängt vermutlich von der Implementierung ab.


    Zitat von OleS

    Wie kann ich eigentlich wieder zurück auf alsa ohne

    pulseaudio, denn eigentlich benötige ich das nicht.

    Ich hatte beim Frontend-Skript schon eine Option eingebaut, mit der man pulseaudio pausieren kann, wenn das VDR-Frontend aktiv ist, da fehlt bislang nur eine Möglichkeit zu erkennen, ob der VDR nach dem stoppen des Frontends die Soundkarte schon freigegeben hat, bevor man pulseaudio reaktiviert - sonst hat man keinen Ton mehr damit - dafür habe ich in den letzten Tagen eine Lösung erarbeitet und komme hoffentlich bald dazu das python3-yavdrfrontend Paket zu aktualisieren, so dass man mit einer Variablen in der /etc/yavdr-frontend/config.yml Ausgabeplugins wie softhddevice, vaapidevice oder softhdcuvid die Möglichkeit geben kann direkt über ALSA Ton auszugeben.


    Andere (eigenständige) Programme kann man mit pasuspender wrappen und für KODI muss man noch eine Umgebungsvariable setzen, damit das dann auch tatsächlich ALSA nutzt.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Zitat von seahawk1986

    dafür habe ich in den letzten Tagen eine Lösung erarbeitet und komme hoffentlich bald dazu das python3-yavdrfrontend Paket zu aktualisieren

    Super, vielen Dank.


    Ich hatte mir zum Test eine passende asound.conf gebaut und in /var/lib/vdr/.config/pulse/client.conf den Parameter autospawn = no gesetzt. Nach einem reboot der Box sollte das doch ausreichen, oder?


    Zitat von seahawk1986

    Für micht sieht das nach Fehlern in der Aufnahme aus.

    Ja, in dieser speziellen Aufnahme sind ein paar kleine Fehler, aber bisher ist der VDR damit prima klargekommen. Andere ebenfalls stockende Aufnahmen haben keinerlei Fehler im TS. Ich befürchte es ist ein Problem im Netzwerk, denn lokal abgelegte Aufnahmen spielen sauber ab und irgendwie verhält sich tracepath eigenartig:



    Ich habe zu meinem NAS immer mal wieder Hänger obwohl darauf eigentlich nichts läuft. Habe zum Test extra alle Services angehalten.

    Also doch mal das Netzwerk auf den Kopf stellen...


    Cheers,

    Ole

    Einmal editiert, zuletzt von OleS ()

    Da es momentan ja 2 neue UHD-Sender gibt (siehe hier im Thread zum "softhdcuvid"-Plugin) habe ich mir auch mal das yavdr-ansible installiert.

    Zusätzlich noch das neue "softhdcuvid"-Plugin für die Bildausgabe installiert.


    Die Installation ist erstmal soweit durchgelaufen und ich habe auch Bild und Ton, allerdings mit ein paar kleineren Problemchen:

    1. Bei SD habe ich nur ein 4:3-Bild, obwohl es 16:9-Sendungen sind.
    2. Bei HD ist des Bild bei den ersten kurzen Tests soweit i.O.
    3. Bei UHD habe ich immer Bildruckler. Das ist natürlich weniger schön!

    Über meine Chinabox mit Coreelec und KODI-18.0 mit dem vdr-vnsi-Addon ist der UHD-Empfang + Wiedergabe für die Arte-UHD-Sender einwandfrei, da funktioniert sogar das HDR! ;)


    Mein System ist:

    Hardware: Intel i5-2700, Nvidia GT1030

    Software nach "dkms status": nvidia, 390.48, 4.15.0-34-generic, x86_64: installed


    Muss ich zusätzlich zum "normalen" yavdr-ansible für UHD noch etwas installieren?

    Würde ein neuerer nvidia-Treiber-396 etwas bringen? Wie sollte ich da vorgehen?


    Paul

    Einmal editiert, zuletzt von Paulaner ()

    Zitat von Paulaner

    Bei SD habe ich nur ein 4:3-Bild, obwohl es 16:9-Sendungen sind.

    Da musst du in den Einstellungen von softhdcuvid unter Video bei "16:9 and other video display format" etwas anderes als die Voreinstellung auswählen, mit "center cut-out" passt es zumindest bei 16:9 Material.

    Zitat von Paulaner

    Bei UHD habe ich immer Bildruckler. Das ist natürlich weniger schön!

    Ich habe hier leider keine Möglichkeit mit UHD zu experimentieren.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Ich habe mal noch 2 Fragen zum yavdr-ansible:

    • Wie kann ich den VDR über die Konsole stoppen/starten? Ein "vdr stop" scheint irgendwie bei mir nicht zu funktionieren. Wenn ich den Befehl in der Konsole eingebe, dann kommt nur diese Angaben und mehr passiert nicht. Der VDR läuft einfach weiter.
    Code
    vdr stop
vdr: no primary device found - using first device!


    • Wie bekomme ich meine Fernbedienung wieder am Laufen, die am seriellen Port COM1 mit einem Homebrew-Empfänger hängt.

    Die Fernbedienung nutze ich bereits seit sehr vielen Jahren per LIRC am seriellen Port. Dazu gibt es dann einen Treiber "serial_ir"

    Dazu hatte ich vor Jahren mal eine "lircd.conf" erstellt, die in /etc/lirc/ liegt und dazu noch eine "/etc/modeprobe.d/serial_ir.conf" für die Zuweisung des COM1-Ports.

    Was müsste ich in yavdr-ansible machen, um die Fernbedienung am seriellen Port wieder ans Laufen zu bekommen?


    Paul

    Einmal editiert, zuletzt von Paulaner ()

    Zitat
    • Wie kann ich den VDR über die Konsole stoppen/starten? Ein "vdr stop" scheint irgendwie bei mir nicht zu funktionieren. Wenn ich den Befehl in der Konsole eingebe, dann kommt nur diese Angaben und mehr passiert nicht. Der VDR läuft einfach weiter.

    sudo service vdr stop

    sudo service vdr start

    Mein VDR: Hardware: Nanum SE-H100/ASRock Q1900M/Pico-PSU/GeForce GT 720/yavdr-ansible

    Zitat von wannseheichwas

    sudo service vdr stop

    sudo service vdr start

    Danke, klappt perfekt. ;)


    Paul

    Ich habe meinen Rechner mit einem Atric V5 noch nicht auf yavdr-ansible umgestellt, aber soweit ich das gelesen habe, genügt es mittlerweile serial_ir mit den korrekten Optionen zu laden und mit ir-keytable das gewünschte Protokoll und Keymap zu setzen.


    Nur wenn einem das Verhalten der Kernel-Decoder nicht gefällt, braucht man Lirc noch (dann sollte man LIRC als Protokoll setzen) - das Format der Konfigurationsdateien hat sich bei neueren Lirc-Konfigurationen geändert, die Start-Optionen werden in der /etc/lirc/lirc_options.conf gesetzt - wenn für deinen Empfänger nach dem Laden des serial_ir Treibers der Geräteknoten /dev/lirc0 angelegt wird, sollte der Teil der Konfigurationsdatei dann nach meinem Verständnis so aussehen:

    Code
    [lircd]
          nodaemon        = False
          driver          = default
          device          = /dev/lirc0

    Und da ich bei yavdr-ansible die lircd.service maskiere, muss man dann noch folgende Schritte ausfürhen, um die Unit wieder zu aktivieren:

    Code
    sudo systemctl unmask lircd.service
sudo systemctl enable lircd.service
sudo systemclt start lircd.service

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Zitat von seahawk1986

    ... aber soweit ich das gelesen habe, genügt es mittlerweile serial_ir mit den korrekten Optionen zu laden und mit ir-keytable das gewünschte Protokoll und Keymap zu setzen.

    Ich würde auch auf LIRC verzichten und mit den ir-keytable arbeiten, aber da komme ich nicht weiter, weil ir-keytable kein Remote-Gerät findet:

    Code
    root@yaVDR:/home/yavdr# ir-keytable
Keine Geräte gefunden


    Hier bin ich mit meinem Latein am Ende, weil ich nicht weiß, wie ich "serial_ir" bei Ubuntu-18.04 laden soll.

    In /etc/modprobe.d habe ich erstmal eine Datei "serial_ir.conf" mit folgendem Inhalt angelegt, weil mein serieller IR-Empfänger an COM1 liegt:

    Code
    # COM1 equivalent: /dev/ttyS0
options serial_ir irq=4 io=0x3f8


    Ein "lsmod | grep serial_ir" gibt nichts zurück!

    Wenn ich vorher ein "modprobe serial_ir" ausführe, dann wird das Modul geladen:

    Code
    root@yaVDR:/home/yavdr# lsmod | grep serial_ir
root@yaVDR:/home/yavdr# modprobe serial_ir
root@yaVDR:/home/yavdr# lsmod | grep serial_ir
serial_ir              20480  0
rc_core                45056  3 cx88xx,cx23885,serial_ir

    Damit ich weiterkomme, würde ich gerne eine Hilfe benötigen, wie ich bei yavdr-ansible vorgehen muss:

    • Wie muss ich vorgehen, damit das Modul "serial_ir" beim Start automatisch geladen wird?


    Paul

    Soweit ich das gelesen habe, muss man vor dem Laden von serial_ir dem Kernel sagen, dass er die Schnittstelle freigeben soll: /usr/bin/setserial /dev/ttyS0 uart none


    Wenn das zum gewünschten Ergebnis führt, kannst du dir z.B. eine Systemd-Unit anlegen, die das für dich beim Start automatisch macht:

    Code: /etc/systemd/system/load-serial_ir.service
    [Unit]
Description=Load serial_ir
[Service]
Type=oneshot
ExecStart=/usr/bin/setserial /dev/ttyS0 uart none
ExecStart=/usr/bin/modprobe -s serial_ir
[Install]
WantedBy=multi-user.target

    Und dann noch die Unit aktivieren, damit sie beim Starten ausgeführt wird:

    sudo systemctl enable load-serial_ir.service

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden