Help request: VDR CoreElec (chroot oder Zabrimus) und amremote/eventlird

Man kann auch versuchen, auf eventlircd zu verzichten mit einer kleinen Änderung in udev-Regel:

#/storage/.config/udev.rules.d/ps3remote.rules

KERNEL=="event?", ATTRS{name}=="PS3 Remote", \
SYMLINK="input/ps3remote" , ENV{eventlircd_enable}="false"

Eventlircd sollte dann nichts mehr mitkriegen und sich im Prinzip so verhalten, als wenn es gestoppt und disabled wäre.

Danach verwendet man das vdr-remote-Plugin unter Vorgabe des Parameters

—-input=/dev/input/ps3remote

und durchläuft dann den Anlernprozess in vdr. Bei mir hätte eine originale NEC-FB so gut funktioniert.

Ob Zabrimus allerdings das remote-Plugin in seinem Sortiment hat und ob es wie beschrieben vom exklusiven device-Zugriff „ent-patcht“ ist, weiss ich nicht!

Hi,

Nur als Idee : auf den Standard Tastaturbelegungen ist F1 rot...

MfG Stefan

Zitat von Dr. Seltsam

Gibt es bei VDR*Elec denn eine vorbelegte remote.conf für vdr? Ich habe bislang keine gefunden.

Eine Default-Konfiguration wird nicht mitgeliefert, weil ich auch nicht weiß welche ich nehmen soll.

Zitat von Dr. Seltsam

Linux wie wir es kennen und lieben. Jeder kocht sein eigenes Süppchen, und eine theoretisch simple Fernbedienungskonfiguration wird zur Raketenwissenschaft.

Wenn ich das so lese, dann denke ich auch, das meine Versuche auch etwas Zeit in Anspruch nehmen wird. Bei der bisherigen Konfiguration habe ich immer erst geprüft, ob Kodi vernünftig bedienbar ist und dann die VDR remote.conf erstellt.

Mich interessiert, ob die Version ohne /storage/.config/remote.conf immer noch überall einwandfrei funktioniert?

Wie funktioniert das bei LibreELEC? Gibt es da auch verschiedene Treiber und damit Probleme? Nicht das es die remote.conf da immer gibt und durch die Änderung auf einmal nix mehr funktioniert.

Zitat von Zabrimus

Wie funktioniert das bei LibreELEC? Gibt es da auch verschiedene Treiber und damit Probleme? Nicht das es die remote.conf da immer gibt und durch die Änderung auf einmal nix mehr funktioniert.

Ich habe jetzt nicht alles gelesen, aber bei LE habe ich hier keine/storage/.config/remote.conf. Woher käme die?

Ist das ganze nicht eine amlogic spezifische Sache? Dann würde ich das auch auf CE beschränken... Weniger ist mehr.

Falls es noch niemand verlinkt hat, mache ich das hier nochmal: https://www.yavdr.org/documentation/0.6/de/ch02s03.html und https://wiki.libreelec.tv/configuration/ir-remotes

Die haben mir zum Verständnis sehr geholfen - obwohl ich jetzt letztendlich mit FLIRC unterwegs bin...

LibreElec unterstützt ältere amlogic-Hardware und offenbar zumindest im Alpha-Stadium auch neuere Modelle: https://libreelec.tv/downloads/amlogic/

Wahrscheinlich wird softhdodroid darunter nicht laufen, aber zumindest sollte es standardmäßig keine remote.conf geben. LibreElec setzt voll auf Mainline. Bei älteren Versionen kann das anders aussehen, aber da wird die unterstützte Hardware vermutlich erst recht nicht mit vdr laufen.

So, ich habe nach langer Zeit mal wieder ein VDR*Elec auf meiner Tanix TX3 ausprobiert. Mit meinen vorhandenen /storage/.config/remote.conf und /storage/.config/vdropt/remote.conf funktioniert die Fernbedienung unter vdr auf Anhieb richtig.

Man kann nach dem Stoppen von eventlircd die Tastenzuordnung mittels evdev kontrollieren, indem man nicht das aml_keypad device (=amremote) auswählt, sondern das "PS3 Remote" device. Das ist nicht "grabbed by another process".

Damit Kodi vernünftig bedient werden kann, empfiehlt es sich wohl doch, in der /storage/.config/remote.conf für die OK-Taste den event 28 (KEY_Enter) zu hinterlegen. In der /storage/.config/vdropt/remote.conf dann entsprechend

LIRC.Ok         KEY_ENTER

