Posts by JimmySmith

    Thats great news. Thank you!

    "make sure to disable in-kernel decoding" is this,

    1. : > /storage/.config/rc_maps.cfg

    or you mean create (even dummy) /storage/.config/lircd.conf, then reboot to be even able record something by commands above? Just to be sure, pardon me if its dumb question, I am trying to understand the wiki page.



    Although lircd disables all remote protocols on startup (and thus disables in-kernel decoding)

    I understand as disable in-kernel decoding means by running lircd

    and then


    lircd will now be started automatically if the /storage/.config/lircd.conf file is present.

    would suggest that when I record lircd.conf and reboot, kernel decoding should be disabled..

    P.S.: Perhaps would be usefull add the record procedure to the wiki page also..


    I am using LE 7.0.3 in various installations of RPi2, with various remotes (from old VCR, old TV's etc.) via raw codes

    recorded simply via

    1. config.txt: dtoverlay=lirc-rpi
    2. systemctl stop eventlircd.service
    3. systemctl stop kodi.service
    4. killall lircd
    5. ir-keytable -p lirc
    6. rm /storage/.config/lircd.conf
    7. irrecord -f /storage/.config/lircd.conf
    8. reboot now

    Works out of the box, for all remotes (its just matter of choose correct freq. IR diode).

    Now, due to slowly switching to the x265, I plan to build first PoC based on Odroid C2. I am afraid I cant use 7.0.3 here, so I will must use some of recent versions (and hope there will be no problem with HDMI passthrough to the receiver, HDMI-CEC etc.).

    I am a bit frightened by the "IR changes". Is it possible to use some procedure, or there is need to set up something differently? I think I once tried (but it was quite long ago) gpio-ir with Rpi just for curiosity, but it doesnt work for me..

    Thank you in advance, I bet, that this must be interesting also for others..


    I did build previous version so it fix for at least someone :)

    I am amazed to see, that official builds still doesnt use working version of libcec :(

    I can assume that it still not be fixed properly for vast majority of devices on libcec bleeding edge, but why they doesnt use commit, which is verified and working for the majority (if not all?).

    This is the case since 8.0.1 and I think its pity, that someone still needs to recompile this after long time since this founding :(

    I am not talking about developing. I am talking about my needs, please, try to understand user point of view, not developer one, and try to not force your preferences to me. What you mention seems to be workaround, not actually solution..

    I wrote down twice, that MMAL as general option is no go for me. It maybe solve a little glitch - which I still hope, its solveable just by configuration. But Ill most likelly eventually buy MPEG license, if someone didnt help me, more than change my "tuned" working configuration and start to dealing with another problems instead.. :)

    But how I can automatically trigger MMAL just for PVR streams? I think it would be possible to catch PVR (by tsmpg stream, or filename of playlist maybe?) via .xml, thats the first thing, but second would be how to change Acceleration parameters from there.

    For some reason, LE acts differently when handling mpeg stream, and mpeg recorded file.

    In case of file:

    • when both OMX and MMAL are enabled, it acts "fine": first tried OMX, then MMAL, and ends on ffmpeg.
    • when only OMX enabled: tried, and disable video stream
    • when only MMAL enabled: tried, and sucessfully fallback into ffmpeg

    Unfortunatelly, in MPEG2 stream case, there is need to be only MMAL enabled to get it work. And as I stated earlier, I dont wanna MMAL.. (A various problems and increased CPU load with it.. been there, dont wanna been there again, ugly! :-] )


    I am using OMX acceleration, works great. But recently I am start implementing TVHeadend client / PVR. SD channels on TV are MPEG2, and they dont play fine, when OMX is checked. I've got just black screen with audio, propably because missing MPEG2 codec lincenses:

    1. 08:01:09 46.545105 T:1571812256 ERROR: COMXCoreComponent::SetParameter - OMX.broadcom.video_decode failed with omx_err(0x80001005)
    2. 08:01:09 46.545250 T:1571812256 ERROR: OMXPlayerVideo : Error open video output
    3. 08:01:09 46.546589 T:1571812256 WARNING: OpenStream - Unsupported stream 0. Stream disabled.

    MMAL fallback works fine, but I dont want to use MMAL acceleration globally:

    1. 08:01:52 89.600616 T:1571812256 WARNING: CMMALVideo::Open Codec mmal-mpeg2 is not supported
    2. 08:01:52 89.600777 T:1571812256 NOTICE: CDVDVideoCodecFFmpeg::Open() Using codec: MPEG-2 video
    3. 08:01:52 89.602654 T:1571812256 NOTICE: Creating video thread
    4. 08:01:52 89.602959 T:1571812256 NOTICE: Opening stream: 2 source: 256
    5. 08:01:52 89.603073 T:1483731872 NOTICE: running thread: video_thread
    6. 08:01:52 89.603188 T:1571812256 NOTICE: Finding audio codec for: 86016
    7. 08:01:52 89.603882 T:1571812256 NOTICE: Creating audio thread
    8. 08:01:52 89.604248 T:1475343264 NOTICE: running thread: CDVDPlayerAudio::Process()

    I already tried add

    1. <omx>
    2. <omxdecodestartwithvalidframe>0</omxdecodestartwithvalidframe>
    3. </omx>

    with no luck.

    Is there any way (advancedsettings.xml), how to restrict(or change configuration related to) acceleration automatically, just for PVR (or MPEG streams?). The manual switching within menu is not an option for me :)

    Thanks in advance

    Is it right, that this patch did not make it into the current release 8.0.2?

    Did anybody adopted this patch to version 8.0.2?

    It can be that devs doesnt take care about Forum reports much, unfortunatelly. I dont know in which LibCEC commit was this fixed, but 8.0.2 use commit 2fc92b5, I compiled latest 3953f8d (Commits · Pulse-Eight/libcec · GitHub).

    I cant see Issues section on LibreELEC github, I will try to make some PR, if I will have time, to sort this out for you guys.

    EDIT: Pull Request created. Hopefully it find his way into next release.

    Hmm, then I will give up for this time I guess. I did my best. Thank you for the help, I learned something new. Thanks god we have lirc on board, which is not picky at all :)

    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.


    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 :)


    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..


    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)


    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

    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:

    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:

    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:

    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.


    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..


    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 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:

    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.

    I also think that Rpi3 uses the same image as Rpi2. Are you sure you see Extracting / Checking messages after reboot with update tar file in place? You need to have .tar file in correct .update folder (dont extract it).