yavdr ansible

https://github.com/catalinii/minisatip/pull/594

Pull-Request wurde ohne Rückfragen übernommen.

Ich passe am Wochenende mal mein PKGBUILD an und stelle das dann bei VDR4Arch mit rein. Für x86 läuft das dann im Autobuild-Prozess mit und es werden Binärpakete bereitgestellt. Für ARM muss jeder selber bauen. Ich baue meine ARM-Pakete (einige wenige die ich brauche) auf einem RPi 4.

Die libmcli packe ich ins AUR. Das minisatip-PKGBUILD im AUR kann ich aber nicht anpassen.

Wie ist das mit der libmcli eigentlich für yavdr gelöst? Mir war /usr/include/mcast zu "unspezifisch". Deshalb ist es bei mir jetzt /usr/include/libmcli/mcast. Die Netceiver-Tools paketiere ich direkt mit ins libmcli-Paket.

Will minisatip eigentlich im Betrieb auch irgendwo auf die Platte schreiben? Muss ich dem User mit dem minisatip läuft irgendwo Schreibrechte geben oder läuft im Betrieb alles im RAM?

Soweit ich das in meinen Notizen habe, gibt es in den yaVDR PPAs für die Header zwei Möglichkeiten - einmal das Paket libmcli-dev, das die Header nach /usr/include/libmcli installiert und mcli-dev (wird aus dem Quelltext des vdr-plugin-mcli gebaut), das die Header direkt nach /usr/include/mcast bzw. /usr/include/mcli installieren würde. Für minisatip habe ich libmcli-dev als Abhängigkeit genutzt.

Zitat von M-Reimer

Will minisatip eigentlich im Betrieb auch irgendwo auf die Platte schreiben?

Es gibt zumindest eine Funktion, um eine .pid-Datei in /var/run/ anzulegen: https://github.com/catalinii/m…ter/src/minisatip.c#L1673, die in https://github.com/catalinii/m…ter/src/minisatip.c#L1773 aufgerufen wird.

Zitat von seahawk1986

Soweit ich das in meinen Notizen habe, gibt es in den yaVDR PPAs für die Header zwei Möglichkeiten - einmal das Paket libmcli-dev, das die Header nach /usr/include/libmcli installiert

Dann letztlich /usr/include/libmcli/mcast oder ohne das "mcast" am Ende?

Ohne "mcast" kann man das /usr/include/libmcli dann halt nicht einfach so bei minisatip beim Bauen angeben.

Zitat von seahawk1986

Es gibt zumindest eine Funktion, um eine .pid-Datei in /var/run/ anzulegen

/var/run ist RAM. Also kein Problem.

Ich würde dann also einfach mal versuchen keine schreibbaren Verzeichnisse vorzusehen. Bei Problemen kann man immer noch nachbessern.

Zitat von M-Reimer

Dann letztlich /usr/include/libmcli/mcast oder ohne das "mcast" am Ende?

Mit mcast als eines der Unterverzeichnisse (da gibt es auch noch Dateien in anderen Unterordnern) - das Paket ist immer noch dem Stand, den Frodo damals erstellt hat.

https://aur.archlinux.org/cgit…t/tree/PKGBUILD?h=libmcli

minisatip ist bei vdr4arch eingecheckt und läuft in nächster Zeit auch im Autobuild mit.

Auf dem Raspberry baue ich mir das eher kleine Tool dann selber.

Danke erstmal für die super Arbeit, hab den yavdr relativ schnell zum Laufen bekommen.

Brauche nur noch bei einem kleinem Thema Hilfe.

Bei yavdr 0.6 habe ich immer den menuorg-appswitcher zum Starten von Desktopapps aus der menorg.xml genommen. Den gibt es aber wohl jetzt nicht mehr.

Was habt ihr denn angedacht, stattdessen zu nehmen?

Zitat von flyingrobi

Was habt ihr denn angedacht, stattdessen zu nehmen?

Das desktop-Plugin (sollte als "Applikationen" im menuorg-Menü auftauchen) bildet die GNOME-Menüstruktur ab - wenn eine Anwendung eine .desktop-Datei mitbringt (oder du eine .desktop-Datei für eine Anwendung hinterlegst), kann man sie darüber "standalone" starten (unter der Voraussetzung, dass der Prozess nicht forkt oder sich sonst der Kontrolle durch die generische Systemd-Unit entzieht). Im Hintergrund wird dann über /var/lib/vdr/plugins/desktop/starter (was ein symbolischer Link auf /usr/bin/start-desktop ist) mit dem Pfad der .desktop Datei aufgerufen. Das yavdr-frontend sieht dann nach, ob es eine Systemd-Unit mit dem Namen gibt (abzüglich einer eventuell vorhandenen .desktop-Endung - das kann man z.B. nutzen, wenn Programme mit speziellen Argumenten gestartet werden müssen oder zum Beenden besondere Befehle nötig sind - vgl. z.B. /var/lib/vdr/.config/systemd/user/kodi.service) , ansonsten fällt es auf/usr/lib/systemd/user/app@.service zurück, für die dann eine Instanz mit dem Namen der Anwendung gestartet wird.