Ansonsten müsste man in Kodi mit z.B. dem Key map Editor -Addon die Taste definieren, weil Kodi mit KEY_OK nichts anfangen kann. Da man aber auch für die Vornahme dieser Zuordnung in Kodi eine funktionierende Entertaste braucht, müsste man dafür extra eine Tastatur anschließen. Ich glaube es wird dann wirklich einfacher, die Belegung für vdr wie oben beschrieben anzupassen - zumal man das für die Menütaste, die als KEY_C definiert wird, ohnehin machen muss.

Ansonsten gab es mit keiner Taste Probleme. Alle Farbtasten kommen richtig an.

Eine Merkwürdigkeit fiel mir auf, die ich mir nicht so recht erklären kann: Ein paar Tasten (Left/Right/Up/Down/Channel+/Channel- sowie die Zifferntasten) funktionieren im vdr auch bei gestopptem eventlircd (prellen allerdings fürchterlich). Wie kann das sein? Über /var/run/lirc/lircd kann vdr keine Tasten empfangen, wenn eventlircd nicht läuft. Und native Unterstützung von /dev/input/eventX hat vdr ohne remote-Plugin nicht. Es kann also nur so sein, dass einige FB-Tasten als Tastatur über die KBD-Einträge in vdr's remote.conf erkannt werden.

Was fiel mir noch auf?

• bei identischer Konfiguration ist die FB spürbar langsamer als bei meiner Ubuntu-chroot-Installation.
• Es gibt immer noch das alte Problem, dass mit deaktiviertem Fast Channel Switch (was leider immer noch Plugin-Standard ist) das Bild beim Umschalten manchmal für einen Moment zu schnell läuft. Unter chroot tritt das nie auf.
• während in den VDR Menüs an diversen Stellen die Umlaute richtig angezeigt werden (z.B. "Kanäle"), werden sie an anderer Stelle falsch dargestellt, als wenn der falsche Zeichensatz verwandt würde. Da kann ich mir keinen Reim drauf machen. Sieht aus, als sei die po-Datei fehlerhaft.

Was die Integration von amremote und ps3remote.py angeht, hat Zabrimus jedenfalls einen tollen Job gemacht!

Ok, danke das Du VDR*ELEC gegengeprüft hast.

Habe mir jetzt "nur" die Farbasten nochmal neu angeschaut. Es stellte sich raus, dass ich einen Übertragungsfehler bei einem Tastencode hatte.

Farbasten amremote Ausschnitt aus /storage/.config/remote.conf

    0x23 59  # KEY_F1 rot
    0x22 60  # KEY_F2 grün
    0x25 61  # KEY_F3 gelb
    0x24 62  # KEY_F4 blau

und

Farbtasten vdr Ausschnitt aus /storage/.config/vdroprt/remote.conf

LIRC.Red        KEY_F1
LIRC.Green      KEY_F2
LIRC.Yellow     KEY_F3
LIRC.Blue       KEY_F4

funktioniert jetzt.

Mein Fehler war u.a.:

Farbtasten vdr Ausschnitt aus /storage/.config/vdroprt/remote.conf

So funktioniert es nicht:
#LIRC.Red        KEY_RED
#LIRC.Green      KEY_GREEN
#LIRC.Yellow     KEY_YELLOW
#LIRC.Blue       KEY_BLUE

zu verwenden und ein falscher Tastencode amremote...

Gibt es einen Grund, das Du nicht gleich

0x23 0x18e #KEY_RED

zugeordnet hast?

Dann funktioniert in vdr auch

LIRC.Red        KEY_RED

Braucht Kodi unbedingt KEY_F1?

Zitat von Dr. Seltsam

Gibt es einen Grund, das Du nicht gleich

Code

0x23 0x18e #KEY_RED

zugeordnet hast?

Dann funktioniert in vdr auch

Code

LIRC.Red        KEY_RED

Braucht Kodi unbedingt KEY_F1?

Oh man, habe es aus Unverständnis so gemacht

Ich las die event codes, dachte ich kann nur die einfachen zwei/dreistelligen Zahlencodes verwenden und habe auch nicht nach z.B. Red gesucht.

Naja, jetzt ist es korrigiert - läuft.

Kodi ist in Benutzung/Tastenbelegung Neuland für mich. Nutze Kodi vielleicht zu 5%...

Kann die Frage ob F1 unbedingt gebraucht wird nicht beantworten.

Von den anderen Punkten auf Beitrag #66 ist besonders die spürbar langsamere FB interessant. Trotz gleicher Konfiguration...

Muss mich jetzt erstmal richtig mit dem Odroid anfreunden, z.B. habe ich mir für Weiteres nun eine zweite eMMC bestellt.

