Also Frage: Kann man es einstellen, das der VDR dauerhaft zu einem festen Zeitpunkt angeht, natürlich unter Berücksichtigung evtl. anderer Timer, um das EPG zu aktualisieren bzw. aufzunehmen?
Ja, das geht über das vdr-addon-acpiwakeup - siehe https://www.yavdr.org/document…_acpiwakeup_conf_emphasis
An den Paketen für bionic habe ich schon seit mehreren Wochen nichts mehr geändert - osd2web scheint zumindest in einer VM mit dem aktuellen Stand keine Probleme zu machen. Was war denn im Log zu sehen und welches Ausgabeplugin war dabei aktiv?
Beide Pakete stammen aus dem PPA.
Aus welchem PPA? Was sagt apt policy vdr vdr-plugin-skindesigner vdr-plugin-osd2web?
AFAIK braucht das ffmpeg 4.2.x, was nicht in den regulären Paketquellen enthalten ist - und ohne vdr-osr-browser macht es wenig Sinn das vdr-plugin-hbbtv Paket zu bauen.
Sieht so aus, als ob das ein häufiger auftretendes Problem mit dem x264-Decoder in Verbindung mit vdpau ist: https://forums.developer.nvidi…0-68-ccmds-00000014/53648
Probier mal als Workaround die Ausgabe mit vdr-plugin-softhdcuvid oder dem Paket vdr-plugin-softhddevice-cuvid (da muss dann noch -v cuvid in der /etc/vdr/conf.avail/softhddevive.conf ergänzt werden) zu machen.
Jun 28 00:56:00 vdr kernel: [42785.382952] NVRM: Xid (PCI:0000:01:00): 68, pid=18741, CCMDs 00000013 0000c2b0
Xid 68 kann laut https://docs.nvidia.com/deploy/xid-errors/index.html#topic_4 ein Treiber- oder Hardwareproblem sein.
Was sagt denn nvidia-smi -q, wenn das aufgetreten ist?
Laut https://docs.nvidia.com/deploy…rors/index.html#topic_3_2 wäre es einen Versuch wert einen Bugreport bei nvidia aufzumachen.
Da da außerdem noch ein I/O Throttle zuschlägt, würde ich mal in dmesg schauen, ob es um die Zeit herum irgendwelche Fehlermeldungen von Seiten des Kernels gab.
Was steht denn im Log, wenn der VDR startet? Hat der die nötigen Berechtigungen, um auf die serielle Schnittstelle zuzugreifen (was sagt ls -l /dev/ttyS1 und groups vdr) ?
Also spielt das Warten auf den Start von nmbd keine Rolle bei der Verzögerung des Bootvorgangs und 20 Sekunden sind für ein ION-System nicht schlecht.
Die multipath-tools, die die multipathd.service installieren, sind wie es aussieht eine Abhängigkeit des Pakets ubuntu-server, das man prinzipiell deinstallieren kann, wenn man es nicht braucht - damit sollte man sich das Warten auf systemd-udev-settle.service sparen können. Man sollte dabei nur aufpassen welche automatisch installierten Pakete dann bei einem apt-autoremove vom System geworfen werden und die noch benötigten als manuell installiert markieren.
PS: Häng die boot.svg einfach an, vom Kopf der Datei in dem Ausschnitt, den du mit nano siehst, hat niemand etwas.
Gibt es eine Stelle, an der man das Debug von yavdr-frontend deaktivieren kann?
Ja, man kann den Loglevel als Startargument setzen:
Also z.B. eine /var/lib/vdr/sytemd/user/yavdr-frontend.service.d/nodebug.conf mit diesem Inhalt anlegen, wenn man nur kritische Fehler sehen möchte:
Was liefert denn systemd-analyze critical-chain bzw. wie sieht das im Gesamtzusammenhang aus, wenn du den Bootvorgang plotten lässt? systemd-analyze plot > boot.svg
Das sieht so aus, als wäre da die Intel IGP parallel zur nvidia-Karte aktiv - nach Möglichkeit würde ich die Intel IGP im Bios abschalten.
Ansonsten kannst du die Zeilen https://github.com/yavdr/yavdr…tasks/detect-xorg.yml#L56 bis https://github.com/yavdr/yavdr…tasks/detect-xorg.yml#L96 für den Block auskommentieren, der versucht den noveau-Treiber und die daran hängenden Module zu entladen - das ist dazu gedacht, dass man ohne Reboot nach der Installation des nvidia-Treibers eine Bildschirmerkennung machen kann aber das klappt nur, wenn es keine anderen Grafiktreiber gibt, die auf KMS setzen.,
Kannst du in dem Core (bzw. einem erneut provozierten Crash mit gdb) schauen, wie die Variablen in den Frames für cPlugin::SetupStore(char const*, int) und cSatipPluginSetup::Store() aussehen?
Also für den gezeigten Fall, wo die in #0 und #1 stecken:
lag an der allowed_hosts.conf jetzt ist alles wieder gut
Das kann man übrigens auch über das Playbook vorkonfigurieren: https://github.com/yavdr/yavdr…bionic/group_vars/all#L39
Das vdr-plugin-live kannst du nachinstallieren, ein Webfrontend zur Konfiguration fehlt noch.
Bislang ist die Idee die Installation durch Anpassung des Playbooks zu konfigurieren, damit man das bei Bedarf jederzeit wieder so ausrollen kann.
Schau doch mal, ob du an einen aussagekräftigen segfault kommst (dazu sollten der VDR und die Plugins mit Debug-Symbolen gebaut worden sein - in den yaVDR-PPAs gibt es jeweils *-dbg Pakete mit den Debug-Symbolen, also vdr-dbg, vdr-plugin-satip-dbg usw.).
Zu Fuß mit gdb geht das z.B. so:
markad-ng wäre auch zu aktualisieren
Ich hab mal das neueste Release hochgeladen.
Ich habe es gerade hochgeladen: https://launchpad.net/~yavdr/+…ntal-main/+build/19469300
was kann ich bei der Installation ändern das es gleich das richtige Verzeichnis verwendet
Sorg dafür, dass das Paket libmariadb-dev-compat installiert ist. mysql_config kann aus zwei Paketen installiert werden, zum einen für MySQL (Paket libmysqlclient-dev) und eben das genannte für mariadb.
Das Zielverzeichnis wird aus der Ausgabe von mysql_config --plugindir ermittelt (vgl. https://projects.vdr-developer…t/tree/epglv/Makefile#n28 - das passende mysql_config steckt im Paket libmariadb-dev-compat).
Auf einem Ubuntu 20.04 System sollte das folgendes Ergebnis liefern:
Ja, da ist eine Neuinstallation leider der einzig sinnvolle Weg, da sich durch den Wechsel von Upstart zu Systemd sehr viel am Unterbau geändert hat. yavdr-ansible gibt es für bionic und focal.
