Ich kann der gerne mal ein Video von machen, damit man das auch mal in Aktion sieht.
Leider hab ich bisher noch keine Lösung gefunden das "flackern" zu verhindern.
Ich kann der gerne mal ein Video von machen, damit man das auch mal in Aktion sieht.
Leider hab ich bisher noch keine Lösung gefunden das "flackern" zu verhindern.
Das passiert btw. bei mir auch auch mit dem klassischen VDR OSD.
Nach jeden Frontend detach/attach wird da noch irgendetwas aus dem "alten Buffer" gemalt.
Also für mich funktioniert das jetzt. Habe da noch ein bisschen weiter gebastelt und ein paar der Keys der Fenbedienung via udev umgemapped (https://yulistic.gitlab.io/201…eymapping-with-udev-hwdb/). Dazu habe ich die Datei /etc/udev/hwdb.d/90-hama-mce.hwdb angelegt:
#
# map 'O' (== 70012) to F1
# discard NUMLOCK (== 70053)
# map keypad to normal numbers
#
evdev:name:HID 05a4:9881:dmi:*:bvrF15:bd10/23/2013:*:rnB75M-D3H:*
KEYBOARD_KEY_70012=f1
KEYBOARD_KEY_70053=reserved
KEYBOARD_KEY_70059=1
KEYBOARD_KEY_7005a=2
KEYBOARD_KEY_7005b=3
KEYBOARD_KEY_7005c=4
KEYBOARD_KEY_7005d=5
KEYBOARD_KEY_7005e=6
KEYBOARD_KEY_7005f=7
KEYBOARD_KEY_70060=8
KEYBOARD_KEY_70061=9
KEYBOARD_KEY_70062=0
#
# remap of system control keys
# SLEEP -> POWER2
#
evdev:name:HID 05a4:9881 System Control:dmi:*:bvrF15:bd10/23/2013:*rnB75M-D3H:*
KEYBOARD_KEY_10082=power2
Display More
Dadurch kann man auch einige Einträge unter /etc/eventlircd/hama-mce.evmap weglassen. Da geht bestimmt auch noch mehr, aber für meine Zwecke DOSBox, ZSNES (higan ist leider irgendwie defekt), Firefox für Streaming Dienste klappt das perfekt.
Habe hier noch die Scripte angehängt mit denen ich den Wechsel zu einer Applikation bzw. wie beim alten yaVDR 0.6 einfach nur eine Applikation parallel zum VDR starte (ich nutze gern dvbcut oder handbrake während der VDR läuft).
Im Archiv sind:
Dabei ist vdr-app ein Bash-Script mit folgenden Modi (sorry, mit Python werde ich nicht warm):
Beispiel Aufruf:
vdr-app switch dosbox -conf .config/game.conf
Ah fast vergessen, damit das journal nicht ständig mit Meldungen darüber dass der eventlircd gestorben ist und er jetzt alle drei Sekunden versuchen wird sich wieder zu verbinden zugespammt wird empfiehlt es sich das Log Level des VDRs runterzudrehen (siehe RE: [gelöst] [yavdr-ansible] vdr log deaktivieren)
Damit das funktioniert müssen die Änderungen aus Punkt 1. und 4. von RE: [yavdr-ansible] Fernbedienung in Anwendungen nutzen (Firefox, Higan etc. pp.) übernommen werden.
Vielleicht hilft es ja jemandem. Ich bin auf jeden Fall mit der Funktionalität zufrieden.
Also, nachdem ich endlich verstanden habe was sich konkret zwischen yaVDR 0.6 und 0.7 (ansible) geändert habe, habe ich es nun auch hinbekommen das System so umzubauen dass es das tut was ich eigentlich will. In der 0.6er Installation wurde beim Applikationswechseln der eventlircd ausgeschaltet. Das ist auch notwendig, da sonst - wie oben beschrieben - der vdr bei dem Tastendruck auf der Fernbedienung meint er müsste das Frontend wieder attachen. Das will ich aber nicht, ich will ja die Keycodes die die Ferbedienung abfackelt direkt abgreifen.
Daher habe ich folgendes geändert:
1. Dem vdr user die Rechte gegeben den eventlircd Dienst zu starten und zu stoppen via /etc/sudoers.d/yavdr-eventlircd
vdr ALL=(ALL) NOPASSWD: /bin/systemctl start eventlircd.service
vdr ALL=(ALL) NOPASSWD: /bin/systemctl stop eventlircd.service
2. Ein Shellscript vdr-switch-app nach /usr/bin gepackt:
#!/usr/bin/bash
#
# missing task
#
if [ -z "$1" ] ; then
svdrpsend MESG "No application given to start. Exiting..." > /dev/null
exit 1
fi
#
# grab application
#
APP=$1
shift
#
# start application
#
if [ "$APP" == "--start" ] ; then
command $@
exit $?
fi
#
# check if application exists (if not search it)
#
if [ ! -e "$APP" ] ; then
WHICH_APP=$(which $APP)
if [ $? != 0 ] ; then
svdrpsend MESG "Cannot find $APP. Exiting..." > /dev/null
exit 1
fi
APP=$WHICH_APP
fi
#
# trigger application switch
#
APP=$(echo "$APP $@")
systemctl --user --no-block start $(systemd-escape --template vdr-switch-app@.service -- "$APP")
exit 0
Display More
3. Den vdr user-lokalen Dienst vdr-switch-app@.service in /home/vdr/.config/system/user/ hinzugefügt:
[Unit]
Description=Helper to switch from VDR to application
[Service]
ExecStartPre=-/usr/bin/frontend-dbus-send stop
ExecStartPre=/usr/bin/systemctl --user stop irexec.service
ExecStartPre=-/usr/bin/sudo /usr/bin/systemctl stop eventlircd.service
ExecStart=%h/usr/bin/vdr-switch-app --start %I
ExecStartPost=-sudo /usr/bin/systemctl start eventlircd.service
ExecStartPost=/usr/bin/systemctl --user stop irexec.service
ExecStartPost=-/usr/bin/frontend-dbus-send start
Type=oneshot
Display More
4. Die xorg-ignore-eventlircd.conf löschen damit die Key-Events der Fernbedienung auch bei X Applikationen ankommt.
Dann kann ich nun im menuorg.xml hinschreiben:
und meine Fernbedienung funktioniert dann im Netflix Firefox Profil so wie früher. Die Hama schickt ja (für mich) "sinnige" Kommandos.
Kann sein dass ich noch die Fehlerbehandlung überarbeiten muss. Habe noch nicht konkret getestet was im Fehlerfall passiert.
Was meint ihr? Overkill? Quatsch? Geht das doch irgendwie besser mit frontend-dbus-send?
Ah, verdammt - wer lesen kann ist klar im Vorteil. Ich hab das einfach wunderbar überlesen.
Vielen Dank, jetzt klappt das so wie erwartet.
Ahoi,
ich würde gerne das Logging des VDRs ein wenig reduzieren, da ja doch eine Menge Nachrichten im journalctl auflaufen.
Der Aufruf vdr --help verrät es ja schon wie man das Log Level einstellen kann:
-l LEVEL, --log=LEVEL set log level (default: 3)
0 = no logging, 1 = errors only,
2 = errors and info, 3 = errors, info and debug
if logging should be done to LOG_LOCALn instead of
LOG_USER, add '.n' to LEVEL, as in 3.7 (n=0..7)
Aber wenn ich in /lib/systemd/system/vdr.service ExecStart ändere zu ExecStart=/usr/bin/vdr -l 0 und den Dienst neu starte, so steht im journalctl:
Jan 07 09:23:26 satis systemd[1]: Starting Video Disk Recorder...
Jan 07 09:23:26 satis vdr[2990]: vdr: no primary device found - using first device!
Jan 07 09:23:26 satis systemd[1]: Started Video Disk Recorder.
Wenn ich den Parameter wieder lösche klappt das einwandfrei.
Woran kann das liegen?
Ich bastel da jetzt gerade an einer Lösung die mittels eines user-lokalen systemd Dienstes den Applikationsswitch vornimmt und dann irxevent vor dem Applikationsstart startet. Dazu habe ich folgenden Dienst irxevent.service:
[Unit]
Description=LIRC X event command handler
Conflicts=irexec.service
[Service]
Type=simple
ExecStart=/usr/bin/irxevent %h/.xlircrc
Der Dienst vdr-switch-app.service um den Wechsel in die Applikation zu triggern um das Frontend zu deaktivieren hat folgenden Code:
[Unit]
Description=Helper to switch from VDR to application
Requires=irxevent.service
[Service]
Type=oneshot
ExecStartPre=-frontend-dbus-send stop
ExecStart=vdr-switch-app
ExecStartPost=-frontend-dbus-send start
Dabei ist vdr-switch-app ein Script das zwei Modi hat:
Was jetzt noch fehlt ist irexec.service nach Beenden des Dienstes wieder zu starten.
Das ist jedoch nicht mein Hauptproblem.
Womit ich jetzt noch kämpfe ist, dass das frontend ja eigentlich nur detached ist.
D.h. jeder Event auf der Fernbedienung führt zu:
Im Prinzip will ich hier ja dasselbe was frontend-dbus-send switchto macht, nur dass ich eben eine beliebige Kommandozeile übergeben will ohne dass ich da jetzt noch .desktop Dateien irgendwo hinkippen muss.
Wie kann ich hier verhindern dass die Fernbedienung das re-attachen des Frontends auslöst?
Ich habe jetzt mal ein wenig herum experimentiert.
Händisch mache ich folgendes nach frontend-dbus-send switch-to xterm:
In der .xlircrc steht folgendes drin:
begin
prog = irxevent
button = KEY_1
config = Key 1 CurrentWindow
end
begin
prog = irxevent
button = KEY_2
config = Key 2 CurrentWindow
end
...
begin
prog = irxevent
button = KEY_CLOSE
config = Key CTRL-Q CurrentWindow
end
Display More
Und tatsächlich kommen diese Events dann auch an (z.B. in xev).
Jetzt würde ich das nur gerne noch automatisieren, d.h. sobald der Wechsel in eine Applikation geschafft wurde, irexec killen und irxevent starten und sobald diese beendet wurde wieder irexec starten und irxevent killen.
Wie kann ich das am Besten realisieren?
Edit: Ich vermute mal das müsste ich irgendwie in /usr/lib/pyhton3/dist-packages/yavdr-frontend/yavdrfrontend.py einbauen, oder? Ich verstehe einfach nicht was genau irexec /home/vdr/.lircrc aufruft...
Mh, ich hab nochmal geschaut wie das bei dem yaVDR 0.6 gelöst war.
Dort habe ich für den Higan (Emulator) das über folgendes init script gelöst das von dem menuorg-appswitcher aufgerufen wurde:
description "Higan Daemon"
script
export PATH=/usr/local/bin:/usr/bin:/bin
export HOME=/home/tv
exec su -c "/usr/bin/higan" tv
end script
pre-start script
if [ ! -z $STANDALONE ] ; then
vdr-dbus-send /Remote remote.Disable ||:
stop eventlircd
touch /tmp/.standalone || /bin/true
fi
end script
post-stop script
/bin/rm -f /tmp/.standalone
if [ ! -z $STANDALONE ] ; then
start eventlircd
vdr-dbus-send /Remote remote.Enable ||:
/sbin/initctl emit --no-wait vdr-frontend-restart
fi
end script
Display More
Dadurch war die Fernbedienung exklusiv für den aufgerufenen Prozess und hat nicht noch Befehle im Hintergrund an den VDR geschickt.
Hier würde ich gerne über das frontend-dbus-send switch-to das so ähnlich realisieren. Kann ich da denn den irexec stoppen und den irxexec starten und umgekehrt?
Ahoi,
ich habe vor kurzem meinen acht Jahre alten yaVDR von 0.6 auf 0.7 (ansible, focal) geupgraded und bin dank eurer Hilfe auch eigentlich schon relativ weit gekommen.
Es gibt nur eine Sache die ich nicht verstehen will, da stehe ich echt auf dem Schlauch.
Wie in dem "alten" yaVDR würde ich z.B. gerne KEY_CLOSE auf meiner hama Fernbedienung (00052451, siehe Anhang) nutzen um Anwendungen wie z.B. Firefox zu schließen.
Das klappt irgendwie (noch) nicht...
Mit irw sehe ich zumindest mal das was ankommt:
Bei xev scheint jedoch nichts anzukommen außer die Maus-Emulation und die linke Maustaste auf der Fernbedienung.
ButtonPress event, serial 44, synthetic NO, window 0x800001,
root 0x250, subw 0x0, time 647576, (151,53), root:(420,157),
state 0x0, button 1, same_screen YES
ButtonRelease event, serial 44, synthetic NO, window 0x800001,
root 0x250, subw 0x0, time 647712, (151,53), root:(420,157),
state 0x100, button 1, same_screen YES
MotionNotify event, serial 44, synthetic NO, window 0x800001,
root 0x250, subw 0x0, time 683208, (151,55), root:(420,159),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 44, synthetic NO, window 0x800001,
root 0x250, subw 0x0, time 683240, (151,56), root:(420,160),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 44, synthetic NO, window 0x800001,
root 0x250, subw 0x0, time 683272, (151,58), root:(420,162),
state 0x0, is_hint 0, same_screen YES
MotionNotify event, serial 44, synthetic NO, window 0x800001,
root 0x250, subw 0x0, time 683336, (151,60), root:(420,164),
state 0x0, is_hint 0, same_screen YES
Display More
Wie schaffe ich es dass die Knöpfe bei xev (und somit bei anderen Anwendungen) ankommen.
Ich weiß einfach nicht mehr wie ich da "echte" Keyboard Events genieren kann...
Was übersehe ich hier?
Hier noch ein kleiner Nachtrag:
Es ist eventuell besser man überscheibt die systemd config via systemctl edit wait-for-dvb@0.service und fügt hier ein:
[Service]
ExecStartPre=/usr/bin/logger -t wait-for-dvb got device %i
ExecStart=-/usr/bin/szap -x -n 002 -c /etc/vdr/channels.conf
Dadurch verhindert man dass bei einem Update die Änderungen überbügelt werden.
Vielen lieben Dank für die verdammt schnelle Hilfe nochmal! Werde ich dann morgen in Ruhe ausprobieren.
In yavdr-ansible mit WinTV-NOVA -HD-S2 gab es da mal einen Ansatz. Leider hat der TE die funktionierende Lösung nicht zusammengefasst..
Klasse, das funktioniert! Vielen lieben Dank!
Die Lösung hierzu ist /etc/systemd/system/multi-user.target.wants/wait-for-dvb@0.service ändern zu:
[Service]
Type=oneshot
ExecStartPre=/usr/bin/logger -t wait-for-dvb got device %i
ExecStart=-/usr/bin/szap -x -n 002 -c /etc/vdr/channels.conf
Danke nochmal!
Jetzt muss ich nur noch lernen wie ich in dem neuen VDR eigene Menu-Einträge erstelle und in andere Applikationen switchen kann (DosBox, Firefox) und alles ist neu und hat die alten Features :).
Das ist jetzt außerhalb dieses Threads: Gibts da Anleitungen dazu? Kann man sich das von dem "Kodi Switcher" abgucken?
Hier das Syslog ab dem Booten (log.reboot.txt) und zusätzlich noch nach Restart des VDR Dienstes (log.restart.txt).
Hier scheint die Firmware während des Starts des VDR Dienstes geladen zu werden:
Dez 29 17:03:03 satis systemd[1]: Starting Video Disk Recorder...
Dez 29 17:03:03 satis systemd[1449]: pam_unix(login:session): session opened for user vdr by (uid=0)
Dez 29 17:03:03 satis systemd[1]: Created slice User Slice of UID 666.
Dez 29 17:03:03 satis systemd[1]: Starting User Runtime Directory /run/user/666...
Dez 29 17:03:03 satis systemd-logind[1009]: New session 1 of user vdr.
Dez 29 17:03:03 satis systemd[1]: Finished User Runtime Directory /run/user/666.
Dez 29 17:03:03 satis systemd[1]: Starting User Manager for UID 666...
Dez 29 17:03:03 satis systemd[1473]: pam_unix(systemd-user:session): session opened for user vdr by (uid=0)
Dez 29 17:03:03 satis vdr[1472]: [1472] VDR version 2.4.8 started
...
Dez 29 17:03:04 satis kernel: cx24116_firmware_ondemand: Waiting for firmware upload (dvb-fe-cx24116.fw)...
Dez 29 17:03:04 satis kernel: cx24116_firmware_ondemand: Waiting for firmware upload(2)...
...
Dez 29 17:03:09 satis kernel: cx24116_load_firmware: FW version 1.23.86.1
Dez 29 17:03:09 satis kernel: cx24116_firmware_ondemand: Firmware upload complete
Dez 29 17:03:09 satis vdr[1472]: [1472] DVB API version is 0x050B (VDR was built with 0x050B)
Dez 29 17:03:09 satis vdr[1472]: [1472] frontend 0/0 provides DVB-S,DVB-S2 with QPSK ("Conexant CX24116/CX24118")
...
Dez 29 17:03:12 satis vdr[1472]: [1472] switching to channel 1 S19.2E-1-1019-10301 (Das Erste HD (S19.2E))
Dez 29 17:03:12 satis vdr[1472]: [1772] device 1 receiver thread started (pid=1472, tid=1772, prio=high)
Dez 29 17:03:12 satis vdr[1472]: [1472] [softhddev]SetVolumeDevice: 35
Dez 29 17:03:12 satis systemd[1]: Started Video Disk Recorder.
Display More
Das sieht mir auf den ersten Blick nicht so ganz schlecht aus... Mh.
Hallo Leute,
ich nutze yaVDR schon ganz lange und habe seit über 8 Jahren ein yaVDR 0.6er System am Laufen. Aber leider leider wird es langsam Zeit mal upzugraden weil DRM + firefox + Streaming Dienste nicht mehr auf dem "alten" yaVDR miteinander harmonieren wollen.
Daher habe ich nun auf einer neuen SSD das yaVDR ansible nach https://www.yavdr.org/document…aVDR07_documentation.html aufgesetzt. Das klappte auch alles soweit ganz gut (auch wenn ich mit dem ansible Zeugs noch nicht so recht durchsteigen will *g*) nur passiert hier eine Besonderheit. Nachdem ich die channels.conf vom alten yaVDR übetragen habe zeigt das System nach dem Reboot nur einen schwarzen Bildschirm (das Thema gab es hier ja schon öfters). Das OSD funktioniert aber und ich kann zwischen den Kanälen "umschalten" - es wird nur eben kein Bild gezeigt.
Wenn ich den VDR über das OSD Menu (System -> Befehle -> VDR neu starten) manuell neu starte klappt das auf einmal mit dem Fernsehbild. Ich verstehe absolut nicht warum und werde aus den journal log des VDR users nicht schlau.
Angehängt die Ausgaben von sudo journalctl -u vdr nach dem Reboot des Systems (vdr.log.reboot.txt) und nach dem manuellen Restart des vdr Dienstes (vdr.log.restart.txt).
Ich habe auch wie in https://www.yavdr.org/document….html#vdr-common-problems beschrieben den vdr Dienst auf die DVB S2 Karten via sudo systemctl enable wait-for-dvb@0.service warten lassen, das führte aber leider nicht zum Erfolg.
Was übersehe ich hier?
Das Ausgabeplugin habe ich temporär auf vdr-plugin-softhddevice-openglosd-ffmpeg-2.8 umgestellt um dem yaVDR 0.6er System "näher zu kommen". Das scheint auch nix damit zu tun zu haben (daher auch die ERROR: unknown config parameter Meldungen in den Logs).
Bin da jetzt echt ratlos.
Vielen Dank im Voraus für eure Hilfe!