Bleibe hier und hier am Ball.

Danke für die Geduld

Vorweg: Ich nutze VDR*ELEC mit Rockchip.

Zitat von Dr. Seltsam

Was fiel mir noch auf?

• bei identischer Konfiguration ist die FB spürbar langsamer als bei meiner Ubuntu-chroot-Installation.

Finde ich sehr interessant. Hast du eine Vermutung, woran es liegen kann, dass die FB langsamer ist? Ich habe zwar keinen Vergleich, aber eine Verzögerung bei der FB konnte ich bei mir noch nie feststellen. Es muss ja was geben, was den Unterschied ausmacht und tendenziell würde ich eher tippen, dass eine native Umgebung flüssiger läuft, als eine chroot.

Zitat von Dr. Seltsam

• während in den VDR Menüs an diversen Stellen die Umlaute richtig angezeigt werden (z.B. "Kanäle"), werden sie an anderer Stelle falsch dargestellt, als wenn der falsche Zeichensatz verwandt würde. Da kann ich mir keinen Reim drauf machen. Sieht aus, als sei die po-Datei fehlerhaft.

Kannst du das eingrenzen oder präzisieren? Welche Menüs/Plugins sind hier betroffen? Dann kann ich mal schauen und das ggfs. hier auch testen.

Zitat von rell

Finde ich sehr interessant. Hast du eine Vermutung, woran es liegen kann, dass die FB langsamer ist? Ich habe zwar keinen Vergleich, aber eine Verzögerung bei der FB konnte ich bei mir noch nie feststellen. Es muss ja was geben, was den Unterschied ausmacht und tendenziell würde ich eher tippen, dass eine native Umgebung flüssiger läuft, als eine chroot.

Das ist das große ungelöste Rätsel. Performance-Unterschiede habe ich ja auch bei vdr - das Umschaltverhalten ohne fast Channel Switch ist definitiv schlechter, ständig läuft das Bild zu schnell, als müsse eine AV-Zeitdifferenz aufgeholt werden. Das Phänomen haben ja auch andere schon bestätigt. Was kann dazu führen, dass die gleiche Anwendung unter dem gleichen laufenden Kernel in einer chroot-Umgebung performanter läuft? Mir fiele dazu nur ein:

• andere glibc
• evtl. andere Compiler-Optionen beim Kompilieren verwandt

Zitat

Kannst du das eingrenzen oder präzisieren? Welche Menüs/Plugins sind hier betroffen? Dann kann ich mal schauen und das ggfs. hier auch testen.

Schau mal in das Buildsystem unter

VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-20/build/_vdr-2.6.4/po/

Es gibt eine de_DE.po.orig und eine gepatchte de_DE.po

In der po-Datei steht

"Content-Type: text/plain; charset=ISO-8859-15\n"

"Content-Transfer-Encoding: 8bit\n"

Wenn ich sie mit 8859-15 Kodierung öffne, wird alles korrekt angezeigt. Öffne ich sie hingegen in UTF-8, sollten eigentlich alle Umlaute falsch angezeigt werden, wie z.B.

msgstr "Br�ckenzeit zwischen Timern (min)"

Bei einigen Einträgen werden sie dann aber richtig angezeigt, und das sind auch genau die Einträge, die dann im Menü falsch dargestellt werden:

msgstr "Mindestzeit für vorherigen Kanal (s)"

Ich vermute, dass da irgendwas beim Patchen schief gegangen ist, obwohl auch die de_DE.po.orig den gleichen Fehler enthält (die aber offensichtlich auch schon reingepatchte Zapcockpit-Einträge enthält).

Die Übersetzungen der Plugins habe ich nicht weiter getestet.

Die Umlaute werden wohl tatsächlich durch den zapcockpit verhunzt. Damit https://github.com/rellla/VDRS…acfd01c2048468b49287bba40 sollte es hoffentlich passen.

Den fast Channel Switch könnte man auch direkt von VDR*ELEC einpatchen lassen. Ich habe keinen Odroid, aber ist es besser, wenn das standardmäßig aktiviert ist?

Zitat von Dr. Seltsam

• andere glibc
• evtl. andere Compiler-Optionen beim Kompilieren verwandt

Welche glibc nutzt du in der chroot-Umgebung? Welche Compiler-Flags sind bei dir gesetzt?

Zitat von rell

Den fast Channel Switch könnte man auch direkt von VDR*ELEC einpatchen lassen.

Das ist nicht nötig. Den baue ich in die nächste Version von softhdodroid als default ein.

