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.

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

seahawk1986 wrote:

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.

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

OleS wrote:

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?

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:

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

Cheers,

Ole

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.

OleS wrote:

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.

seahawk1986 wrote:

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?

seahawk1986 wrote:

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

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

Paulaner wrote:

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.

Paulaner wrote:

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

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

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.

• 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

Quote

• 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

wannseheichwas wrote:

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:

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

seahawk1986 wrote:

... 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:

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:

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

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

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:

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

sudo systemctl enable load-serial_ir.service