Posts by HiassofT

In general it's best to disable Lirc in LE settings->services and use the more modern "ir-keytable" configuration (which uses the IR support built into the Linux kernel).

Detailed information about that is in the wiki: Infrared Remotes [LibreELEC.wiki]

Note that some IR receivers in USB DVB adapters only support a limited set of IR protocols (run "ir-keytable" to find out which they are) which means you may not be able to use every remote - the GPIO IR receiver and MCE USB receivers can support all protocols/remotes and can also be used with Lirc if your remote uses some non-standard protocol.

Another alternative to IR remotes on RPi is using CEC, i.e. using your TV's remote to control the RPi. If your TV supports that it should work out of the box.

so long,

Hias

GPIO IR receivers are rather sensitive to interrupt latency and unfortunately USB traffic (such as from DVB adapters) can introduce such latencies. A couple of people had the same issues as you.

Easiest solution then is to use an USB IR receiver - maybe one of your DVB adapters has an IR receiver built in which you can use, otherwise an MCE USB receiver (eg the "HP" ones available on ebay) is usually a good choice.

so long,

Hias

Make sure you disable Lirc in Settings->Libreelec->Services.

so long,

Hias

Well, as I wrote before eventlircd has nothing to do with lirc, it's for supporting remotes handled by the kernel. And most people absolutely need it.

If you don't need/want it you can just run "systemctl mask eventlircd" to disable it.

so long,

Hias

In case of IR issue it's a good idea to look into the media build / crazycat / dvb packages - or disable them. They also replace the rc-core subsystem which is responsible for IR remotes.

Very slow IR response with harmony remotes and current kernels <= 4.17 is mostly caused by setting command repeat to 0 (or 1). Set it to 1 (or 2) so that the remote sends at least 2 IR messages on a short button press.

The current linux media tree (which will go into 4.18) contains improvements in this area which make IR remotes a lot snappier (even Harmony remotes with command repeat disabled). I've backported these to kernel 4.14 (they are merged in LE master tree), when using kernel 4.17-rcX you can probably just pick these commits:

a86d6df84ae6 media: rc: set timeout to smallest value required by enabled protocols
284922562b81 media: rc: per-protocol repeat period and minimum keyup timer
c421c62a4a08 media: rc: mce_kbd decoder: low timeout values cause double keydowns
539327608dbe media: rc: mce_kbd protocol encodes two scancodes
63039c29f7a4 media: rc: mce_kbd decoder: fix stuck keys
cb5bd0575c41 media: rc: mce_kbd decoder: remove superfluous call to input_sync
53a62800efb2 media: rc: mce_kbd decoder: fix race condition
91352b572786 media: rc: mceusb: IR of length 0 means IR timeout, not reset
877f1a7cee3f media: rc: mceusb: allow the timeout to be configurable
aec3eadfb642 media: mceusb: MCE_CMD_SETIRTIMEOUT cause strange behaviour on device
d4589935ebab media: mceusb: filter out bogus timing irdata of duration 0
0630efeee853 media: rc: ite-cir: lower timeout and extend allowed timeout range

Read the discussion here for details: [PATCH v2 0/7] Improve latency of IR decoding — Linux media

so long,

Hias

eventlircd is used to translate linux input events from remotes handled by the kernel into lirc events.

This is needed because Kodi can't cope with a bunch of linux input events, most well known being "KEY_OK". So if you use an IR or RF remote the OK button won't work unless you run eventlircd.

More details are in the wiki: Infrared Remotes [LibreELEC.wiki]

so long,

Hias

IMHO the big benefit of using Kodi is that I can use a single application for listening to my flacs, watch Netflix, play my DVDrips etc.

There may be different distributions / programs / systems that handle each of these tasks better, but then I'd need to switch between those, adapt to different user interfaces, manage each of them separately etc.

So, I'm not sure if yet another audio distribution (being it a stripped-down / specialized Kodi or something else) is such a good idea. Improving Kodi seems like a better idea to me. If you don't want video functionality you don't have to use it. But if you later decide otherwise it'll be right there for you.

so long,

Hias