yavdr-frontend bietet außerdem eine DBus-API an, über die man den Wechsel je nach Anwendungszweck schöner steuern kann - für menuorg-Einträge bzw. die commands.conf des VDR gäbe es frontend-dbus-send start_desktop NAME_DER_DESKTOP_DATEI (alternativ kann man auch frontend-dbus-send switchto NAME_DER_DESKTOP_DATEI nutzen, dafür kann man auch die in der Konfigurationsdatei /etc/yavdr-frontend/config.yml im Abschnitt Applications definierten besonderen Namen wie "vdr", "mediacenter", "browser" usw. nutzen), wenn man mit einer Taste auf der Fernbedienung zwischen einer Anwendung und dem VDR-Frontend hin- und herschalten können will, wäre z.B. frontend-dbus-send switchbetween vdr NAME_DER_DESKTOP_DATEI eine Möglichkeit.

Wenn eine .desktop Datei (keine Systemd-Unit!) parallel zum VDR-Frontend über menuorg gestartet werden soll, kann man das mit dem Programm /usr/bin/run-desktop-file machen, da für den VDR passende Umgebungsvariablen gesetzt sind, um auf die Session zugreifen zu können.

Danke Seahawk für die sehr ausführliche Antwort. Das werde ich gleich ausprobieren.

Zitat von flyingrobi

Danke Seahawk für die sehr ausführliche Antwort. Das werde ich gleich ausprobieren.

Hat geklappt. Die .service Datei und wo sie gespeichert werden muss, war das fehlende Stückchen.

Hab "frontend-dbus-send switchto NAME_DER_DESKTOP_DATEI" in der menuorg.xml genommen.

Nochmals vielen Dank!

Hallo,

habe heute auf meinen beiden ansible vdrs heute ein apt dist-upgrade laufen lassen und seitdem auf beiden nur noch einen schwazen Bildschirm. Ich nutze minisatip auf meinem Haupt vdr und verbinde mich auf beiden vdr mit dem plugin-satip zu minisatip.

Der vdr scheint ohne Fehler zu starten, ich bekomme aber kein OSD und kann keine Kanäle mehr tunen.

Welche Logfiles soll ich am besten posten, damit mir vielleicht jemand weiterhelfen kann...

Danke schon mal...

Ich glaube minisatip dürfte nicht mehr laufen.

Hatte ich auch nach einem distupgrade auf meinem Server. Scheinbar ist da jetzt eine Abhängigkeit dazugekommen, die beim distupgrade nicht mitinstalliert wird.

Ich bin grade nicht am Rechner, müsste aber libmcli-dev sein.

Habe im Syslog etwas dazu gefunden:

user@vdr:~$ sudo cat /var/log/syslog | grep minisatip

Jul 26 20:49:46 vdr minisatip[1059]: /usr/bin/minisatip: error while loading shared libraries: libmcli.so: cannot open shared object file: No such file or directory

Jul 26 20:49:46 vdr systemd[1]: minisatip.service: Main process exited, code=exited, status=127/n/a

Jul 26 20:49:46 vdr systemd[1]: minisatip.service: Failed with result 'exit-code'.

EDIT:

Das installieren des Pakets libmcli behebt das Problem:

sudo apt install libmcli

na dann wie eben geschrieben libmcli-dev nachinstallieren

Merkwürdig, dass die Abhängigkeit da nicht über die ${shlibs:Depends} gezogen wird - ich habe gerade ein Paket hochgeladen, das eine Abhängigkeit zu libmcli hinzufügt.

Nachdem ich das Thema mit dem Starten von Programmen in der menuorg.conf mit eurer Hilfe jetzt hinbekommen habe, ist mir aufgefallen, dass ich über den Browser nur PCM Sound bekommen, sowohl beim Firefox als auch beim Chrome.

Ich hab mal parallel zum Browser pavucontrol gestartet, aber darin keine Lösung gefunden.

Der einzige Unterschied, den ich zwischen vdr und Browser in pavucontrol feststellen konnte, ist, dass der vdr über die alsalib reinkommt, der Browser aber direkt auf das pa device zugreift. Kenne mich leider nicht gut genug aus und finde via suche leider auch nichts was mir hilft.