Zitat von rell

Welche glibc nutzt du in der chroot-Umgebung? Welche Compiler-Flags sind bei dir gesetzt?

Die chroot ist ein Ubuntu 20.04 von Hardkernel. Die haben da nur einen amlogic-Kernel reingepackt, ansonsten müsste das die normale glibc 2.31 von Focal sein. Ich habe am Makefile von vdr nichts geändert:

# Compiler flags:

PKG_CONFIG ?= pkg-config

CC       ?= gcc
CFLAGS   ?= -g -O3 -Wall

CXX      ?= g++
CXXFLAGS ?= -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses
CXXFLAGS += $(CPPFLAGS)

CDEFINES  = -D_GNU_SOURCE
CDEFINES += -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE

LIBS      = -ljpeg -lpthread -ldl -lcap -lrt $(shell $(PKG_CONFIG) --libs freetype2 fontconfig)
INCLUDES ?= $(shell $(PKG_CONFIG) --cflags freetype2 fontconfig)

Greift das auch für Plugins?

Im Makefile von softhdodroid steht

### The compiler options:

export CFLAGS    = $(call PKGCFG,cflags) -I.
export CXXFLAGS = $(call PKGCFG,cxxflags)

ifeq ($(CFLAGS),)
$(warning CFLAGS not set)
endif
ifeq ($(CXXFLAGS),)
$(warning CXXFLAGS not set)
endif

Gibt es noch globale Einstellungen auf Betriebssystem-Ebene? Wo wird festgelegt, für welche Architektur kompiliert wird? Neben der grundlegenden Wahl aarch64 (= arm64) oder 32-bit gibt es ja auch noch CPU-abhängige Optimierungen (armv..)

Das Build-System von CoreElec hat da einige Konfigurationsmöglichkeiten in VDRSternELEC/CoreELEC/config/

Mir ist aber nicht klar, ob die erzeugten Target-images je Box individuell optimiert kompiliert wurden, oder ob für größtmögliche Kompatibilität evtl. Kompromisse gemacht wurden.

Ich habe da nur Halbwissen...

Nur damit ich es richtig verstehe. Du vergleichst VDR*ELEC mit CoreELEC-20-ng als Basis mit einem CoreELEC-20-ng worin eine chroot Umgebung läuft?

Oder die 21er Version? Und beides mal arm und nicht aarch64?

/home/andreas/git/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-20/toolchain/bin/armv8a-libreelec-linux-gnueabihf-g++ -march=armv8-a+crc -mtune=cortex-a53 -mabi=aapcs-linux -Wno-psabi -Wa,-mno-warn-deprecated -mfloat-abi=hard -mfpu=neon-fp-armv8 -Wall -pipe  -O2 -fomit-frame-pointer -DNDEBUG  -fPIC -c -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DREMOTE_KBD -DVDR_USER=\"root\" -DLIRC_DEVICE=\"/var/run/lirc/lircd\" -DVIDEODIR=\"/storage/videos\" -DCONFDIR=\"/storage/.config/vdropt\" -DARGSDIR=\"/etc/vdr/conf.d\" -DCACHEDIR=\"/storage/.cache/vdr\" -DRESDIR=\"/storage/.config/vdropt\" -DPLUGINDIR=\"/usr/local/lib/vdr\" -DLOCDIR=\"/usr/local/vdrshare/locale\" -I/home/andreas/git/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-20/toolchain/armv8a-libreelec-linux-gnueabihf/sysroot/usr/include -I/home/andreas/git/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-20/toolchain/armv8a-libreelec-linux-gnueabihf/sysroot/usr/include -I/home/andreas/git/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-20/toolchain/armv8a-libreelec-linux-gnueabihf/sysroot/usr/include/freetype2 -I/home/andreas/git/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-20/toolchain/armv8a-libreelec-linux-gnueabihf/sysroot/usr/include  -o sections.o sections.c

So baut VDR auf CoreELEC/VDR*ELEC. Unterschiedlich ist schonmal das optimize level...

Zitat von rell

Nur damit ich es richtig verstehe. Du vergleichst VDR*ELEC mit CoreELEC-20-ng als Basis mit einem CoreELEC-20-ng worin eine chroot Umgebung läuft?

Oder die 21er Version? Und beides mal arm und nicht aarch64?

Es ist auf alle Fälle 20-ng

Es kann sein, dass die Basis des chroot-Systems sogar ein VDR*Elec (ohne ausgeführtes install-Script) ist - zumindest läuft aber der Kernel von Zabrimus wegen einiger benötigter Patches.