IMHO the role of stripped down OSes is one of the most overrated things - even in embedded system design. Basically it has next to no impact on performance and the only thing you gain is a smaller sized install image - which isn't really important if you install the system on a 8-32GB SD card. Sure, it's relevant if you only have 1GB of embedded flash or even less, but eg in case of RPi this isn't really a thing to worry much about.

If you compare eg Raspbian Lite to LE you'll notice the Raspbian Lite install image is about 360MB compressed and LE is about 150MB. But, if you look closer you'll also see that Raspbian comes with about 54MB (uncompressed) of kernel modules, LE with about 19MB (again, uncompressed) of them. Yes, they take up space but they might come in handy when you need one of those.

Then comes the big question: busybox or full-fledged gnu tools. Well, busybox is small but the tools also don't offer the full functionality. That caught the piCoreFolks, busybox modprobe didn't support the "softdep" option. Busybox ash isn't bash so even nowadays where most people are (or should be) aware of the term "bashism" you may come across some script that doesn't work with a standard posix shell because it uses commands specific to bash. Recently we ran into the issue where busybox's mount didn't cope too well with systemd. And so on and so forth, the list is basically endless.

So, when you design an embedded system / appliance the more important question you should ask yourself is whether you are prepared to put a lot of effort into maintaining a stripped down OS or if it's better to use some other system (like Debian), and eg just tweak the kernel and/or config settings a bit and make sure you install the packages you want and don't install those you don't need.

As you might have guessed there's no easy answer to that and both approaches have their pros and cons. But,, performance-wise both solutions will be about on par, most CPU time and RAM will be used by the main application - be that Kodi or some node.js scripts.

so long,

Hias

Just remembered about another audio distro with a stripped-down base (though a different approach than LE uses), piCorePlayer: piCorePlayer

Not sure if that comes near your needs, never really used it, just helped the folks getting the Cirrus Logic Audio Card working a few months ago.

so long,

Hias

Concerning touchscreen: there's the Estouchy Skin for Kodi Kodi Community Forum - Estouchy - I have to admit I never tried it though as I don't have any touchscreens.

You can disable various main menu entries (like Movies, Videos, ...) in Kodi if you don't want/need them - just head to Settings -> Interface -> Skin -> Configure Skin...

If you want some extended functionality in Kodi you'll need to check if there's some addon readily available that suits your needs or create a feature request for Kodi if some core functionality needs to be extended.

LibreELEC is already quite stripped down but if it bothers you that some background processes like pulseaudio, eventlircd, ... are running and you don't want/need them you can simply disable them via "systemctl mask SERVICENAME". A while back ago I did that to repurpose a Wetek Play 1 running LE as a headless tvheadend server - I even disabled kodi as it'd consume a significant amount of CPU and memory when it just sat there being idle.

As all of these are just configuration changes you can easily check yourself if it brings you nearer to your goal. If you discover that's a viable way to go and you want that config "out of the box" then you could start thinking about creating an LE community build or fork that ships with these changes as default.

so long,

Hias

