Beiträge von sboldt

Zitat von louis

Jo das ist ein Bug im softhddevice-openglosd. Da das ganze aber für mich keine Prio hat, hatte ich bisher weder Zeit noch Lust, das zu fixen

Ciao Louis

Hi Louis,

hattest Du dafür doch irgendwann einen Patch geschrieben? Aus yaVDR 0.6 ist der Bug nämlich mit irgendeinem Update vor ich glaube ca. 1 Jahr verschwunden. Nun habe ich den VDR mit Ubuntu 18.04 neu aufgesetzt und stoße wieder auf den gleichen Fehler. Fehlt da evtl ein Fix im entsprechenden Paket? Könntest Du das evtl. mal prüfen? Ich denke Du bist da vermutlich der fitteste Wenn Du keine Zeit oder keine Lust hast sag bitte einfach kurz Bescheid, dann muss ich anderweitig mal danach suchen.

Danke schon mal im Voraus!

Viele Grüße,

Stephan

Zitat von davie2000

Weiß nicht mehr, ob ich dafür was "Verbogen" habe; kann aber bei Bedarf nachschauen.

Das wäre natürlich super! Wobei ich zumindest mit dem aktuellen Seiten-Überlagerungs-Bug das gar nicht schlecht finde eine Taste zum "nur-aktivieren" zu haben. Diese startet nämlich das Plugin bei jedem Knopfdruck neu und zeigt die zuletzt aufgerufene Seite dann korrekt an. Raus kommt man auch sehr leicht mittels Menü- oder Exit-Taste.

Was mich wundert ist, dass ich das gleiche Problem lange auf meinem alten yaVDR hatte (Ubuntu 14.04) und irgendwann vor ich glaube ca. 1 Jahr nach einem Update das Problem weg war! Daher ging ich davon aus, dass es da auf für die 18.04 yaVDR Pakete einen Patch geben müsste...

Könnt ihr eine zur openglosd alternative Version vom Softhddevice empfehlen, die evtl. das Problem nicht hat? Ich blicke bei den verschiedenen Softhddevice Versionen irgendwie eh nicht durch welche man wofür am besten nehmen sollte. Gibt's da evtl. irgendwo eine Übersicht? Im Wiki wurde ich nicht so richtig fündig. In meinem Fall geht es konkret um die Darstellung auf einer Nvidia Grafikkarte, die natürlich möglichst viel in der GPU berechnen sollte.

Viele Grüße,

Stephan

Hallo zusammen,

ich habe einen VDR 2.4.0 mit osdteletext Plugin in Version 0.9.7. Meine Fernbedienung hat eine separate Videotext Taste, die lt. irw auch als KEY_TEXT erkannt wird. Allerdings weiß ich nun nicht wie ich das osdteletext Plugin durch den entsprechenden Tastendruck aktivieren kann. "svdrpsend help" zeigt keine Befehlte für das Plugin an. Gibt es einen andern Weg das osdteletext plugin ein- und bei erneutem Tastendruck wieder auszublenden?

Danke im Voraus für jeden Tip!

Viele Grüße,

Stephan

Hallo zusammen,

ich habe einen VDR 2.4.0 mit osdteletext Plugin in Version 0.9.7, sowie vdr-plugin-softhddevice-openglosd 0.6.1rc1 installiert. Wenn ich das osdteletext Plugin aufrufe wird die erste Seite problemlos dargestellt. Wechesele ich jedoch die Seite scheinen die hellen Bereiche der alten Seite noch durch die dunklen Bereiche der neuen Seite durch. Dadurch ist der Text der neuen Seite teilweise kaum lesbar. Hat jemand eine Idee woran das liegen könnte und wie man das abstellen kann?

Danke im Voraus für jeden Tip!

Viele Grüße,

Stephan

Meine Vermutung war korrekt, dass da was nicht mit den udev-Rules stimmte. Die Datei /lib/udev/rules.d/98-eventlircd.rules war disabled (hieß also nun /lib/udev/rules.d/98-eventlircd.rules.disabled ). Durch Entfernen des ".disabled" + Reboot stimmte nun auch der udevadm info Output und die zuvor nicht funkionierenden Tasten wurden nun auch vom VDR verarbeitet.

