Es ist kein Hardware Problem: VDR 2.2.0 auf trusty läuft wie vorher gewohnt und die Sender der DVB-S2 Karte sind nach dem Booten gleich sichtbar; im syslog sind keine segfaults des softhddevice.
Es scheint sich also tatsächlich um ein Software Problem zu handeln. Auf der Bionic Installation habe ich gesehen, dass ein vdr-plugin-softhddevice zur Verfügung steht. Es ist für VDR 2.3.8. Ich werde es mal für VDR 2.4 bauen, um zu sehen, ob es besser als das vdr-plugin-softhddevice-openglosd läuft.
Ich habe das Bauen vom vdr-plugin-softhddevice sein lassen, denn er ist über 2 Jahre alt und installiert viele Wayland Packet; ich wollte die yavdr ansible installation nicht zerstören, denn sie scheint mir X und nicht Wayland zu nutzen.
Im folgenden Spoiler befindet sich ein Auszug der syslog, wo ich mit dem VDR 2.4 boote; eingestellt ist ein Sender der DVB-S2 Karte; bei Zeitindex 17:06:29 schalte ich blind auf einen Sender der DVB-C Karte und das Bild erscheint.
Vielleicht kann jemand mir weiterhelfen.
MfG
Hast du eventuell Logs von den weiter oben beschriebenen Crashes oder zumindest ein komplettes Syslog ab Boot (journalctl -b -l)?
Was ist die Ausgabe von vdr --showargs? Mich wundert etwas, dass der VDR beim Start nicht versucht einen Sender zu tunen.
Wegen der 10000 Zeichen Grenze hier im Board, musste ich in meiner vorherigen Antwort den syslog ziemlich abkürzen.
Das syslog mit den Crashes habe ich leider nicht mehr; ich hatte jedoch einen neuen. Die Crashes kommen hauptsächlichvor, wenn ich auf TV5 Monde und France 24 auf Hotbird schalte. (Ich habe die channels.conf und wegen des Monoblocks die diseqc aus dem VDR 2.2 übernommen; ich nehme jedoch an, dass dies kein Problem sein sollte.)
Betrachte ich all die Probleme die ich mit bionic und VDR 2.4 habe, frage ich mich, ob es nicht sinnvoller ist, auf VDR 2.2 und trusty zurückzugehen.
Die Crashes kommen hauptsächlichvor, wenn ich auf TV5 Monde und France 24 auf Hotbird schalte.
Das scheint an ffmpeg zu hängen, am Quellcode von softhddevice-openglosd hat sich gegenüber dem Stand in den PPAs für den VDR 2.4.0 eigentlich nichts geändert. Hast du diese Crashes auch, wenn du das Paket vdr-plugin-softhddevice-vdpau-hevc installierst (das verwendet ffmpeg 3.3 statt ffmpeg 3.4)?
Kommt mir irgendwie bekannt vor. Ich habe solche Crashes auf BBC1 HD.
Treten auch mit softhddevice auf (selbst gebaut). Und auch mit ofthddevice-openglosd, Und auch mit vdr-plugin-softhddevice-vdpau-hevc.
Auch ich habe die Crashes mit dem vdr-plugin-softhddevice-vdpau-hevc. Ich benutze jedoch nicht eine selbstgebaute Version, sondern die Version aus dem PPA, der von yavdr ansible hinzugefügt wurde. Außerdem, sind auch die Farben des LCARS OSD verfälscht.
Hi,
in welcher Auflösung senden denn die von den Segfaults betroffenen Kanäle?
Ich habe auch ein Problem mit "krummen" Formaten, das ich schon länger reportet habe:
softhddevice - Sender in 1920x1090 - VDR startet neu
Das besteht bei diesem Sender auch unter aktuellem yavdr-ansible noch,....
Hallo,
bin auch gerade dabei yavdr-ansible zu installieren.
Leider bricht die Installation mit dieser Meldung ab:
TASK [yavdr-desktop : enable and start yavdr-xorg for the vdr user] *************************************************************************************************************************************************************************
fatal: [localhost]: FAILED! => {"changed": false, "msg": "Unable to start service yavdr-xorg: A dependency job for yavdr-xorg.service failed. See 'journalctl -xe' for details.\n"}journalctl -xe gibt folgendes aus:
Verbaut ist eine Nvidia 630er.
Mach mal einen Reboot und lass den Installer noch mal laufen - bei älteren nvidia-Karten scheint das Laden des Treibers direkt nach der Installation des Pakets nicht zuverlässig zu funktionieren.
Danke. Das war es.
Gibt es eigentlich noch das template-System vom "alten" yavdr? Oder wie kann ich meine angepassten Daten für die Fernbedienung einbinden?
Es gibt noch Templates, aber statt Clearsilver nutze ich jinja2 (u.a. weil das von Ansible direkt unterstützt wird) - für die /etc/rc_maps.cfg sieht das aktuell so aus: https://github.com/yavdr/yavdr…/templates/rc_maps.cfg.j2
Ich habe da gerade noch den Hinweis ergänzt, dass die Datei von Ansible verwaltet wird, dann schreibt er automatisch in den Header, wo das Template lag, aus dem die Datei generiert wurde, also z.B.:
$ cat /etc/rc_maps.cfg
#
# *** ANSIBLE MANAGED FILE ***
# template: /home/install_user/yavdr-ansible/roles/yavdr-remote/templates/rc_maps.cfg.j2
#Statt jedes Mal install-yavdr.sh komplett durchlaufen zu lassen, kann man einzelne Rollen gezielt ausführen - also z.B. um yavdr-remote erneut laufen zu lassen:
sudo -H ansible-playbook -i "localhost," --connection=local --tags="yavdr-remote" yavdr07.ymlSchau ich mal. Betrifft ja nur eine Taste.
Die Templates habe ich gefunden. Wo müssen denn dann die angepassten Dateien hinkopiert werden?
Mit dem Ausführen der Rolle wird das dann verarbeitet? Analog zu früher mit process-templatate?
Dann noch eine Frage ... menuorg ist ja nun nicht mehr essentieller Bestandteil. Kann das trotzdem noch normal installiert werden zum Anpassen des Menüs? Wurde ja früher auch aus Templates generiert.
Die Menuorg-Integration in yavdr-ansible fehlt noch, aber prinzipiell sollte das Plugin nutzbar sein - einfach eine /var/lib/vdr/plugins/menuorg.xml mit dem gewünschten Inhalt anlegen.
Was sich gegenüber yaVDR 0.6 geändert hat, sind die Skripte zum Starten von Anwendungen - mit Upstart war das ja so gelöst, dass menuorg über Umwege initctl mit root-Rechten aufgerufen hat, um dann Upstart-Units zu stoppen/starten, für KODI sah das z.B. so aus:
<command name="Kodi" execute="echo /usr/share/vdr/menuorg-appswitcher standalone=yes app=kodi display=1 | at now > /dev/null " />
Bei yavdr-ansible ist das Starten von Desktop-Anwendungen rein in der User-Session in Zusammenspiel mit dem Frontend-Skript gelöst - OOTB kann man Anwendungen über das desktop-Plugin (Menü-Eintrag "Desktop") starten, das die Menü-Struktur anhand der von GNOME gewohnten Menü-Kategorien nachbildet. Nahezu jedes Programm, das eine .desktop-Datei mitbringt sollte sich damit starten lassen, ggf. muss man etwas nacharbeiten, damit Systemd den Prozess richtig Überwachen und bestimmte Exit-Codes verdauen kann. Wenn da Interesse besteht, kann ich da noch mehr dazu schreiben.
Für menuorg würde der Befehl zum Umschalten dann so aussehen:
<command name="Kodi" execute="frontend-dbus-send switchto kodi" />
Oder wenn man das lieber über eine Taste auf der Fernbedienung machen will, kann man das in der /var/lib/vdr/.lircrc eintragen, um mit KEY_HOME zwischen kodi und dem VDR-Frontend zu wechseln:
$ cat /var/lib/vdr/.lircrc
begin
prog = irexec
button = KEY_HOME
config = frontend-dbus-send switchbetween kodi vdr
endHallo seahawk1986,
Könntest du mir bitte sagen, ob es möglich wäre, die xenial branch von yavdr ansible weiter zu pflegen? Ich finde sie besonders interessant für Personen, die VDR 2.2 auf xenial laufen lassen möchten, weil sie noch zu viele Probleme mit VDR 2.4 haben und einen moderneren Unterbau benötigen, um zum Beispiel Kodi 18 benutzen zu können.
Falls die xenial branch weiter gepflegt wird, wäre vielleicht folgendes Problem zu beheben: jedesmal wenn ich install-yavdr.sh laufen lasse, setzt er erneut die PPAs, so dass sie mehrfach vorkommen, und ich sie immer wieder löschen muss.
Außerdem würde ich in dem Fall vorschlagen, auch die Pakete für yavdr ansible xenial mit in die experimental-* PPAs aufzunehmen, anstatt auf die unstable-* von yavdr aufzubauen.
Schließlich, würde ich noch vorschlagen die von ansible benutzen PPAs von experimental-* zum Beispiel nach ansible-* umzubennen, um sie von den veralteten experimental-* zu unterscheiden.
Ich bin mir bewusst, dass das alles ziemlich viel Arbeit bedeutet; aber vielleicht wird die benötigte Zeit durch weniger notwendigen Support wieder eingenommen.
Auf jeden Fall, nochmals vielen Dank für die viele Arbeit, die du schon in yavdr ansible gesteckt hast, auch falls du die entscheidest, die xenial branch nicht weiter zu pflegen.
MfG
Ich schätze mal, dass man durchaus Pull Requests schicken kann, um die ein oder andere Baustelle zu beheben.
Alternative wäre aber ggf. ein anderes PPA, wo man vdr 2.2 Pakete ablegt, um dann doch 18.04 nutzen zu können.
Lars.
Alternative wäre aber ggf. ein anderes PPA, wo man vdr 2.2 Pakete ablegt, um dann doch 18.04 nutzen zu können.
Ich frage mich, ob es ausreichen würde, ein experimental-vdr-2-2 hinzuzufügen, um bionic als Unterbau zu benutzen, oder ob auch ein experimental-yavdr-2-2 notwendig wäre.
Welche bekannten Probleme gibt es denn noch mit vdr 2.4?
Wäre es nicht besser, Zeit in die Lösung dieser Probleme zu inverstieren?
Der Grund für mich auf Bionic zu gehen war ja gerade, dass dort endlich das network-online.target halbwegs brauchbar funktioniert und man ein halbwegs aktuelles Python 3.6 und Systemd hat. Wenn man da Sachen für xenial zurückportieren wollte, wäre das für bestimmte Dinge ein nicht zu unterschätzender Aufwand - wer dazu Lust hat, kann sich da gerne reinfuchsen, aber mir ist es wichtiger meine begrenzte Zeit in die Weiterentwicklung für bionic zu stecken.
Was man sich überlegen könnte (ich habe meinen Produktiv-VDR noch nicht umgestellt und daher noch keine echten Langzeiterfahrungen) ist, ob man einen VDR 2.2.0 für bionic baut (ggf. mit Extrawürsten wie ein gegen ffmpeg 3.2 gebautes softhddevice-openglosd für Leute, die kein DVB-T2 brauchen, da das so weniger crash-freudig sein soll) - das sollte nicht besonders schwer sein, kostet aber einfach Zeit.
Der VDR und die Plugins sind von der API her stabil genug geblieben, dass der Rest von yavdr-ansible ohne Anpassungen dazu passen sollte.
Schließlich, würde ich noch vorschlagen die von ansible benutzen PPAs von experimental-* zum Beispiel nach ansible-* umzubennen, um sie von den veralteten experimental-* zu unterscheiden.
experimental-kodi wird neu befüllt, sobald es ein KODI 18 Release gibt und experimental-yavdr bekommt neue Inhalte, wenn es sich lohnt. Bislang haben die yavdr-* Pakete in experimental-main keine so desktruktive Ader wie einige yavdr-* Pakete aus früheren yaVDR-Versionen. PPAs kann man nicht umbenennen, sondern muss sie komplett neu anlegen und kann dann bestehende Pakete reinkopieren oder neu bauen lassen. Ansible hat mit den Paketen nichts direkt zu tun - die funktionieren auch eigenständig ohne ein Ansible-Playbook, das nimmt es dem Nutzer lediglich ab das System komplett von Hand zu konfigurieren.
Welche bekannten Probleme gibt es denn noch mit vdr 2.4?
Zum Beispiel deinen Thread von letzter Woche: vdr crasht beim Anlegen eines Timers - ich bin noch nicht dazu gekommen, da den Ablauf im Quellcode nachzuvollziehen.
Vielen Dank für die vielen Erläuterungen.
Ich war auch in der Lage die Ursache für die doppelte Installation der PPAs finden. Bei mir waren die PPAs schon vorinstalliert und ihre URI endete mit einem Slash; der yavdr-installer.sh fügt sie ohne / am Ende der URI hinzu.
Für Kodi 18 benutze ich die unstable PPA des XBMC Teams. Dies ist auch der Hauptgrund warum ich versuche, auf xenial oder bionic umzusteigen: die neueren Kodi Versionen laufen nicht auf trusty; soweit ich lesen konnte.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
