make[1]: Leaving directory '/home/openkd/CoreELEC/build.CoreELEC-S905.arm-9.0-devel/openssl-1.0.2o/.i686-linux-gnu'
"i686-linux-gnu" means you are trying to build on a 32-bit system which is not supported - your build host has to be 64bit.
And you seem to try building CoreELEC, not LibreELEC. So please post your question(s) in the CoreELEC forum https://coreelec.org/forums/
so long,
Hias
You can use the Zoom setting to get rid of encoded black bars. See Video playback - Official Kodi Wiki
so long,
Hias
You can see what i have changed from the git checkout in my release posts. The 2 you want to look are #26 and #29. They are both running fine in short test without crashing kodi.
Thanks a lot for the info! Glad you got it working and that there doesn't seem to be an issue with gcc 8.1.
so long,
Hias
Yes. df52423 is the LE master tree from 2 days ago (just checked).
Do these builds contain the exact same set of patches, as the working gcc 7.3 build and do they crash kodi or not?
so long,
Hias
A fresh full build of df52423 with the changes from the quote is working right now.
Thanks for testing!
Have you tested the same set of patches on top of LE master tree as well?
If not, testing that or on top of the gcc 8-1 bump commit (01391bb7db) would give some hint if the crashes are related to gcc 8.1 or not.
so long,
Hias
Interesting, it's crashing in python. No idea why that's happening but 2 educated guesses:
sky42 could you test if a plain LE master build from commit bfd442ae06 also crashes? That's the commit before the gcc bump from 7.3 to 8.1. We had an odd issue with the Netflix addon after the gcc bump so it would be good to know if the gcc bump caused other side effects we are not aware of.
Another thing to try would be bumping kodi from 593949a to 002ec67a82. That's the version I've been running the last few days and I had no issues with it on RPi2.
so long,
Hias
Instead of using userspace Lircd it might be better to use the more modern in-kernel / ir-keytable configuration - read this wiki page for details: Infrared Remotes [LibreELEC.wiki]
If you do this it's best to disable Lirc in LibreELEC settings and rename (or remove) your .config/lircd.conf file and other lirc-related configurations so they don't get in the way of ir-keytable configuration.
so long,
Hias
Thanks a lot for the feedback!
I'm still a bit puzzled why gpio-ir works better, but then I'm glad it does and I hope it stays this way.
so long,
Hias
Ah, very interesting - I had expected that lirc-rpi and gpio-ir performance would be about the same.
Out of curiosity: are you still using Lirc with gpio-ir or have you switched to ir-keytable/in-kernel decoding?
so long,
Hias
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 rangeRead 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