Ob arm oder aarch64 kann ich nicht sagen, da ich zumindestens weder beim Build-Prozess für VDR*Elec noch beim Kompilieren im chroot-System unter Ubuntu 20.04 irgendwas in der Richtung vorgegeben habe.

Zitat von rell

Code

/home/andreas/git/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-20/toolchain/bin/armv8a-libreelec-linux-gnueabihf-g++ -march=armv8-a+crc -mtune=cortex-a53 -mabi=aapcs-linux -Wno-psabi -Wa,-mno-warn-deprecated -mfloat-abi=hard -mfpu=neon-fp-armv8 -Wall -pipe  -O2 -fomit-frame-pointer -DNDEBUG  -fPIC -c -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DREMOTE_KBD -DVDR_USER=\"root\" -DLIRC_DEVICE=\"/var/run/lirc/lircd\" -DVIDEODIR=\"/storage/videos\" -DCONFDIR=\"/storage/.config/vdropt\" -DARGSDIR=\"/etc/vdr/conf.d\" -DCACHEDIR=\"/storage/.cache/vdr\" -DRESDIR=\"/storage/.config/vdropt\" -DPLUGINDIR=\"/usr/local/lib/vdr\" -DLOCDIR=\"/usr/local/vdrshare/locale\" -I/home/andreas/git/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-20/toolchain/armv8a-libreelec-linux-gnueabihf/sysroot/usr/include -I/home/andreas/git/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-20/toolchain/armv8a-libreelec-linux-gnueabihf/sysroot/usr/include -I/home/andreas/git/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-20/toolchain/armv8a-libreelec-linux-gnueabihf/sysroot/usr/include/freetype2 -I/home/andreas/git/VDRSternELEC/CoreELEC/build.CoreELEC-Amlogic-ng.arm-20/toolchain/armv8a-libreelec-linux-gnueabihf/sysroot/usr/include  -o sections.o sections.c

So baut VDR auf CoreELEC/VDR*ELEC. Unterschiedlich ist schonmal das optimize level...

Beim Kompilieren in chroot kriege ich diese Anzeigen:

cc -g -O3 -Wall -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I.  -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/aarch64-linux-gnu -I/usr/include/aarch64-linux-gnu  -I/usr/include/aarch64-linux-gnu -DPLUGIN_NAME_I18N='"softhdodroid"' -D_GNU_SOURCE -DDEBUG          -DHAVE_GL             -DAV_INFO -DAV_INFO_TIME=3000     -DUSE_MPEG_COMPLETE         -DUSE_VDR_SPU             -DUSE_OPENGLOSD  -DUSE_ALSA -DUSE_SWRESAMPLE  -DGIT_REV='"253e448"'  -g   -std=gnu99    -c -o video.o video.c

Die Default-Einstellung scheint tatsächlich "-O2" zu sein. Leider ist es so, daß man die Optimierung auf "-O3" nur per Package machen kann.

Mein Versuch das Flag global zu setzen (https://github.com/CoreELEC/Co…reelec-20/config/optimize) funktioniert nicht, weil z.B. flac bei "-O3" mit einem internen Compiler-Fehler abbricht

Ich sehe 2 Möglichkeiten:

1. Patchen aller CE/LE Packages (per Script) um die package.mk mit "+speed" zu erweitern. Da bräuchte man aber eine Blacklist von Paketen, für die das nicht gemacht werden darf. Ein riesiger Nachteil ist, daß alles komplett neu gebaut werden muss.

2. Patchen der "eigenen" Pakete (VDR + Abhängigkeiten). Das würde dann zumindest VDR + Konsorten vielleicht schneller machen und der Neu-Build würde sich eben nur auf diese Pakete beschränken.

Ich tendiere gerade zu 2, weil ich da mehr Kontrolle habe und auch schneller feststellen kann, ob etwas nicht baut. Vielleicht ergibt sich dann schon genug Performance oder weniger spürbare Langsamkeit.

Zabrimus Jetzt warst du schneller. Es ginge auch so. Es tauchen dann zwar -O2 und -O3 in der build Zeile auf, aber lt. Spec zählt das letztgenannte.

Die 2-3 Plugin-Tests zeigen auch, dass die Flags für die Plugins übernommen werden. Obgleich dein Patch mehr Zeilen hat, glaube ich, dass es sauberer ist, so wie es du gelöst hast.

Offtopic: Im Branch oben sind noch ein paar Patches drin, damit bei mir x86 wieder baut und cef etwas schöner einbaut. Auch wenn da noch ein paar TODOs sind.