Kann jemand helfen?

Von welchen Seiten erwartest du etwas anderes als PCM-Ton? Netflix beherrscht das laut eigener Aussage bei der Wiedergabe mit HTML5 Player oder Silverlight-Plugin keinen 5.1 Ton: https://help.netflix.com/de/node/14163

Zitat von seahawk1986

Von welchen Seiten erwartest du etwas anderes als PCM-Ton? Netflix beherrscht das laut eigener Aussage bei der Wiedergabe mit HTML5 Player oder Silverlight-Plugin keinen 5.1 Ton: https://help.netflix.com/de/node/14163

Ah, mit der Antwort habe ich jetzt nicht gerechnet. Bei YouTube ist das, laut Suche, wohl auch so.

Schade. Hatte gehofft, dass ich alles mit 5.1 Sound im vdr (ohne Kodi) hinbekomme.

Trotzdem Danke für die Klärung.

seahawk1986 ,

ich habe mal eine Frage zum Starten bzw. viel mehr zum Beenden von KODI und Rückkehr zum VDR.

Wie ich in diesem Thread [softhddevice] Werte für die allgemeine Bildeinstellung wie Helligkeit/Farbton usw. werden nach Neustart nicht aktiviert beschrieben habe, gibt es beim softhddevice-Plugin das Problem, dass die im Setup geänderten Werte bei einem Neustart vom VDR nicht aktiviert werden, sondern es werden immer die "Defaultwerte" verwendet. Das ist vermutlich ein kleiner Fehler im Programm und hat etwas mit dem ATTACH bzw. DETACH zu tun, aber das könnte nur der Plugin-Entwickler genauer sagen.

Da es momentan allerdings so aussieht, dass der Entwickler kaum noch aktiv ist und das an dem softhddevice-Plugin nicht mehr viel passiert, habe ich mir selbst geholfen.

Für den Neustart des VDR habe ich eine kleines Script geschrieben, in dem ich nach dem Starten des VDR den Wert für die Helligkeit im softhddevice-Plugin einmal neu setze und damit ist dann auch der Wert für die Helligkeit nach dem Neustart aktiviert. Das klappt einwandfrei.

vdr-dbus-send /Setup setup.Set string:"softhddevice.Brightness" variant:string:"0"
sleep 1
vdr-dbus-send /Setup setup.Set string:"softhddevice.Brightness" variant:string:"-40"

Wenn ich aber nun KODI über das OSD starte und dann irgendwann beende ist leider wieder das gleiche Verhalten wie vorher gegeben, d.h. der im Setup eingestellte Wert für die Helligkeit ist nicht aktiv und statt dessen wird wieder der Defaultwert "0" verwendet.

Jetzt muss ich immer manuell nochmals mein kleines Script anstoßen, damit der eingestellte Wert aus dem Setup aktiviert wird. Das ist nun doch nicht so optimal und es wäre besser, wenn das Script beim beenden von KODI automatisch nochmals aktiviert würde.

Deshalb meine Frage:

Wo muss ich ansetzen bzw. wo ist die Stelle, um mein Script nach dem beenden von KODI bzw. nach dem ATTACH des softhddevice-Plugins automatisch ausführen zu lassen?

Paul

Zitat von Paulaner

Wo muss ich ansetzen bzw. wo ist die Stelle, um mein Script nach dem beenden von KODI bzw. nach dem ATTACH des softhddevice-Plugins automatisch ausführen zu lassen?

Probier mal, ob es genügt die /usr/lib/python3/dist-packages/yavdr_frontend/frontends/softhddevice.py so anzupassen (danach einen Neustart machen):

from gi.repository import GLib
from .genericfrontend import SofthdBaseClass

class Softhddevice(SofthdBaseClass):
    name = 'softhddevice'

    def start(self, options=None):
        self.set_brightness("0")
        super().start(options)
        GLib.timeout_add_seconds(1, self.set_brightness, "-40")

    def set_brightness(self, value="0"):
        code, result = self.dbus2vdr.Setup.Set("softhddevice.Brightness", value)
        return False

Falls das so nicht klappt, kannst du versuchen die Zeile 8 und 9 vertauschen.

Um das Update-sicher zu machen, kannst du das in eine eigene Datei packen (z.B. eine softhddevice_custom.py im selben Ordner - keine Bindestriche im Dateinamen verwenden!) und dann in der /etc/yavdr-frontend/config.yml in Zeile 62 den Namen anpassen:

softhddevice:
            module_name: yavdr_frontend.frontends.softhddevice_custom
            class_name: Softhddevice
            use_pasuspend: False  # suspend pulseaudio while softhddevice is active, so it has direct ALSA access