Beiträge von CKone

    0.10.2 ist ausreichend, aber 0.10.1 nicht. In @horchi's git wird noch CoreELEC 19.5 erwähnt, und da ist noch 0.10.1 drin.


    Da liegen 5 Jahre dazwischen, so lange wurde eine veraltete Version benutzt.

    ja der hat auch noch 19.5 installiert, schreibe ich ihm mal in den Urlaub das er erst mal neu installieren muss :D


    Wie zeigt sich das Problem mit der falschen Version dann genau?

    das kann ich aber so nicht bestätigen jrie , mein CoreELEC 20 scheint da frischer zu sein:


    image von hier: https://github.com/CoreELEC/CoreELEC/releases/tag/20.0-Nexus


    sogar frischer als das 0.10.1 von jammy im chroot, ist das 0.10.2 nicht hinreichend?

    Könnte es sein, dass /dev zu dem Zeitpunkt noch nicht in das für das chroot genutzte Verzeichnis gemountet wurde?

    Wenn ich das richtig sehe, passiert das bei euren Skripten in https://github.com/horchi/vdrO…scripts/ubuntu-init.sh#L7 - dann bräuchte die irmplircd@.service noch eine Abhängigkeit von der ubuntu.service

    Code
    [Unit]
    Description=irmplircd - a daemon for IRMP receivers
    After=ubuntu.service
    Requires=ubuntu.service


    das hat wunderbar funktioniert, danke Alexander!


    Die Fernbedienung selber läuft jetzt insgesamt prima auf dem CoreELEC20 und dem irmplircd aus dem Ubuntu chroot, danke noch mal an jrie für sein Geduld beim debuggen der Timings.


    Die 5V USB Standby Spannung konnte ich am Ende aktivieren aus dem CoreELEC Menu, das war aber irgendwie zickig aber sie war plötzlich da als ich mit den Einstellungen für USB Power und WOL rungespielt habe. Den Powerkey auf dem gpio konnte ich hiermit aktivieren: https://www.bachmann-lan.de/od…t-einfachem-power-switch/ und den Einschalter dann mit Pin 9 und11 GPIO verbinden, die MCE Taste hatte Emma53 ja schon passend angelernt.


    Die Fernbedienung läuft jetzt anders als mit dem meson-ir wirklich wie man das aus den konventionellen VDR kennt, ich bin wirklich begeistert. Im klaren muss man sich aber darüber sein, dass da schon ein paar Kabel an dem Empfänger sind die es zu verstauen gilt, das ist aber hier bei mir kein Problem.

    danke, das Vorgehen funktioniert prinzipiell jedoch scheint das Timing nicht zu stimmen.


    Die udev rule löst das aus, legt den symlink an und startet den systemd service, dennoch bekomme ich ein dev not found


    wenn ich dann von Hand starte gehts dann problemlos.


    Code
    Feb 24 15:06:51 CKone systemd[1]: Starting irmplircd.service...
    Feb 24 15:06:51 CKone chroot[3245]: Could not open /dev/irmp_stm32: No such file or directory
    Feb 24 15:06:51 CKone chroot[3245]: Unable to open any event device!
    Feb 24 15:06:51 CKone systemd[1]: irmplircd.service: Deactivated successfully.
    Feb 24 15:06:51 CKone systemd[1]: Started irmplircd.service.

    Da ich relativ unzufrieden mit dem meson-ir auf meinem odroid n2+ bin habe ich mir von Emma53 einen STM32 Empfänger bestellt - ich hab son Ding schon seit Jahren an meinem VDR im Esszimmer und bin da egtl sehr zufrieden mit.


    Als Basis bin ich mit diesem alten LibreELEC Addon von jrie https://github.com/j1rie/IRMP_…aster/irmplircd/LibreELEC und meiner CoreElec 20 Installation mit chroot Ubuntu eingestiegen. Benötigt werden hier vor hauptsächlich aktuelle arm4 Binarys zu irmplircd lircd-uinput.


    Für das irmplircd hatte ich beta gebeten mit einmal das binary auf seiner Entwicklungsumgebung zu bauen, das läuft aber leider weder bei ihm noch bei mir, genauso wenig wie das Binary aus Ubuntu Jammy. Um hier weiterzukommen hab ich kurzerhand das Paket auf dem chroot Ubuntu Jammy installiert und von CoreELEC aus gestartet:


    Die Unit hab ich dazu kurz passend gemacht:


    das lircd-uinput ist auf dem Coreelec freundlicherweise dabei, daher hab ich dein binary rausgehauen und durch einen Symlink ersetzt:

    Code
    lircd-uinput -> /usr/sbin/lircd-uinput


    Damit startet das lircd-uinput mit dem systemd service.


    den meson Empfänger kann man hiermit ausknipsen, so dass beim nächsten boot das Modul nicht mehr geladen wird:

    Code
    touch '/storage/.config/remote.disable'

    meine bestehende MCE Konfiguration für ir-keytable konnte ich mithilfe der irmp_keymap.map aus dem 1. Beitrag Verkaufsthread von Emma53 mit einem Editor einfach passend machen.


    Ab hier funktioniert die Fernbedienung erstmal und läuft auch schon extrem rund mit der Harmony MCE Profil die ich seit Jahren nutze. Obwohl das irmplircd auf dem chroot gestartet wurde funktioniert hier 👍


    Ein Problem hab ich ich noch mit dem irmplircd.service wen ich den enablen will, da moniert er ein nicht vorhandenes Device .

    Code
    root@CKone:~$ systemctl enable irmplircd
    Created symlink /storage/.config/system.d/dev-irmp_stm32.device.wants/irmplircd.service → /storage/.config/system.d/irmplircd.service.
    Unit /storage/.config/system.d/irmplircd.service is added as a dependency to a non-existent unit dev-irmp_stm32.device.


    Hier fehlt mir leider im Moment etwas die Idee, das device wird ja aus der udev Rule erzeugt und das funktioniert ja einwandfrei.


    Vllt hat hier ja noch wer eine Idee?

    Bei den irmplircd-Empfängern müssen im wesentlichen die Binaries irmplircd und lircd-uinput für arm kompiliert werden, alles andere kann im Prinzip übernommen werden.

    Ich mag jetzt den Thread hier nicht highjacken aber mal einen kurzen Zwischenstand: der Empänger ist da und die udev Rule greift auch, das lircd-uinput ist im Standard Corelec 20 hier dabei:


    Code
    CKone:/usr/sbin # lircd-uinput
    lircd-0.10.2[5693]: Info: lircd-uinput:  Opening log, level: Info
    lircd-0.10.2[5693]: Info: Reading data from /run/lirc/lircd.socket, writing to /dev/uinput
    lircd-0.10.2[5693]: Notice: POLLERR or curl_poll() error, exiting.


    Jetzt bräuchte ich nur noch das passende irmplircd binary, könnte das vllt jemand von hier mit einer passenden Entwicklungsumgebung kurz übersetzen:

    https://launchpad.net/~seahawk…3-git20180103.orig.tar.gz oder von hier https://github.com/realglotzi/irmplircd


    das wäre wirklich super.

    Oder teste auch noch einmal andersrum und schau dir die IP Adressen an, die auf der vdrs Tabelle hinterlegt sind.

    Das sind die Adressen, an die der EPGD die Kommandos sendet.

    ist im epg2vdr Plugin da korrekte Netzwerkgerät eingestellt, damit der epgd dem vdr während er selbst auf der Tabelle rumschreibt dem Plugin sagen kann keine neuen DVB Events zu senden?


    Ich hab mir da auch mal n Wolf gesucht.

    Moin


    was ich immer mal fragen wollte: beim "SES UHD Demo Channel", bekommt ihr da auch mit Passthrough mit softhdodroid (hier hängt noch ein Denon AVR dazwischen) keinen Ton ?


    Auf meinem anderen NUC8 VDR mit softhddrm am Sony TV direkt habe ich Ton auf diesem Sender.


    Danke

    FLIRC ist wie eine Tastatur, die Einträge sehen bei mir so aus:



    Du kannst aber auch Deine FLIRC anlernen, die REMOTE löschen und dann den VDR starten. Er fragt dann automatisch ab. Wichtig ist, dass Du VDR für ein Terminal startest, z.B. -t /dev/tty7 und zuvor in der Konsole (runvdr) auch in dieses Terminal wechselst, z.B. chvt 7.


    also abgesehen von den bekannten Nachteilen des Flirc, also kodi schwerig, kein wakeup und nicht mit irexec zu nutzen ist das Ding toll- allerdings hatte das Ding massiv Probleme mit den tooglebits meines "Microsoft Windows Media Center SE" Profils. Siehe: https://support.flirc.tv/hc/en…nd-Key-Press-Doesn-t-Work


    Ich bin da jetzt wie angeregt mit der Harmony auf ein Panasonic DMR_HST230 Profil gewechselt und muss sagen das damit die Fernbedienung absolut perfekt läuft, mit den besagten Flirc Einschränkungen halt. - aber das Beste an FB was ich auf dem odroid bisher gesehen hab, könnteman theoretisch auch so lassen.


    Ich hab dann gestern aber nochmal mit dem Alexander gemailt und ich würde mich gern noch mal an den STM32 Empfänger machen, den ich hier auf einem anderen VDR seit Jahren benutze. Leider fehlt dem coreelec hierzu das irmplircd , alledings haben wir dazu ein altes LIBREELEC Addon gefunden: https://github.com/j1rie/IRMP_…aster/irmplircd/LibreELEC


    ich versuche mich mal dran das mit vereinten Kräften wieder gangbar zu machen