Posts by HagenS

    Ist die Nutzung von json-rpc über TCP in den Einstellungen angeschaltet? https://kodi.wiki/view/JSON-RPC_API#Enabling_JSON-RPC

    Treffer - versenkt...!


    War natürlich nicht eingeschaltet - wäre ich auch nie drauf gekommen, dass da ein Zusammenhang besteht... Aber mit dem Wissen um die Hintergründe der Steuerung ist es natürlich klar :-). Jetzt reagiert Kodi brav auf den Befehl und beendet sich wie gewünscht.


    Danke (mal wieder) für den Hinweis! :thumbup:

    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
    1. Testing ... (interrupt to exit)
    2. Event: time 1613753567.635346, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7003e
    3. Event: time 1613753567.635346, type 1 (EV_KEY), code 63 (KEY_F5), value 1
    4. Event: time 1613753567.635346, -------------- SYN_REPORT ------------
    5. Event: time 1613753567.805363, type 4 (EV_MSC), code 4 (MSC_SCAN), value 7003e
    6. Event: time 1613753567.805363, type 1 (EV_KEY), code 63 (KEY_F5), value 0
    7. 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
    1. watchfor /DDCI-Err: can't write to CI adapter/
    2. exec /root/ca-reset.sh
    3. watchfor /info: Kanal nicht verfügbar/
    4. exec /root/ca-reset.sh
    5. watchfor /skipped channels/
    6. 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
    1. Oct 26 17:13:46 yavdr vdr: BOBLIGHT: boblight Thread started (pid=3517)
    2. Oct 26 17:13:46 yavdr vdr: BOBLIGHT: Connected to boblight
    3. 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]
    4. 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
    5. Oct 26 17:13:46 yavdr boblightd[710]: (CClientsHandler::Process) 127.0.0.1:44628 Connection closed
    6. 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
    1. Oct 26 17:13:46 yavdr vdr: BOBLIGHT: boblight Thread started (pid=3517)
    2. Oct 26 17:13:46 yavdr vdr: BOBLIGHT: Connected to boblight
    3. 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]
    4. 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
    5. Oct 26 17:13:46 yavdr boblightd[710]: (CClientsHandler::Process) 127.0.0.1:44628 Connection closed
    6. 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