[...]
E: XKBVARIANT=nodeadkeys
E: eventlircd_enable=true
E: eventlircd_evmap=ircore.evmap

Nun scheint tatsächlich alles zu funktionieren. 1000 Dank an seahawk1986 !! Deine Hilfe war echt der Hammer! Respekt vor Deinem Tiefgreifenden Wissen um die Zusammenhänge, Abhängigkeiten und benötigten Einstellungen. Ganz großes Tennis!

Puh....das ist schon ne Weile her... Also spontan würde ich sagen: unmasken, lircd.conf, hardware.conf vom alten VDR kopiert, lirc_ir.conf angepasst und nicht viel mehr.

Der fehlende Eintrag müsste doch aus einer udev-rule kommen, oder?

Es steht zumindest nicht explizit dort:

root@vdr:~# udevadm info --query=all  --name=/dev/input/event2
P: /devices/platform/serial_ir.0/rc/rc0/input2/event2
N: input/event2
S: input/by-path/platform-serial_ir.0-event-ir
E: BACKSPACE=guess
E: DEVLINKS=/dev/input/by-path/platform-serial_ir.0-event-ir
E: DEVNAME=/dev/input/event2
E: DEVPATH=/devices/platform/serial_ir.0/rc/rc0/input2/event2
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=platform-serial_ir.0
E: ID_PATH_TAG=platform-serial_ir_0
E: ID_SERIAL=noserial
E: LIBINPUT_DEVICE_GROUP=19/1/1:serial_ir
E: MAJOR=13
E: MINOR=66
E: SUBSYSTEM=input
E: TAGS=:power-switch:
E: USEC_INITIALIZED=22077330
E: XKBLAYOUT=de
E: XKBMODEL=pc105
E: XKBVARIANT=nodeadkeys

root@vdr:~#

Ja, gibt es:

root@vdr:~# cat  /etc/X11/xorg.conf.d/40-ignore-eventlircd.conf
#
# *** ANSIBLE MANAGED FILE ***
# template: /tmp/yavdr-ansible/roles/yavdr-xorg/templates/xorg-ignore-eventlircd.conf.j2
#

Section "InputClass"
    Identifier "exclude eventlircd devices"
    MatchTag   "eventlircd"
    Option     "Ignore"    "True"
EndSection

Nach reboot ist eventlirc wieder da, klappt aber trotzdem nicht. Bzgl. der Menü-Taste habe ich nun gesehen, dass beim Drücken folgender EIntrag im Log erscheint:

[softhddev]FeedKeyPress: remote 'XKeySym' not found

Hier meine remote.conf:

LIRC.Up KEY_UP
LIRC.Down KEY_DOWN
LIRC.Menu KEY_MENU
LIRC.Ok KEY_OK
LIRC.Back KEY_BACK
LIRC.Left KEY_LEFT
LIRC.Right KEY_RIGHT
LIRC.Red KEY_RED
LIRC.Green KEY_GREEN
LIRC.Yellow KEY_YELLOW
LIRC.Blue KEY_BLUE
LIRC.0 KEY_0
LIRC.1 KEY_1
LIRC.2 KEY_2
LIRC.3 KEY_3
LIRC.4 KEY_4
LIRC.5 KEY_5
LIRC.6 KEY_6
LIRC.7 KEY_7
LIRC.8 KEY_8
LIRC.9 KEY_9
LIRC.Info KEY_INFO
LIRC.Play KEY_PLAY
LIRC.Pause KEY_PAUSE
LIRC.Play/Pause KEY_PLAYPAUSE
LIRC.Stop KEY_STOP
LIRC.Record KEY_RECORD
LIRC.FastFwd KEY_FASTFORWARD
LIRC.FastRew KEY_REWIND
LIRC.Next KEY_NEXT
LIRC.Prev KEY_BACK
LIRC.Power KEY_POWER2
LIRC.Channel+ KEY_CHANNELUP
LIRC.Channel- KEY_CHANNELDOWN
LIRC.PrevChannel KEY_PREVIOUS
LIRC.Volume+ KEY_VOLUMEUP
LIRC.Volume- KEY_VOLUMEDOWN
LIRC.Mute KEY_MUTE
LIRC.Subtitles KEY_SUBTITLE
LIRC.Schedule KEY_EPG
LIRC.Channels KEY_CHANNEL
LIRC.Commands KEY_FAVORITES
LIRC.Audio KEY_MODE
LIRC.Timers KEY_TIME
LIRC.Recordings KEY_PVR
LIRC.Setup KEY_SETUP
LIRC.User0 KEY_TEXT
LIRC.User1 KEY_PROG1
LIRC.User2 KEY_PROG2
LIRC.User3 KEY_PROG3
LIRC.User4 KEY_PROG4
LIRC.User5 KEY_AUDIO
LIRC.User6 KEY_VIDEO
LIRC.User7 KEY_IMAGES
LIRC.User8 KEY_FN
LIRC.User9 KEY_SCREEN