Have a look at the Yatse (and maybe Kore, haven't tried it since a while) apps. TV can stay off and you just browse through your music library and remotely control kodi from your tablet / phone. Works rather nicely IMO!

so long,

Hias

Technically the LCDproc service addon and the Kodi LCD addon are 2 separate things. You could configure the Kodi LCD addon to connect to an lcdproc instance running on another computer (I've used that to test things) or you could run lcdproc in LibreELEC and have some other program / addon (even on another computer) display info there.

If we automatically install the kodi LCD addon people might need to disable it if they want to use some other program / addon to show stuff on the display (not 100% sure what happens if 2 clients connect to an lcdproc instance at the same time). Probably a niche use case, but again something that needs to be kept in mind / documented.

so long,

Hias

Quote from CvH

4) Borgbackup - uses python pip, even perl looks interesting now

Python 3.4+, to be more specific

so long,

Hias

Quote from apokalypz

It looks like mainline has fixed the issue:

media: rc: meson-ir: add timeout on idle · torvalds/linux@8d7a77c · GitHub

They, fittingly, call these keypresses "ghost" keypresses. It looks to be caused by the hardware not generating a timeout after each keypress, so they added it in software.

My question is this:

Can we get this fix backported to our kernel in the official odroid C2 (and generic amlogic devices) builds?

The fix is already in the LE amlogic-3.14 tree, see these 2 PRs: fix in-kernel decoding with meson-ir by HiassofT · Pull Request #83 · LibreELEC/linux-amlogic · GitHub fix flush_timer by danielkucera · Pull Request #98 · LibreELEC/linux-amlogic · GitHub

LE 8.2.5 uses an older version of the 3.14 kernel without these fixes, but the current LE 9.0 development branch has these built in.

so long,

Hias

Support for non-NEC remotes, like RC6 MCE remotes, is rather lacking in the 8.2.x Amlogic tree, you might have more luck configuring your remote as a Xbox One remote and then using a rc_maps.cfg with "* * xbox_one" - the Xbox One remote uses the NEC protocol.

I fixed the kernel remote to support MCE and other remote handling in January, but these changes are only available in the 9.0 (preview) versions - this is why LE9.0 and CE9.0 preview builds work better than the 8.2 ones in this respect.

I'm not sure why Lirc sometimes doesn't work on 8.2, IMHO it should be fine (unless you have some "killall lircd" or similar commands in your autostart.sh). But then I'm not really experienced with Amlogic boxes and the old 3.14 kernel, my only contact with these so far was getting in-kernel / ir-keytable decoding working (which I did "blind", without actual hardware to test).

so long,

Hias

If you are using irsend it could be that you are hit by this lirc bug: LIRC / Tickets / #315 irsend / lircd hang when using repeats A proposed fix has been posted but it hasn't made it's way into lirc yet.

Do you also get the error when you don't use irsend?

I'm not familiar with usb-uirt so I won't rule out a bug in the uirt2-raw lirc driver, or it could also be a RPi USB issue (we saw plenty of those, also with serial usb devices). The checksum error certainly is odd.

Also check dmesg for USB related errors and run "vcgencmd get_throttled" (you should get "0x0") to check if the power supply is OK.

so long,

Hias

hmm, only rc-core is loaded but no there's no sign of a rc0 device being registered - and also no error message. Maybe some module is missing?

fasigno could you grab dmesg and lsmod form a working Arch installation, maybe that'll give us some hints.

so long,

Hias

Quote from Legitwarrior

I am using exactly the files boot2k3 was posting in #229. In Coreelec 8.90.1 it works in nightly-20150428 not.

When using nightly ir-keytable is saying this for example:

Code

LibreELEC:~ # ir-keytable -t
Testing events. Please, press CTRL-C to abort.
206.066939: event type EV_MSC(0x04): scancode = 0x9f43
206.066939: event type EV_KEY(0x01) key_down: KEY_UP(0x0067)
206.066939: event type EV_SYN(0x00).
206.078253: event type EV_MSC(0x04): scancode = 0x9f43
206.078253: event type EV_SYN(0x00).
206.270042: event type EV_MSC(0x04): scancode = 0x9f43
206.270042: event type EV_SYN(0x00).
206.520025: event type EV_KEY(0x01) key_up: KEY_UP(0x0067)
206.520025: event type EV_SYN(0x00).
220.720056: event type EV_MSC(0x04): scancode = 0x9f0a
220.720056: event type EV_KEY(0x01) key_down: KEY_DOWN(0x006c)
220.720056: event type EV_SYN(0x00).
220.970109: event type EV_KEY(0x01) key_up: KEY_DOWN(0x006c)
220.970109: event type EV_SYN(0x00).

Display More

Thanks for testing!

I was just told that there's currently an Amlogic specific bug in Kodi which prevents lirc events (which is used by default in LE for remote handling) from working.

A workaround for that issue was PRed here: [aml]Register lirc in AML after #13761 by gelotus · Pull Request #13798 · xbmc/xbmc · GitHub - but it looks like it needs a bit of rework.

It'll probably take a couple more days until this issue is fixed in Kodi, then a bit until Kodi is updated in LE. Until that's resolved IR remotes will stay broken in nightly Amlogic LE builds.

so long,

Hias