WD TV Live remote

  • Trying to setup my Infrared remote control on LE community deve-20170401 Generic.x86_64 (Acer Aspire ES1-511 laptop HTPC)
    I was able to see my codes (below).
    irrecord doesn't seem to create the Lircd.conf


    I don't know what to do. I have searched and tried many guides. Please help.





    Testing events. Please, press CTRL-C to abort.
    1491257390.801027: event type EV_MSC(0x04): scancode = 0x847912
    1491257390.801027: event type EV_SYN(0x00).
    1491257399.664019: event type EV_MSC(0x04): scancode = 0x847906
    1491257399.664019: event type EV_SYN(0x00).
    1491257400.588036: event type EV_MSC(0x04): scancode = 0x84790c
    1491257400.588036: event type EV_SYN(0x00).
    1491257402.081120: event type EV_MSC(0x04): scancode = 0x84790d
    1491257402.081120: event type EV_SYN(0x00).
    1491257402.874016: event type EV_MSC(0x04): scancode = 0x847902
    1491257402.874016: event type EV_SYN(0x00).
    1491257403.579841: event type EV_MSC(0x04): scancode = 0x847904
    1491257403.579841: event type EV_SYN(0x00).
    1491257404.217898: event type EV_MSC(0x04): scancode = 0x847901
    1491257404.217898: event type EV_SYN(0x00).
    1491257405.010623: event type EV_MSC(0x04): scancode = 0x84791f
    1491257405.010623: event type EV_SYN(0x00).
    1491257405.541018: event type EV_MSC(0x04): scancode = 0x84790a
    1491257405.541018: event type EV_SYN(0x00).
    1491257406.006006: event type EV_MSC(0x04): scancode = 0x84791e
    1491257406.006006: event type EV_SYN(0x00).
    1491257406.865089: event type EV_MSC(0x04): scancode = 0x84791b
    1491257406.865089: event type EV_SYN(0x00).
    1491257407.439106: event type EV_MSC(0x04): scancode = 0x847905
    1491257407.439106: event type EV_SYN(0x00).
    1491257407.969629: event type EV_MSC(0x04): scancode = 0x84791a
    1491257407.969629: event type EV_SYN(0x00).
    1491257408.675564: event type EV_MSC(0x04): scancode = 0x847907
    1491257408.675564: event type EV_SYN(0x00).
    1491257409.293317: event type EV_MSC(0x04): scancode = 0x847908
    1491257409.293317: event type EV_SYN(0x00).
    1491257409.888005: event type EV_MSC(0x04): scancode = 0x847909
    1491257409.888005: event type EV_SYN(0x00).
    1491257410.484134: event type EV_MSC(0x04): scancode = 0x84794c
    1491257410.484134: event type EV_SYN(0x00).
    1491257411.036439: event type EV_MSC(0x04): scancode = 0x847900
    1491257411.036439: event type EV_SYN(0x00).
    1491257411.523377: event type EV_MSC(0x04): scancode = 0x847903
    1491257411.523377: event type EV_SYN(0x00).
    1491257412.239423: event type EV_MSC(0x04): scancode = 0x84794d
    1491257412.239423: event type EV_SYN(0x00).
    1491257412.762019: event type EV_MSC(0x04): scancode = 0x847941
    1491257412.762019: event type EV_SYN(0x00).
    1491257413.380251: event type EV_MSC(0x04): scancode = 0x847914
    1491257413.380251: event type EV_SYN(0x00).
    1491257413.933137: event type EV_MSC(0x04): scancode = 0x847915
    1491257413.933137: event type EV_SYN(0x00).
    1491257414.573441: event type EV_MSC(0x04): scancode = 0x847916
    1491257414.573441: event type EV_SYN(0x00).
    1491257415.125630: event type EV_MSC(0x04): scancode = 0x847917
    1491257415.125630: event type EV_SYN(0x00).
    1491257415.766033: event type EV_MSC(0x04): scancode = 0x847918
    1491257415.766033: event type EV_SYN(0x00).
    1491257416.341035: event type EV_MSC(0x04): scancode = 0x847919
    1491257416.341035: event type EV_SYN(0x00).
    1491257416.959202: event type EV_MSC(0x04): scancode = 0x84790e
    1491257416.959202: event type EV_SYN(0x00).
    1491257417.687310: event type EV_MSC(0x04): scancode = 0x84791c
    1491257417.687310: event type EV_SYN(0x00).
    1491257418.349617: event type EV_MSC(0x04): scancode = 0x84791d
    1491257418.349617: event type EV_SYN(0x00).
    1491257418.924109: event type EV_MSC(0x04): scancode = 0x84795e
    1491257418.924109: event type EV_SYN(0x00).
    1491257419.586404: event type EV_MSC(0x04): scancode = 0x84795d
    1491257419.586404: event type EV_SYN(0x00).
    1491257420.204615: event type EV_MSC(0x04): scancode = 0x84795c
    1491257420.204615: event type EV_SYN(0x00).
    1491257420.823185: event type EV_MSC(0x04): scancode = 0x84795f
    1491257420.823185: event type EV_SYN(0x00).
    1491257421.507479: event type EV_MSC(0x04): scancode = 0x84790f
    1491257421.507479: event type EV_SYN(0x00).
    1491257422.333597: event type EV_MSC(0x04): scancode = 0x847911
    1491257422.333597: event type EV_SYN(0x00).
    1491257423.053271: event type EV_MSC(0x04): scancode = 0x847910
    1491257423.053271: event type EV_SYN(0x00).

    Edited once, last by Bubba2017 ().

  • Since the remote is supported by the kernel it's best to create an ir-keytable file instead of using userspace lircd.


    First stop eventlircd and kodi so they don't interfere:

    Code
    1. systemctl stop kodi
    2. systemctl stop eventlircd


    Then we need to find out which protocol the remote is using. To do that we need some info about the IR receiver which we can get with "ir-keytable". The output should look like this:

    Code
    1. LibreELEC:~ # ir-keytable
    2. Found /sys/class/rc/rc0/ (/dev/input/event1) with:
    3. Driver (null), table rc-dib0700-rc5
    4. Supported protocols: rc-5 nec rc-6
    5. Enabled protocols: rc-5
    6. Name: IR-receiver inside an USB DVB re
    7. bus: 3, vendor/product: 2040:7060, version: 0x0100
    8. Repeat delay = 500 ms, repeat period = 125 ms


    The important things are the supported and enabled protocols. Since you already got scancode output from "ir-keytable -t" you only need to test within the "Enabled protocols", otherwise you'd need to go through all "Supported protocols" (except "lirc", which isn't a real protocol).


    Now test with each protocol if you get scancode output. Run the following command (change the protocol after "-p") and press buttons on your remote.

    Code
    1. ir-keytable -p nec -t


    If you get no event output try the next protocol.


    If you set the correct protocol the output should look like this - note the EV_MSC events with "scancode = ..."

    Code
    1. LibreELEC:~ # ir-keytable -p nec -t
    2. Protocols changed to nec
    3. Testing events. Please, press CTRL-C to abort.
    4. 1491293447.763188: event type EV_MSC(0x04): scancode = 0x847908
    5. 1491293447.763188: event type EV_SYN(0x00).
    6. 1491293448.029412: event type EV_MSC(0x04): scancode = 0x847908
    7. 1491293448.029412: event type EV_SYN(0x00).
    8. 1491293448.351181: event type EV_MSC(0x04): scancode = 0x847908
    9. 1491293448.351181: event type EV_SYN(0x00).


    (BTW: the output above is with a WDTV live remote which I happened to have sitting in a box)


    Now that we have determined the protocol we can create a keytable file for the remote in /storage/.config/rc_keymaps/ - let's name it "wdtv-live". Open another ssh session and start an editor (keep "ir-keytable -t" running in the other session, we need that to get the scancodes).

    Code
    1. nano /storage/.config/rc_keymaps/wdtv-live


    In the very first line we have to put a header with the name of the table (the actual name is not important, better avoid blanks in it but you can name it anything you like) and the protocol (after "type: "). The protocol is the important thing here. The header should look like this:

    Code
    1. # table wdtv-live, type: NEC


    Now we have to map the buttons. Press a button on the remote, record the scancode you got from ir-keytable (the 0x... code after "scancode = ...") and add it to the keytable file together with the key name. Note: you have to use the official linux keynames as listed in linux/include/uapi/linux/input-event-codes.h - Elixir - Free Electrons


    When you're done the keytable file should look like this:

    Code
    1. # table wdtv-live, type: nec
    2. 0x847905 KEY_UP
    3. 0x847900 KEY_DOWN
    4. 0x847907 KEY_LEFT
    5. 0x847909 KEY_RIGHT
    6. 0x847908 KEY_OK
    7. 0x84791b KEY_BACK


    Save the file, stop "ir-keytable -t" and test if the keytable file is correct. Run the following command (it clears the current kernel keytable, loads your newly created one and then starts test mode) and press keys on the remote. Note that you should now also see EV_KEY events with the keycodes:


    To make this permanent create a rc_maps.cfg file in /storage/.config/

    Code
    1. nano /storage/.config/rc_maps.cfg


    Insert the following line to automatically load your keymap (on any ir receiver with any kernel default keymap):

    Code
    1. * * wdtv-live


    Save the file, then run the following command to test if everything's setup correctly:

    Code
    1. LibreELEC:~ # ir-keytable -a /storage/.config/rc_maps.cfg
    2. Old keytable cleared
    3. Wrote 6 keycode(s) to driver
    4. Protocols changed to nec


    so long,


    Hias



  • Thanks this did work.
    I needed to add

    Code
    1. ir-keytable -a /storage/.config/rc_maps.cfg


    to the autostart.sh file to make it work after rebooting.
    I added in red things that might help others who are noob like me.


  • I needed to add

    Code
    1. ir-keytable -a /storage/.config/rc_maps.cfg


    to the autostart.sh file to make it work after rebooting.


    Thanks for the feedback!


    It's odd that you needed to add that command to autostart.sh, the system should pick up .config/rc_maps.cfg automatically on boot.


    Could you please run the following commands and post the URL you got from the last one?

    Code
    1. udevadm control -l debug
    2. udevadm trigger --action=add -s input
    3. journalctl -a | paste


    so long,


    Hias


  • Configured this for a buddy.


    Hey Thanks daweze,


    I don't know what to do with the files you provided.


    I was able to program my remote using the method Hiassof provided.


    Thanks though.

  • Hello,


    I already post this to the OE forum (similiar topic about IR, and this topic was hinted for me by HiassofT), but as my platform is LE, I would post it also here:


    I cant make IR work on Rpi2 platform without lirc.
    I have this setup:

    Code
    1. dtoverlay=gpio-ir,gpio_pin=18,gpio_pull=1,rc-map-name=rc-rc6-mce






    When I try ir-keytable -t, no input shown from NEC and Samsung remotes. I also tried all other (-p rc-5, then rc-6, sony, sanyo, nec) explicitly, and test with NEC, Samsung and even Panasonic TV remotes, and still, no info at all. I dont know, where could be a problem here. The TV (Panasonic remote) is quite new, like 2015/2016 model, so I think it should be recognized by something.


    Btw., Samsung remote (which I using with lirc) has this kind of codes inside lirc conf:


    Any help would be appretiated. I think system doesnt operate with IR module at all, but I dont know what to setup differently except pin number.

    6x Odroid C2 + CoreELEC 9.0.1; 6x RPi2 + LibreELEC 9.0.1; 3x Win7 Kodi 18.1 + vPeter's mariaDB plugin as Library DB

    Edited once, last by JimmySmith ().

  • Hi!


    I already post this to the OE forum (similiar topic about IR, and this topic was hinted for me by HiassofT), but as my platform is LE, I would post it also here:


    I also answered on the OE forum 2 days ago but it looks my post is no longer there. Ah, well...

    Quote


    I cant make IR work on Rpi2 platform without lirc.


    When I try ir-keytable -t, no input shown from NEC and Samsung remotes. I also tried all other (-p rc-5, then rc-6, sony, sanyo, nec) explicitly, and test with NEC, Samsung and even Panasonic TV remotes, and still, no info at all. I dont know, where could be a problem here. The TV (Panasonic remote) is quite new, like 2015/2016 model, so I think it should be recognized by something.


    This probably means the remotes use some proprietary or non-standard protocol and you have to use lirc - or another remote :)

    Quote


    Btw., Samsung remote (which I using with lirc) has this kind of codes inside lirc conf:

    Code
    1. name /storage/.config/lircd.conf
    2. flags RAW_CODES|CONST_LENGTH


    lircd.conf files with RAW codes is a strong indication of a non-standard protocol.


    BTW: your kernel log looks odd, like it's coming from a 4.4 kernel. Are you using berryboot? If yes, I can only advise to get rid of it. Berryboot is not supported in LibreELEC as you'll be missing a lot of fixes from the LibreELEC kernel, especially in the rc subsystem.


    so long,


    Hias

  • Hello,


    Yes, I have the same feeling with RAWs (Samsung Remote), but what wonders me, I didnt get anything even with year old Panasonic remote (I even tried Pioneer AVR remote bought 6 months ago, still big nothing). I believe at least Panasonic's remote protocol should be pretty standardized; my Pioneer AVR remote has learning capabilities (actually can learn practically any other remote's button code), and has even pre-hardcoded like tens of codes from other brands, and when I tried just for fun use one of panasonic for it, at least arrows works out of the box. I mean, I told AVR remote: use panasonic code, and I would able to control Panasonic TV with it.


    No, I dont use berryboot, I am using pretty clean instalation of 7.0.3 LE (SDcard /flash, USB flasdrive /storage).. Could it be that this feature is avaible only from LE >= 8 ?


    Bottom line: I am perfectly fine with using lirc :) I am just curious about other possible methods..

    6x Odroid C2 + CoreELEC 9.0.1; 6x RPi2 + LibreELEC 9.0.1; 3x Win7 Kodi 18.1 + vPeter's mariaDB plugin as Library DB

    Edited once, last by JimmySmith ().


  • Yes, I have the same feeling with RAWs (Samsung Remote), but what wonders me, I didnt get anything even with year old Panasonic remote (I even tried Pioneer AVR remote bought 6 months ago, still big nothing). I believe at least Panasonic's remote protocol should be pretty standardized; my Pioneer AVR remote has learning capabilities (actually can learn practically any other remote's button code), and has even pre-hardcoded like tens of codes from other brands, and when I tried just for fun use one of panasonic for it, at least arrows works out of the box. I mean, I told AVR remote: use panasonic code, and I would able to control Panasonic TV with it.


    No, I dont use berryboot, I am using pretty clean instalation of 7.0.3 LE (SDcard /flash, USB flasdrive /storage).. Could it be that this feature is avaible only from LE >= 8 ?


    Bottom line: I am perfectly fine with using lirc :) I am just curious about other possible methods..


    I think (but I'm not 100% sure) LE 7.0.3 should work fine, but better upgrade to 8.0.1. Configuration via rc_maps.cfg is only available in 8.0.1, basic ir-keytable functionality worked before (I've been using gpio-ir with a hauppauge remote / rc-5 protocol for about a year).


    It's rather odd that you didn't get any output at all. (at least some) Samsung remotes use the NEC protocol, there's even a samsung keymap in /usr/lib/udev/rc_keymaps/samsung:

    Code
    1. # table samsung, type: NEC
    2. 0x43532f KEY_NUMERIC_0
    3. 0x435341 KEY_NUMERIC_1
    4. ...


    One nasty thing about ir-keytable is that it won't warn you if some other process (eg eventlircd) grabbed the event device - in that case you don't get any output from ir-keytable -t although decoding works perfectly fine.


    To check manually first run ir-keytable to see which event device it's using:

    Code
    1. LibreELEC:~ # ir-keytable
    2. Found /sys/class/rc/rc0/ (/dev/input/event1) with:
    3. ...


    Then check with lsof if that device is used:

    Code
    1. LibreELEC:~ # lsof | grep /dev/input/event1
    2. 566 /usr/sbin/eventlircd /dev/input/event1


    Ideally that command shouldn't output anything, here we see that eventlircd had grabbed the event device.


    Another possibility is to install the system tools addon and use evtest instead of ir-keytable -t - evtest will warn you if some process grabbed the device. You still have to use ir-keytable to select the protocol, but then use evtest to check for events.


    BTW: gpio-ir-recv (and several others of the ir receiver drivers in the rc subsystem) also supports a "raw" lirc device, /dev/lirc0, so you can use "mode2" to check if the driver is able to see any IR signals at all.


    so long,


    Hias

  • Quote


    Configuration via rc_maps.cfg is only available in 8.0.1


    Does it mean that I (on 7.0.3) cant use custom codes at all, or just I need to use existing filename (I mean copy /usr/lib/udev/rc_keymaps/XXY into /storage/.config/rc_keymaps/XXY and modify it for custom IR codes?


    I also tried

    Code
    1. dtoverlay=gpio-ir,gpio_pin=18,gpio_pull=1,rc-map-name=rc-samsung


    just from curiosity, no luck there also.


    Anyway, I follow your advices:
    Output with dtoverlay=lirc-rpi:

    Code
    1. ir-keytable
    2. Couldn't find any node at /sys/class/rc/rc*.


    Output with dtoverlay=gpio-ir,gpio_pin=18,gpio_pull=1,rc-map-name=rc-samsung, killed kodi and eventlirc:

    Code
    1. ir-keytable
    2. Found /sys/class/rc/rc0/ (/dev/input/event0) with:
    3. Driver gpio-rc-recv, table rc-empty
    4. Supported protocols: unknown other lirc rc-5 jvc sony nec sanyo mce-kbd rc-6 sharp xmp
    5. Enabled protocols: unknown lirc rc-5 sony nec sanyo rc-6 sharp xmp
    6. Name: gpio_ir_recv
    7. bus: 25, vendor/product: 0001:0001, version: 0x0100
    8. Repeat delay = 200 ms, repeat period = 125 ms
    9. lsof | grep /dev/input/event0
    10. Libreelec:~ #


    Installed System Tools, evtest shows:

    Code
    1. evtest
    2. No device specified, trying to scan all of /dev/input/event*
    3. Available devices:
    4. /dev/input/event0: gpio_ir_recv
    5. /dev/input/event1: MCE IR Keyboard/Mouse (gpio-rc-recv)
    6. /dev/input/event2: lircd


    I test all of above (0-2), and none of outputs shows any button keypress.

    Quote


    supports a "raw" lirc device, /dev/lirc0, so you can use "mode2"


    Could you elaborate this little bit more? I didnt find it in the github gpio-ir-recv description. I would like to try every option which I have to conclude it as: "Mysteriously, IR doesnt react on anything, except running under lirc" :)


    Still, big mystery for me..

    6x Odroid C2 + CoreELEC 9.0.1; 6x RPi2 + LibreELEC 9.0.1; 3x Win7 Kodi 18.1 + vPeter's mariaDB plugin as Library DB

  • Does it mean that I (on 7.0.3) cant use custom codes at all, or just I need to use existing filename (I mean copy /usr/lib/udev/rc_keymaps/XXY into /storage/.config/rc_keymaps/XXY and modify it for custom IR codes?


    On old systems you can, for example, use the override method. But you should really update to 8.0.1, do you have any particular reason why you are still using 7.0.3?

    Quote


    I also tried

    Code
    1. dtoverlay=gpio-ir,gpio_pin=18,gpio_pull=1,rc-map-name=rc-samsung


    You have to use a valid kernel map, i.e. one of the kernel modules in /lib/modules/*/kernel/drivers/media/rc/keymaps/ (without the .ko at the end).


    rc-samsung doesn't exist, therefore the kernel falls back to rc-empty:

    Quote


    Found /sys/class/rc/rc0/ (/dev/input/event0) with:
    Driver gpio-rc-recv, table rc-empty


    With ir-keytable you can only use the user space keymaps, eg the samsung one in /usr/lib/udev/rc_keymaps

    Code
    1. ir-keytable -c -w /usr/lib/udev/rc_keymaps/samsung



    Quote


    Could you elaborate this little bit more? I didnt find it in the github gpio-ir-recv description. I would like to try every option which I have to conclude it as: "Mysteriously, IR doesnt react on anything, except running under lirc" :)


    This means most rc subsystem drivers support both the new method with in-kernel decoding and the old method with userspace lircd. So you can use lirc tools like mode2 to debug IR issues or run lircd if you want to use a remote that's not supported by the kernel protocol decoders.


    The old lirc_xxx kernel drivers from the staging directory are currently being converted to rc drivers - or removed if noone cared about them.


    For you as a user this means (besides a name change, eg lirc_serial -> serial_ir) that you'll still be able to use lirc as before or use in-kernel decoding - if your remote protocol is supported.


    so long,


    Hias

  • Quote


    do you have any particular reason why you are still using 7.0.3


    For now, yes, but deeper discussion it is outside of scope this topic I guess. Maybe I will update eventually, but so far I still dont have enough trust to the Kodi >17 (malloc mentions, ffw memory mention, new default skin, cpu usage of new version, cec issues on some devices after libcec bump..). I actually have one SD card with latest LE8 pure on testing purposes , and watching news and feedback; but so far, "production" is still rock&solid on 7.0.3..

    Quote


    You have to use a valid kernel map


    Ah, mea culpa, I thought that /usr/lib/udev/rc_keymaps/samsung is enough. Still didnt catch all things around this IR kernel support I guess :( But, does it affect just "testing" button codes? I thought, that those maps are just "preconfigured" - hardcoded remote codes of brands remotes, it is actually affect possibility to use TSOP in general? If yes, that would mean just ir-record -p protocol choice isnt enough, and I must restart Rpi with all of .ko types and test if some of them will communicate with IR :s


    I am little bit confused around rc vs. ir things, I see .ko's on both /lib/modules/4.4.13/kernel/drivers/media/rc and /lib/modules/4.4.13/kernel/drivers/media/rc/keymaps. And also, why there appears two new inputs, after enabling dtoverlay=gpio-ir.


    /dev/input/event0: gpio_ir_recv
    /dev/input/event1: MCE IR Keyboard/Mouse (gpio-rc-recv)

    6x Odroid C2 + CoreELEC 9.0.1; 6x RPi2 + LibreELEC 9.0.1; 3x Win7 Kodi 18.1 + vPeter's mariaDB plugin as Library DB


  • Ah, mea culpa, I thought that /usr/lib/udev/rc_keymaps/samsung is enough. Still didnt catch all things around this IR kernel support I guess :( But, does it affect just "testing" button codes? I thought, that those maps are just "preconfigured" - hardcoded remote codes of brands remotes, it is actually affect possibility to use TSOP in general? If yes, that would mean just ir-record -p protocol choice isnt enough, and I must restart Rpi with all of .ko types and test if some of them will communicate with IR :s


    I am little bit confused around rc vs. ir things, I see .ko's on both /lib/modules/4.4.13/kernel/drivers/media/rc and /lib/modules/4.4.13/kernel/drivers/media/rc/keymaps.


    The kernel keymap (eg. drivers/media/rc/keymaps/rc-rc6-mce.ko) is automatically loaded by the kernel. For example an mceusb IR reciever has an hardcoded default for loading the rc-rc6-mce map.


    With gpio-ir-recv it's a little bit different, here you can configure the default kernel keymap.


    The effect of this is that for example you'll be able to use your (original) MCE remote out of the box, everything is setup by the kernel without having to use userspace tools like ir-keymap.


    On LibreELEC (and a lot of other Linux distributions) ir-keytable is available to change the default kernel configuration. For example, if you'd like to use another remote with your MCE IR receiver.


    If you use the gpio receiver and don't care about the kernel keymaps or even protocols, eg if you plan to setup everything with ir-keytable or use lircd you can simply use the rc-empty keymap - then no keycode entries will be installed by the kernel.


    ir-keytable configuration via rc_maps.cfg is an easy way to make the config permanent, that's the reason why I added it in 8.0.1 :)

    Quote


    And also, why there appears two new inputs, after enabling dtoverlay=gpio-ir.


    /dev/input/event0: gpio_ir_recv
    /dev/input/event1: MCE IR Keyboard/Mouse (gpio-rc-recv)


    I only get the "MCE IR Keyboard" here (LE 8.0.1, kernel 4.9) if I manually enable the mce_kbd protocol - kernel 4.4 loads all protocol decoder modules by default so this is probably why you are seeing it.


    so long,


    Hias

  • If I understand you correctly, then loaded/not loaded kernel keymap shouldnt interfere with ir-keytable -t / evtest results. So I am back on the start, why the heck I am not able see any input from any remotes which I tried :)


    I would be perfectly fine with custom mapping each of button, though (of course with option store it somewhere on /storage, just as lirc.conf do). I am used to do it since I started use (and still using) Girder+Serial IR on Windows, and to be honest I like that kind of freedom :) Lirc Rpi is very intuitive, but I dont see problem in gathering codes and create simple text file. In a way it would be more transparent, as you dont see codes within irrecord runtime, just output file.

    Quote


    if I manually enable the mce_kbd protocol


    Yea, that could be it. I noticed, that I can enable/disable "ir-keytable" all protocols (-p), except mce_kdb. For some reason it is propably enabled, even when I didnt see it between Enabled protocols: output from ir-keytable. Then I would call it standard behauviour also. I have nothing more to grasp :)

    6x Odroid C2 + CoreELEC 9.0.1; 6x RPi2 + LibreELEC 9.0.1; 3x Win7 Kodi 18.1 + vPeter's mariaDB plugin as Library DB

    Edited once, last by JimmySmith ().



  • I ran the commands as asked as I currently have it setup.
    Here is what the results were --> LcGV


  • I ran the commands as asked as I currently have it setup.
    Here is what the results were --> LcGV


    Hmm.. which build(s) are you using?

    Code
    1. Linux version 4.10.9 ([email protected]) (gcc version 6.3.0 (GCC) ) #1 SMP Sun Apr 9 21:35:26 CEST 2017


    Could be that this community build doesn't yet include the rc_maps.cfg changes - they were quite recently included in LibreELEC and first appeared in 8.0.1. If that build is based on 8.0.0 you'll be missing the new features.


    Can you test with the official 8.0.1 build?


    so long,


    Hias

  • I am using the community build with retroplayer integrated.


    Just run the update from the LibreElec addon?
    How do you want me to test?


    I have all my remotes currently working. Do you need me to test without the autostart.sh line?