Jemand ne Idee warum manche Tasten im VDR nicht funktionieren, andere aber schon? Das die Menü-Taste nicht funktioniert ist schon ziemlich nervig.

root@vdr:~# ir-keytable  -t
Testing events. Please, press CTRL-C to abort.
109.130624: lirc protocol(nec): scancode = 0x3d
109.130634: event type EV_MSC(0x04): scancode = 0x3d
109.130634: event type EV_KEY(0x01) key_down: KEY_MENU(0x008b)
109.130634: event type EV_SYN(0x00).
109.182623: lirc protocol(nec): scancode = 0x3d repeat
109.182630: event type EV_MSC(0x04): scancode = 0x3d
109.182630: event type EV_SYN(0x00).
109.310624: event type EV_KEY(0x01) key_up: KEY_MENU(0x008b)
109.310624: event type EV_SYN(0x00)

Wie zu sehen ist wird KEY_MENU von ir-keytable erkannt, aber der VDR reagiert nicht darauf

Komisch, zusammen mit lirc hat es funktioniert wenn ich als Protokoll RC5 angegeben habe. In der Tat werden nun mit eingestelltem NEC Protokoll (auch bei laufendem eventlircd) Tastendrücke erkannt. Ich habe die Keymap allerdings anpassen müssen, da die zuvor in der lircd.conf gespeicherten Codes anders waren. Nun ist es jedoch so, dass MANCHE Tasten am VDR ankommen (z.B. 0-9, Pfeiltasten, Volume +-) , andere aber nicht, obwohl sie mit ir-keytable -t entsprechend erkannt werden (z.B. KEY_MENU, KEY_OK, Farbtasten, etc.). Hast Du noch eine Idee woran das liegen könnte?

1000 Danke übrigens für Deine tolle Hilfe!

Viele Grüße,

Stephan

Hier die lircd.conf meiner OneForAll:

begin remote

  name  OneForAll_Sat
  bits           16
  flags SPACE_ENC|CONST_LENGTH
  eps            30
  aeps          250

  header       8980  4399
  one           629  1599
  zero          629   483
  ptrail        630
  repeat       8979  2189
  pre_data_bits   16
  pre_data       0xFF
  gap          107040
  repeat_bit    10

  toggle_bit_mask 0x0

      begin codes
          KEY_OK                   0x1CE3
          KEY_UP                   0xFC03
          KEY_EPG                  0x9C63
          KEY_MENU                 0xBC43
          KEY_INFO                 0x9D62
          KEY_UP                   0xFC03
          KEY_DOWN                 0xDC23
          KEY_LEFT                 0x3DC2
          KEY_RIGHT                0x1DE2
          KEY_EXIT                 0xF20D
          KEY_1                    0x7E81
          KEY_2                    0x5EA1
          KEY_3                    0x9E61
          KEY_4                    0xBE41
          KEY_5                    0xFE01
          KEY_6                    0xDE21
          KEY_7                    0x1FE0
          KEY_8                    0x3FC0
          KEY_9                    0x7F80
          KEY_0                    0x1EE1
          KEY_TEXT                 0x916E
          KEY_SETUP                0xF10E
          KEY_RED                  0x31CE
          KEY_GREEN                0x11EE
          KEY_YELLOW               0x718E
          KEY_BLUE                 0x51AE
          KEY_PLAY                 0x32CD
          KEY_PAUSE                0x12ED
          KEY_STOP                 0xB24D
          KEY_RECORD               0x926D
          KEY_BACK                 0x5CA3
          KEY_VOLUMEUP             0xBF40
          KEY_VOLUMEDOWN           0x5FA0
          KEY_CHANNELUP            0xDF20
          KEY_CHANNELDOWN          0xFF00
      KEY_MUTE                 0x00FF9F60
      end codes

