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.
Beiträge von HagenS
-
-
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:
Code
Alles anzeigenvdr@yavdr:~$ frontend-dbus-send switchto kodi vdr@yavdr:~$ frontend-dbus-send switchto vdr vdr@yavdr:~$ systemctl --user status kodi.service ● kodi.service - Start kodi in user session Loaded: loaded (/var/lib/vdr/.config/systemd/user/kodi.service; static; vendor preset: enabled) Active: deactivating (final-sigterm) (Result: timeout) since Thu 2021-02-25 14:35:50 CET; 12s ago Process: 2242 ExecStartPre=/usr/bin/set-kodi-display (code=exited, status=0/SUCCESS) Process: 2245 ExecStart=/usr/bin/kodi (code=exited, status=143) Process: 2317 ExecStop=/bin/bash -c [ -n "$MAINPID" ] || exit 0; /usr/bin/kodi-send --action=QUIT; while ps -p $MAINPID -o comm=; do sleep .25; done (code=killed, signal=TERM) Main PID: 2245 (code=exited, status=143) CGroup: /user.slice/user-666.slice/user@666.service/kodi.service └─2250 /usr/lib/x86_64-linux-gnu/kodi/kodi.bin vdr@yavdr:~$ vdr@yavdr:~$
-
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:
CodeTesting ... (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
...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.cfgwatchfor /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:
Code: ca-reset.sh
Alles anzeigen#!/bin/bash timeout 30 sh -c 'until nc -z $0 $1; do sleep 1; done' localhost 6419 sleep 2 /usr/bin/svdrpsend HITK Menu /usr/bin/svdrpsend HITK 9 /usr/bin/svdrpsend HITK 2 /usr/bin/svdrpsend HITK 5 /usr/bin/svdrpsend HITK Green sleep 2 /usr/bin/svdrpsend HITK Menu /usr/bin/svdrpsend plug epg2vdr update /usr/bin/svdrpsend plug epg2vdr reload
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...!
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.
-
Wer das mit Ubuntu 20.04 machen will: in https://launchpad.net/~seahawk…/ubuntu/vdr-2.4.5-patches habe ich gestern Abend Pakete bauen lassen (die Pakete für autostart, pvrinput und externalplayer lasse ich gleich noch gegen den neuen VDR bauen).
Es gibt ein Probleme mit dem menuorg-Plugin - Siehe hier: yavdr experimental für Ubuntu 20.04 (yavdr ansible @ focal)
-
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:
Code
Alles anzeigenDec 15 10:42:18 yavdr vdr: [1636] no locale for language code 'ltz' Dec 15 10:42:18 yavdr vdr: [1636] no locale for language code 'mlt' Dec 15 10:42:18 yavdr vdr: [1636] no locale for language code 'por' Dec 15 10:42:18 yavdr vdr: [1636] no locale for language code 'smi' Dec 15 10:42:18 yavdr vdr: [1636] loading plugin: /usr/lib/vdr/plugins/libvdr-dbus2vdr.so.2.4.5 Dec 15 10:42:18 yavdr vdr: [1636] dbus2vdr: use shutdown-hooks in /usr/share/vdr/shutdown-hooks Dec 15 10:42:18 yavdr vdr: [1636] dbus2vdr: use shutdown-hooks-wrapper /usr/share/vdr-plugin-dbus2vdr/shutdown-wrapper Dec 15 10:42:18 yavdr vdr: [1636] loading plugin: /usr/lib/vdr/plugins/libvdr-ddci2.so.2.4.5 Dec 15 10:42:18 yavdr vdr: [1636] loading plugin: /usr/lib/vdr/plugins/libvdr-desktop.so.2.4.5 Dec 15 10:42:18 yavdr vdr: [1636] loading plugin: /usr/lib/vdr/plugins/libvdr-devstatus.so.2.4.5 Dec 15 10:42:18 yavdr vdr: [1636] loading plugin: /usr/lib/vdr/plugins/libvdr-epg2vdr.so.2.4.5 Dec 15 10:42:18 yavdr vdr: [1636] loading plugin: /usr/lib/vdr/plugins/libvdr-extrecmenung.so.2.4.5 Dec 15 10:42:18 yavdr vdr: [1636] loading plugin: /usr/lib/vdr/plugins/libvdr-markad.so.2.4.5 Dec 15 10:42:18 yavdr vdr: [1636] loading plugin: /usr/lib/vdr/plugins/libvdr-menuorg.so.2.4.5 Dec 15 10:42:18 yavdr vdr: [1636] ERROR: /usr/lib/vdr/plugins/libvdr-menuorg.so.2.4.5: undefined symbol: VDRPluginDestroyer Dec 15 10:42:18 yavdr vdr[1636]: vdr: /usr/lib/vdr/plugins/libvdr-menuorg.so.2.4.5: undefined symbol: VDRPluginDestroyer Dec 15 10:42:18 yavdr vdr: [1636] loading plugin: /usr/lib/vdr/plugins/libvdr-osd2web.so.2.4.5 Dec 15 10:42:18 yavdr vdr: [1636] loading plugin: /usr/lib/vdr/plugins/libvdr-pulsecontrol.so.2.4.5 Dec 15 10:42:18 yavdr vdr: [1636] loading plugin: /usr/lib/vdr/plugins/libvdr-scraper2vdr.so.2.4.5 Dec 15 10:42:18 yavdr vdr: [1636] loading plugin: /usr/lib/vdr/plugins/libvdr-skindesigner.so.2.4.5 Dec 15 10:42:18 yavdr epgd: MOVIEDB scraper connected Dec 15 10:42:18 yavdr vdr: [1636] loading plugin: /usr/lib/vdr/plugins/libvdr-softhddevice.so.2.4.5 Dec 15 10:42:18 yavdr vdr: [1636] loading plugin: /usr/lib/vdr/plugins/libvdr-tvguideng.so.2.4.5 Dec 15 10:42:18 yavdr vdr: [1636] loading plugin: /usr/lib/vdr/plugins/libvdr-vdrboblight.so.2.4.5 Dec 15 10:42:18 yavdr vdr: [1636] loading plugin: /usr/lib/vdr/plugins/libvdr-vnsiserver.so.2.4.5 Dec 15 10:42:18 yavdr vdr: [1636] loading plugin: /usr/lib/vdr/plugins/libvdr-weatherforecast.so.2.4.5 Dec 15 10:42:18 yavdr vdr: [1636] loading /var/lib/vdr/setup.conf Dec 15 10:42:18 yavdr kernel: [ 23.627461] vdr[1636]: segfault at 0 ip 00007fe84a87d42a sp 00007ffce02042b8 error 4 in libc-2.31.so[7fe84a73c000+178000] Dec 15 10:42:18 yavdr kernel: [ 23.627468] Code: c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 89 f1 89 f8 48 83 e1 3f 48 83 e0 3f 83 f9 30 77 4b 83 f8 30 77 46 <66> 0f 12 0f 66 0f 12 16 66 0f 16 4f 08 66 0f 16 56 08 66 0f ef c0 Dec 15 10:42:18 yavdr epgd: Scheduled next update in 10 second(s) Dec 15 10:42:18 yavdr epgd: State now 'standby'
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:
CodeOct 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:
CodeOct 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?
-
Sicher, dass die WOL-Pakete nicht von Fritzbox oder ähnlichem rausgefiltert werden?
Speziell von außen über VPN.
War es nicht so, dass WOL per Broadcast funktioniert - und Broadcast's eben nicht über ein VPN ins andere Netz gehen...?
-
Nutzt du noch bionic?
Nein. Hier läuft seit längerem Focal. Aber vielleicht hatte ich das beim Umstieg von Bionic so mit übernommen - das würde zumindest die Abweichung erklären.
-
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
-
Oder du wirfst das PPA mit ppa-purge raus, das sollte dann die Pakete automatisch gerade ziehen.
Genau so hab ich das jetzt auch gemacht - und es hat prima funktioniert.
-
https://launchpad.net/~seahawk…/ubuntu/vdr-2.4.3-patches - da ist bis auf den Commit, der die VDR-Version auf die 2.4.4 anhebt alles drin.
Das hab ich bereits eingebunden... Da in dem yavdr-PPA aber die 2.4.4 enthalten ist, nimmt er wohl die Version von dort. Muss ich jetzt mit Pinning hantieren (hatte ich bisher nicht gebraucht)...?
-
Ich musste neu installieren und hab offensichtlich ein wenig den Überblick über die relevanten Repo's verloren . Welches Repo muss ich denn aktuell einbinden, um einen aktuellen VDR inkl. Zapcockpit zu erhalten? Im yavdr-experimental-vdr ist scheinbar nur der vdr ohne Patches enthalten...
-
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 ). 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:
Code
Alles anzeigenTASK [yavdr-common : use bash instead of dash] ****************************************************************************************************************************************** skipping: [localhost] TASK [yavdr-common : create vdr group] ************************************************************************************************************************************************** fatal: [localhost]: FAILED! => {} MSG: The task includes an option with an undefined variable. The error was: 'dict object' has no attribute 'gid' The error appears to be in '/root/yavdr-ansible/roles/yavdr-common/tasks/configure_system.yml': line 29, column 3, but may be elsewhere in the file depending on the exact syntax problem. The offending line appears to be: when: default_shell.stat.lnk_source | default("") != '/usr/bin/bash' - name: create vdr group ^ here PLAY RECAP ****************************************************************************************************************************************************************************** localhost : ok=7 changed=1 unreachable=0 failed=1 skipped=3 rescued=0 ignored=0
Noch was vergessen...? <grübel>