Beiträge von seahawk1986

    Hast du Systemd auf dem Server? Mit einem systemd.timer kann man direkt einen Unix-Timestamp, wie ihn der VDR an das Shutdown-Skript übergibt nutzen (vgl. https://www.freedesktop.org/so…html#Parsing%20Timestamps).


    Wenn man keinen Timer als Datei auf die Platte schreiben will, dann wäre das im Shutdown-Skript auch recht bequem mit systemd-run möglich (das Skript muss mit root-Rechten ausgeführt werden):

    Shell-Script
    1. #!/bin/bash
    2. timer=$1
    3. StartAhead=300 # start 5 Minutes early
    4. timestamp=$(( timer + StartAhead ))
    5. systemd-run --on-calendar=@${timestamp} --unit=vdr.service
    6. systemctl --no-block stop vdr

    KODI 18 aus dem ppa:team-xbmc/xbmc-nightly sollte unter bionic mit yavdr-ansible funktionieren, wenn man der Lircmap.xml und der remote.xml einen Header verpasst:


    Bei den Start-Zeiten bin ich jetzt statt über netplan direkt über systemd-networkd gegangen, statt den ipv6-Stack komplett zu deaktivieren (was eine Reihe von Problemen mit Diensten verursacht, die so vorkonfiguriert sind, dass sie zumindest IPv6 für localhost erwarten) - also z.B. wenn man nur DHCP für IPv4 nutzen will und sowohl eine statische als auch eine dynamisch zugewiesene IPv4-Addresse will:

    Damit sehen die Bootzeiten gut aus:

    Was ist denn das Programm "Terminal" und von welchem Betriebssystem reden wir?

    Hast du die serielle Schnittstelle am GlobalCache-Gerät auf die richtigen Parameter eingestellt?


    Kannst du den TV von dem Rechner mit der Seriellen Schnittstelle aus steuern?

    Ich habe mit dem Programm "Terminal" z. B. den Befehl 'ka 00' eingeben

    Das ist leider keine für mich eindeutig nachvollziehbare Beschreibung deines Vorgehens. Schon allein, weil nicht eindeutig ist, auf welches Programm du dich beziehst.

    in Sämtlichen Variationen, wie 'k a 00' oder 'ka 01 00' oder 'ka 00\n' und viele mehr.

    Schau mal ins Handbuch des TV, da ist das Protokoll genau beschrieben. Er erwartet einen Carriage Return (\r) am Ende des Befehls. Die erste Zahl ist die Set ID und von der Einstellung im TV abhängig. Warum nimmst du nicht das Python-Skript, das weiter oben gepostet wurde als Grundlage für eigene Experimente?

    Bei VDR4arch wird dieser Patch für den VDR 2.2.0 genutzt: https://github.com/VDR4Arch/vd…r-stable/vdr/PKGBUILD#L22

    evtl. habe ich es übersehen, aber gibt es irgendwo eine Liste compilierbarer und lauffähiger Plugins für vdr 2.3.x?

    In meinem PPA für den VDR 2.3.9 findest du die kompilierbaren Plugins und in den Quellpaketen die ggf. dafür benötigten Patches: https://launchpad.net/~seahawk…+archive/ubuntu/vdr-2.3.9


    Zur Lauffähigkeit kann ich da nur eingeschränkt etwas sagen, ich nutze nur einen kleinen Teil davon.

    Für das Channellists-Plugin gibt es in https://github.com/zulu-entert…t/vdr-plugin-channellists eine aktuelle Version, für dvbhddevice sollte es der Patch von Klaus tun: Produktive Problem- und Pluginlösungen für VDR 2.3.2 und höher


    Für xineliboutput willst du die aktuelle Git-Version: https://sourceforge.net/p/xineliboutput/git/ci/master/tree/

    Und beim remote-Plugin sollte es die Version 0.7.0 tun: [ANNOUNCE] Remote Control Plugin 0.7.0

    Wo fange ich da an zu suchen, bin für jeden Tip dankbar!

    Wenn ich das richtig im Kopf habe, wird der VDR in der Vorkonfiguration beim Auslösen des Standby nicht gestoppt. Du kannst in der Datei /etc/yavdr/force-reload-services.list (die musst du anlegen, falls sie noch nicht existiert) Dienste eintragen, die nach dem Aufwachen neu gestartet werden sollen.

    Code: /etc/yavdr/force-reload-services.list
    1. vdr

    Falls das nicht genügt, schau mal in die Logdateien (dmesg und syslog), da sollte man sehen, was da genau passiert.


    Für das Entladen und erneute Laden von Kernelmodulen ist die /etc/yavdr/force-reload-modules.list vorgesehen. Auch hier kommt ein Eintrag pro Zeile. Die Reihenfolge ist Dienste stoppen, Module entladen, Module laden, Dienste starten: https://github.com/yavdr/yavdr…30force-reload/10_main#L3

    Der audioonly-Patch ist für das squeezebox-Plugin (IIRC heißt der im Paket so, weil horchi mir den mal mit dem Namen geschickt hat): https://github.com/horchi/vdr-…/softhddevice-0.6.1.patch

    Und der add_device_name.patch sorgt dafür, dass man mit dbus2vdr bzw. dem svdrp-Befehl LSTD einen brauchbaren Namen für das Ausgabeplugin bekommt (damit man es leichter hat, wenn man das primäre Frontend programmatisch ändern und dabei verschiedene Varianten unterscheiden können will) - für softhddevice-vpp sieht das z.B. so aus:

    Diff
    1. --- a/softhddevice.cpp
    2. +++ b/softhddevice.cpp
    3. @@ -2340,6 +2340,7 @@
    4. cSoftHdDevice(void);
    5. virtual ~ cSoftHdDevice(void);
    6. + virtual cString DeviceName(void) const { return "softhddevice-vpp"; }
    7. virtual bool HasDecoder(void) const;
    8. virtual bool CanReplay(void) const;
    9. virtual bool SetPlayMode(ePlayMode);

    Könnte das ein (altbekannter) Bug von gdebi sein? https://bugs.launchpad.net/gdebi/+bug/396684


    Ich habe meine pbuilder-Konfiguration ausgehend von https://filthypants.blogspot.d…pbuilder-to-act-like.html aufgebaut, damit sich das möglichst wie Launchpad verhält:

    Damit baut das Paket ganz brav: pbuilder_satip.log.txt

    aber wie weiss dann der pbuilder, das er mein neues vdr-dev benutzen soll?

    Du übergibst ihm das lokale Repository in der ~/.pbuilderrc als zusätzliche Paketquelle und aktualisierst danach die pbuilder-Konfiguration mit sudo pbuilder --update --override-config


    Es gewinnt immer das vdr-dev Paket mit der höchsten Versionsnummer (es sei denn du machst in den Build-Dependencies der Plugins explizit Versionsangaben). Das PPA mit den yaVDR VDR Paketen musst du ja nicht in die Liste aufnehmen, wenn du eine eigene Paketquelle aufmachst (aber ppa:yavdr/experimental-main bietet sich an, wenn du die benötigten Pakete nicht auch alle lokal bauen lassen willst), damit musst du nur aktueller sein als das vdr-dev Paket in den regulären Ubuntu-Paketuquellen.