end remote

root@vdr:~# ps -ef | grep eventlir
root      1128     1  0 15:14 ?        00:00:00 /usr/sbin/eventlircd -f --socket=/var/run/lirc/lircd
root      3854  3773  0 15:16 pts/1    00:00:00 grep --color=auto eventlir
root@vdr:~# systemctl mask --now --runtime eventlircd.{socket,service}
Created symlink /run/systemd/system/eventlircd.socket → /dev/null.
Created symlink /run/systemd/system/eventlircd.service → /dev/null.
root@vdr:~# ps -ef | grep eventlir
root      3948  3773  0 15:16 pts/1    00:00:00 grep --color=auto eventlir
root@vdr:~# ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event2) with:
    Name: Serial IR type home-brew
    Driver: serial_ir, table: rc-rc6-mce
    lirc device: /dev/lirc0
    Supported protocols: other lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp
    Enabled protocols: lirc rc-5
    bus: 25, vendor/product: 0001:0001, version: 0x0100
    Repeat delay = 500 ms, repeat period = 125 ms
root@vdr:~# ir-keytable  -t
Testing events. Please, press CTRL-C to abort.
165.202340: lirc protocol(rc5): scancode = 0x1e07
165.202357: event type EV_MSC(0x04): scancode = 0x1e07
165.202357: event type EV_SYN(0x00).
165.310322: lirc protocol(rc5): scancode = 0x1e07
165.310353: event type EV_MSC(0x04): scancode = 0x1e07
165.310353: event type EV_SYN(0x00).
165.422339: lirc protocol(rc5): scancode = 0x1e07
165.422352: event type EV_MSC(0x04): scancode = 0x1e07
165.422352: event type EV_SYN(0x00).

Die angezeigten events sins wie gesagt alle von der Hauppauge Remote, keiner von der OneForAll, die meine eigentlich Remote ist

Auch mit maskiertem eventllircd werden nur Tastendrücke der Hauppauge Remote angezeigt, nicht aber die meiner VDR Remote (OneForAll).

Hab nun das ansible skript wie angegeben aufgerufen (mit lirc masked). Nach reinem Reboot ist serial_ir geladen und der Adapter wird bei ir-keytable angezeigt.

root@vdr:~# dmesg | grep serial
[    9.555515] serial_ir serial_ir.0: auto-detected active low receiver
[    9.739556] rc rc0: Serial IR type home-brew as /devices/platform/serial_ir.0/rc/rc0
[    9.739592] input: Serial IR type home-brew as /devices/platform/serial_ir.0/rc/rc0/input2
[    9.739810] rc rc0: lirc_dev: driver serial_ir registered at minor = 0, raw IR receiver, raw IR transmitter

root@vdr:~# ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event2) with:
    Name: Serial IR type home-brew
    Driver: serial_ir, table: rc-rc6-mce
    lirc device: /dev/lirc0
    Supported protocols: other lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp
    Enabled protocols: lirc rc-5
    bus: 25, vendor/product: 0001:0001, version: 0x0100
    Repeat delay = 500 ms, repeat period = 125 ms

