Beiträge von HagenS

    Nein - funktioniert tatsächlich nicht. Wenn ich das absetze passiert genau GAR NIX. Im Kodi-Log taucht während der Aktion auch überhaupt nichts auf, auch nicht mit aktiviertem Debug...
    Hoffentlich liegt das nicht an der 19er Version, die hier seit ein paar Tagen läuft... Bisher hatte ich eigentlich keinen Downgrade vor - zumal er ja auch einiges verändert hat nach dem Umstieg.

    Ich habe mir als root mit tmux -S /tmp/tmux-666/default eine Shell für den vdr-Nutzer gestartet und dann bei laufendem vdr-Frontend dort frontend-dbus-send switchto kodi abgesetzt - dabei startet Kodi. Soweit gut. Danach dann in der gleichen Shell den Befehl für den Wechsel zurück - das klappt dann nicht:

    Ich hab noch eine Frage zum Frontend-Handling:


    Wenn ich - während vdr läuft - in einer vdr-Nutzer-Shell den Befehl frontend-dbus-send switchto kodi absetze, dann beendet sich das softhddevice-cuvid Frontend und kodi startet. Soweit alles gut.


    Wenn ich aber während Kodi läuft in der gleichen Shell den Befehl frontend-dbus-send switchto vdr absetze, dann wird (irgendwann) zwar Kodi beendet, aber eben leider nicht das vdr-Frontend neu gestartet. Ich sehe dann nur den schwarzen Hintergrund mit dem yavdr-Logo in der Mitte.


    Der Wechsel von kodi zurück klappt hingegen, wenn ich in Kodi auf "beenden" gehe. Ich würde aber gern extern getriggert "umschalten".


    Mache ich da was falsch?

    Perfekt - Danke! Tolle und sehr informative und auch noch ausführliche Antwort. Bin begeistert.


    Meine Tastatur wird also NICHT vom eventlircd überwacht - deswegen bleibt die bisher schon vorgenommene Anpassung der .lircrc wirkungslos. Wieder was gelernt...


    Ich denke, ich werde zuerst den Weg über die keymacros versuchen (oder dann weiter die anderen Optionen austesten).

    seahawk1986 Ich leg mir grad die Karten bzgl. einer Anpassung der Konfig der Steuerung meines sonst hervorragend funktionierenden yavdr-ansible (focal) - vielleicht kannst Du mir kurz auf die Sprünge helfen...?


    Ich steuere mein System an sich nur per Tastatur und setze als IR-FB eine Logi Harmony ein, welche ihre Signale an einen flirc sendet - der ja dann wieder "normale" Tastendrücke erzeugt (die ich entsprechend gemapped habe).


    Ich würde jetzt gern ein Script auf eine bestimmte Taste meiner Tastatur legen - angedacht war "F5". Ich finde über evtest nach Auswahl der Tastatur auch den Tastendruck:

    Code
    Testing ... (interrupt to exit)
    Event: time 1613753567.635346, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7003e
    Event: time 1613753567.635346, type 1 (EV_KEY), code 63 (KEY_F5), value 1
    Event: time 1613753567.635346, -------------- SYN_REPORT ------------
    Event: time 1613753567.805363, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7003e
    Event: time 1613753567.805363, type 1 (EV_KEY), code 63 (KEY_F5), value 0
    Event: time 1613753567.805363, -------------- SYN_REPORT ------------

    Aber WO genau kann ich denn nun hinterlegen, dass er bei "KEY_F5" eben genau mein Script startet...??? Ich suche schon ewig und alles was ich finde bezieht sich irgendwie auf Tasten einer "echten" IR (!) Fernbedienung :wand


    ...Hagen

    Ich habe das für mich zwischenzeitlich mit dem Tool "swatch" gelöst, welches auf bestimmte Zeilen im syslog reagiert und so Aktionen im Fehlerfall auslöst.


    Die entsprechende config sieht bei mir SO aus:

    Code: /etc/swatch/swatch_patterns.cfg
    watchfor /DDCI-Err: can't write to CI adapter/
          exec /root/ca-reset.sh
    watchfor /info: Kanal nicht verfügbar/
          exec /root/ca-reset.sh
    watchfor /skipped channels/
          exec /root/ca-reset.sh

    Bei den entsprechenden Events startet ein kleines Script, welches letztlich per svdrp-Tastendruck (mangels direktem Befehl) einen CA-Reset auslöst:

    Ich hab bei mir da noch den EPG-Reload drin (wegen der manchmal fehlenden EPG-Bilder am osd2web) - das ist aber eher Kosmetik...


    Seitdem das aktiv ist habe ich keine Probleme mehr mit verpassten Aufnahmen und finde das eigentlich ganz brauchbar. Einen kompletten vdr Restart würde ich eher nicht vorziehen.

    Ich habe ein Paket mit den von wirbel vorgeschlagenen Änderungen bauen lassen - auf meinem Testsystem funktioniert menuorg damit wieder.

    Toll...! :thumbup:


    Bin wieder einmal begeistert, wie schnell bei so etwas reagiert wird und direkt leicht nachnutzbare Lösungen bereitgestellt werden. Ganz großes Kino hier - nur falls das sonst vielleicht zu kurz kommen sollte. Dank an alle. Bei mir läuft es jetzt mit aktiviertem Plugin ohne Probleme.

    Seit dem Update auf die neue VDR git in Seahawks vdr-2.4.5-patches ppa crasht bei mir der vdr, wenn das menuorg Plugin aktiviert ist:


    Mit deaktiviertem Plugin startet er normal.


    Gruß...


    ...Hagen

    Hab eben auf 2.4.5-patches gewechselt und bekomme jetzt beim VDR-Start Segfaults beim Boblight- und beim Skindesigner-Plugin. Hier mal exemplarisch:

    Code
    Oct 26 17:13:46 yavdr vdr: BOBLIGHT: boblight Thread started (pid=3517)
    Oct 26 17:13:46 yavdr vdr: BOBLIGHT: Connected to boblight
    Oct 26 17:13:46 yavdr kernel: [  331.774265] vdr[3544]: segfault at 0 ip 00007f254c4d4848 sp 00007f251e7fbce0 error 4 in libvdr-vdrboblight.so.2.4.5[7f254c4d2000+5000]
    Oct 26 17:13:46 yavdr kernel: [  331.774271] Code: 00 00 48 89 ef e8 58 de ff ff 49 8b 74 24 68 4c 8d 64 24 20 4c 8d 44 24 0c 48 8d 0d e5 29 00 00 48 8d 15 df 29 00 00 4c 89 e7 <48> 8b 06 ff 90 98 00 00 00 4c 89 e6 48 89 ef e8 e4 dd ff ff 4c 89
    Oct 26 17:13:46 yavdr boblightd[710]: (CClientsHandler::Process)      127.0.0.1:44628 Connection closed
    Oct 26 17:13:46 yavdr boblightd[710]: (CClientsHandler::RemoveClient) removing 127.0.0.1:44628

    Was kann das sein?

    Ok - Ursache gefunden. Wie so oft etwas ganz triviales - bei Umstellen ist (warum auch immer) kein softhddevice-Plugin aus dem neuen PPA installiert worden. Es war zumindest keins vorhanden (was mir im Remote-Zugriff nicht sofort aufgefallen war), so dass es für boblight und skindesigner eher schwer war am Leben zu bleiben.


    Leider gibt es in dem Fall keine aussagekräftige Fehlermeldung - deswegen hat es etwas länger gedauert. Läuft jetzt aber wieder...!

    Hab eben auf 2.4.5-patches gewechselt und bekomme jetzt beim VDR-Start Segfaults beim Boblight- und beim Skindesigner-Plugin. Hier mal exemplarisch:

    Code
    Oct 26 17:13:46 yavdr vdr: BOBLIGHT: boblight Thread started (pid=3517)
    Oct 26 17:13:46 yavdr vdr: BOBLIGHT: Connected to boblight
    Oct 26 17:13:46 yavdr kernel: [  331.774265] vdr[3544]: segfault at 0 ip 00007f254c4d4848 sp 00007f251e7fbce0 error 4 in libvdr-vdrboblight.so.2.4.5[7f254c4d2000+5000]
    Oct 26 17:13:46 yavdr kernel: [  331.774271] Code: 00 00 48 89 ef e8 58 de ff ff 49 8b 74 24 68 4c 8d 64 24 20 4c 8d 44 24 0c 48 8d 0d e5 29 00 00 48 8d 15 df 29 00 00 4c 89 e7 <48> 8b 06 ff 90 98 00 00 00 4c 89 e6 48 89 ef e8 e4 dd ff ff 4c 89
    Oct 26 17:13:46 yavdr boblightd[710]: (CClientsHandler::Process)      127.0.0.1:44628 Connection closed
    Oct 26 17:13:46 yavdr boblightd[710]: (CClientsHandler::RemoveClient) removing 127.0.0.1:44628

    Was kann das sein?

    Das Template für das Skript, das die Mountpunkte ins Aufnahmeverzeichnis des VDR verlinkt, sieht so aus: https://github.com/yavdr/yavdr…iskie_vdr_mount_helper.j2 - das sollte aufgrund von https://github.com/yavdr/yavdr…e_vdr_mount_helper.j2#L13 ff. eigentlich alles in Ruhe lassen, was nicht in einen Unterordner von /media/vdr gemountet wird.

    Ok - das ist schonmal ein Anhaltspunkt. In meiner /var/lib/vdr/bin/udiskie_vdr_mount_helper hatte der Check vor dem mount - aus welchem Grund auch immer - gefehlt Ein nochmaliges Ausführen der udiskie-Rolle mit Ansible nach dem Vorbild der xorg-Rolle hat die Datei leider nicht mit dem aktuellen Stand überschrieben - da habe ich die Änderung mal manuell eingefügt und beobachte jetzt mal, ob das schon reicht.


    Danke jedenfalls schonmal für die Hinweise...!

    Wie kann ich denn erreichen, dass nicht immer sämtliche Mounts noch einmal unter /srv/video (o.ä.) erscheinen - vor allem und insbesondere auch die über die fstab eingehängten zusätzlichen Disks...? Für während des Betriebs angesteckte USB- (!!) Datenträger finde ich die Funktion ja noch recht nützlich (wobei ich auch da gern meine Backup-Platte ausnehmen würde), aber für meine ohnehin bereits beim Start gemounteten Daten-Disks ist das eher hinderlich.


    Ich hab auch die Logik hinter dem udiskie-Mechanismus noch nicht wirklich verstanden, um darauf einwirken zu können - gebe ich zu...


    VG Hagen

    Sieht so aus, als hättest du für die Variable vdr in deiner host_vars/localhost nicht alle Inhalte übernommen - kopier die mal vollständig aus der group_vars/all und pass dann die benötigten Werte an.

    Perfekt..:! Läuft jetzt... Hatte tatsächlich nur die Zeile für den Charset_Override drin (und ich glaube sogar den Fehler vor zig Monaten schon einmal gemacht zu haben :wand). Danke für den schnellen Tip...!

    Du musst den focal-Branch nutzen (vgl. README.md im focal Branch bzw. nachträglich git checkout focal) und dann noch die Einträge für das PPA yavdr:ansible-2.8 aus /etc/apt/sources.list.d/ entfernen, weil das Install-Skript das nicht selbst gerade biegen kann.

    Aber auch damit bleibe ich hier hängen:

    Noch was vergessen...? <grübel>