Mit mode2 werden auch Tastendrücke meiner VDR remote erkannt. ir-keytable -t zeigt jedoch mit der gleichen Fernbedienung nichts an Hab verschiedene Protokolel (RC5,RC6,NEC) ausprobiert aber nichts klappte. Was mich wundert: Als enabled protocol wird immer zusätzlich zum händisch gewählten Protokoll auch "lirc" angegeben. Ist das korrekt so?

Was mir zufällig auffiel: Wenn ich statt auf meiner normalen VDR FB auf einer alten Hauppauge WinTV Remote Tasten drücke, so werden bei laufendem "ir-keytable -t" die entsprechenden Scancodes erkannt und ausgegeben! Und das selbst wenn ich vorher mit ir-keytable -c die tables cleare. Aus irgendeinem Grunde scheint der meine Remote nicht zu mögen, obwohl sie mit lirc problemlos funktioniert hat.

Hallo Skyhawk,

ich habe dein Kommando abgesetzt, aber es änderte sich dadurch gar nichts. Dann fiel mir auf, dass der service - zumindest bei mir - lirc (ohne "d") heißt. Hab dann Dein Kommando nochmal abgesetzt mit lirc statt lircd. Nach einem Reboot listete ir-keytable dann jedoch meinen homebrew receiver (Atric IR-Einschalter V5) gar nicht mehr auf. Zudem fiel mir auf, dass das serial_ir Modul gar nicht geladen war. Ein "modprobe serial_ir" sorgte dann dafür das das Modul geladen wurde, aber auch danach wurden keine Tastendrücke von irw oder dem VDR erkannt...

Viele Grüße,

Stephan

Hallo zusammen,

ich habe neulich meinen VDR mit Ubuntu 18.04 und dem Ansible Skript neu aufgesetzt. Das hat auch ziemlich gut geklappt. Allerdings wird der zweite Tuner meiner Hauppauge WinTV-dualHD erst ab Kernel 4.18 sauber unterstützt. Daher habe ich mittels ukuu verschiedene Kernelversionen installiert und getestet. Leider funktioniert (der mit Ubuntu 18.04 mitgelieferte) LIRC ab 4.16 nicht mehr auf dem "klassischen Wege", da sich wohl irgendwelche Schnittstellen geändert haben. Jedenfalls musste ich auf den neuen Weg mit ir-keytable und dem Kernel eigenen IR Support umstellen. Auch das hat nach einiger Fummelei geklappt. Die Kommandos der Fernbedienung werden sogar weniger hakelig verarbeitet als zuvor, alles läuft sehr, sehr "smooth".

Nun musste ich meinen VDR rebooten und siehe da, der VDR reagierte nicht mehr auf die Fernbedienung. Auch mit "irw" wurden keine Tastendrücke erkannt - was vor dem Reboot klappte. "ir-keytable" zeigte den IR-Receiver (Serial IR type home-brew) jedoch so an wie auch vor dem Reboot. Nach einem "systemctl restart lirc" klappte es mit "irw" wieder sauber, mit dem VDR jedoch erst nachdem ich diesen ebenfalls restartet hatte.

Daraus ergeben sich für mich zwei Fragen:

1. Warum funktionierte der grundsätzliche Empfang der IR-Kommandos mit irw nach einem Neustart des Dienstes - ohne Änderung der Konfig

2. Warum brauchte der VDR ebenfalls einen restart? Wenn alles einmal funktioniert kann ich den lirc beliebig oft Neustarten - wenn er wieder läuft klappt's direkt auch wieder mit dem VDR.

Hat jemand eine Idee für dieses verhalten? Welche logs oder konfig-dateien soll ich für die Analyse bereitstellen?

Danke schon vorab für jeden Tip!

Viele Grüße,

Stephan

Zitat von seahawk1986

Ja, insbesondere in Verbindung mit softhddevice wird das schwierig, weil dann mindestens drei Löcher in den Container gebohrt werden müssen:

• Zugriff auf die Soundkarte (mit alsa) bzw. pulseaudio

Also mit Softhddevice / VDPAU brauche ich ja keinen Zugriff auf die Soundkarte, der Ton geht ja per HDMI mit über die Grafikkarte. Oder übersehe ich da etwas?

Zitat von seahawk1986

Zugriff auf den DBus SystemBus

Was muss ich dafür tun? Welcher Port muss dafür durchgereicht werden?

Zitat von seahawk1986

Zugriff auf den X-Server

Auch hier würde mich interessieren welcher Port durchgereicht werden muss. Grundsätzlich habe ich kein Problem damit, dass der Container und das native Linux kommunizieren.

Zitat von seahawk1986

Mit xineliboutput/vdr-sxfe bräuchte man nur eine Netzwerkverbindung zum Container

Die verschiedenen Ausgabeplugins sind für mich auch etwas undurchsichtig. Ist xineliboutput/vdr-sxfe gleichwertig zur Softhddevice Lösung mit VDPAU oder geht das mehr auf die CPU? Wo liegen die Vor- und Nachteile? Das einzige was ich fand ist, dass scheinbar xineliboutput/vdr-sxfe offenbar wiederum andere Ausgabeplugins nutzen kann. Evtl dann auch Softhddevice? Oder hab ich da was falsch verstanden?

Grundsätzlich wäre meine Vorstellung der Containerisierung die folgende (alles auf dem gleichen Server laufend):

1. Ein Container mit tvheadend der die DVB-C Sticks besitzt und diese per SAT->IP Streamt
2. Ein Container mit einem Headless VDR der per SAT->IP die TV Streams vom tvheadend Container bekommt und sich um Aufnahmen, EPGsearch etc. Kümmert. Das Aufnahmenlaufwerk ist entweder per NFS gemountet oder vom Nativen Linux als Volume durchgereicht.
3. Ein VDR Frontend das auf den Headless-VDR Container zugreift. Hier bin ich offen, ob sich das ebenfalls in einem Container befindet oder im nativen Linux installiert ist. Ich habe bislang keine Erfahrung mit getrenntem aufsetzen von Server und Frontend, hoffe aber, dass das ein reines Frontend recht leicht aufzusetzen sein sollte oder irre ich da?
4. Wo LIRC dann läuft ist auch noch offen. Evtl. auch eigener Container oder mit in einen der o.g. Auch hierzu freue ich mich über Meinungen und Tips

Warum ich den ganzen Zirkus machen will ist die Tatsache, dass ich damit unabhängig werde von der Linux Distri / Version des nativen Servers. Das mittlerweile doch uralte Ubuntu 14.04 ist einfach nicht mehr Zeitgemäß. Wir sind aktuell bei Ubuntu 18 und die 19er Version ist für April angekündigt. Und VDR ist nur einer der Dienste dich ich darauf laufen lasse. Webserver, VPN Server, Openhab etc. verrichten dort ebenfalls ihre Dienste und es wird zunehmen schwerer aktuelle Pakete für das alte Ubuntu zu finden. Ganz abgesehen von dem unsäglichen Upstart von dem Ubuntu nach der 14er Version ja verständlicherweise wieder abstand genommen hat

Zudem hat man mit dem Container ne definierte Umgebung und kann parallel in einem zweiten Container z.B. eine neue VDR Version testen, weiss aber, dass man jederzeit wieder auf eine stabil laufende Installation / Konfiguration über den Container zugreifen kann. Die Gefahr sich bei Tests alles zu zerschießen ist dadurch einfach gebannt. Auch der Transfer auf eine neue VDR Hardware wird dadurch immens vereinfacht.

Habt ihr dazu evtl. Tip? Meinungen? Anregungen? Vor allem über eine Klärung der Verständnisfragen ganz oben würde ich mich sehr freuen und danke im Voraus

Viele Grüße,

Stephan

Zitat von mini73

Das Plugin dbus2vdr ist bei yavdr ein Muss, das darf nicht disabled werden.

Lars

Danke für den Hinweis! Mit dem dbus2vdr Plugin klappte es dann auch wieder. Klar ist zwar nicht warum der VDR nicht startete als ich alle Plugins auf einmal wieder reaktivierte, aber nun konnte ich peu a peu alle Plugins wieder hinzufügen und alles läuft wieder. Danke für den Tip!