Are you guys on berryboot ?
LE has a long history of issues with BerryBoot which all originate in BB providing a different kernel build/config to what LE expects. Our advice is to avoid BB .. particularly if you want support from staff in these forums.
I deleted all Matrix images from my share 3-4 months ago when I switched to Nexus and renamed the thread. Even if you find a Matrix image it will perform worse and be less featured than the current Nexus images.
what can i do?
Share system log files?
do you see the vendor-specific ARM-based stuff as the 'future' of Kodi?
Team Kodi has been pursuing a "standards" based approach since 2016 and it's the reason Android now works very well. Linux is iinherently more complicated but a lot of the kernel frameworks are now in place and stable. Supporting older and current hardware has challenges as it means rework to existing codebases and commercial interests rarely fund work on old chips. However Google forcing Android device vendors to get ever-closer to upstream means future chip generations will increasingly have support written around the stable APIs and convergence will come. ARM devices are increasingly performant, and Intel stuff is still available (at a price) for anyone needing more.
Yes, but I only found this on chewitt testing site: LibreELEC-AMLGX.arm-10.85.0-odroid-n2.img.gz
This is a Nexus Kodi 20 Image.
I search for the same but Kodi 19.
I moved the nightly codebase to Nexus which is perfectly stable for experimental N2 images which have issues with hardware decode (except for H264 which works fine). so you would need to disable it and stick to 1080p media. There are no Matrix images for some time and no plans to go back and make any.
NB: I block PM because every self-entitled owner of a $20 Amlogic box seems to think I'm their personal support channel 
Amlogic started upstreaming core board support to the mainline kernel, but it's a slow process so I wouldn't expect LE support anytime soon.
Found it emmctool but device not supported - any way to do force installation to nand?
There are no secret override switches/options and in my version of English "not supported" means it is not supported.
Could someone confirm the problem, at least?
63-character passwords are pointless. Anything over 20-characters is computationally infeasible to brute-force and a serious attempt to crack your network (if you're someone worth targetting) will either focus on a protocol or implementation flaw, or https://xkcd.com/538/
Regardless, it's a known issue and the workaround is to use connmanctl over SSH to join the network.
The x86_64 world is a little different to the ARM world. Intel/AMD standardised their hardware decoders around VAAPI so Kodi can call ffmpeg in a consistent way regardless of each, although at some point capabilities need to reflect which GPU/card and what the TV/panel supports. It all works reasonably well though advanced things like tonemapping still need to be plumbed in. Even nVidia finallly caved and added support for GBM/mesa to their latest drivers; and although Kodi does not support NVDEC (needed) someone wrote an NVDEC > VAAPI ship and we have a proof of concept implementation; although you need to run under Wayland which doesn't support fun stuff like "adjust-refresh" by design so it's not quite the solution nVidia users need (better than "no support" though)..
The ARM world is domainated by ARM Mali GPUs (well supported with FOSS drivers now) with separate vendor-specific decoders. These have a mix of "stateless" and "stateful" types under the V4L2 banner. The stateless V4L2 "requests" uAPI is stable and supports a good range of codecs upstream; it's still up to individual drivers to support them. The stateful "mem2mem" side is not declared stable yet, and with the dependency on vendor firmware blobs is generally a bit futher behind. There is a lot of collaboration happening on testing and upstreaming to the kernel - and LE is heavly involved in that (Kodi is a good test app).
On the userspace side most of the current activity on ffmpeg is focussed on making everything work. The process of usptreaming is looming on the horizon but it's still something to come. Again there's quite a bit of collaboration happening on this and we're involved.
Vulkan is an alternative to things like OpenGL/OpenGLES .. so "standards" .. https://xkcd.com/927/
LE has had millions of installations with the current .img format and MBR arrangement. It is not at fault. It all works when you boot LE as intended with the SD card inserted directly into the board. It stops working when you add your dual-card gadget. Ergo.. it's the dual-card gadget. I'm not sure what the issue is, but I'm out of ideas.
find / -name "*.nfo" -exec sed -i 's|http://imdb|https://imdb|g' {} \;^ Something like that might work. You probably need to grep the possible values for the URLs from the .nfo files first so the sed find/replace is precise and doesn't have unintended results.
The "mini" version normally has S905W and SSV6051P inside, but that's assuming you get a box made by Tanix themselves and not one of the bazillion clones of their boxes
I have the BT remote shipped by O2.cz for their 4K IPTV box (which happens to be an Amlogic device I got samples for). I'm not sure it's one that you can buy or I would "recommend" to people.
I picked up a "Tanix TX3 mini" S905W box for $22 including shipping in 2018. Even if Covid has doubled the cost since it's still a bargain if it helps to get another rouge driver upstream in the long-term (there's no expectations of rapid fixes).
boot=/dev/sdd1 disk=/dev/sdd2 quiet ssh^ last roll of the dice, this forces the boot/disk params to use the raw disk (sd) card device. If that doesn't work I'm 
UPDATE: I've corrected the ^ above, the card reader is changing the presentation of the block device to look like a USB drive, not an SD card which changes some of the /dev/device numbering.
In LE11 (nightly) images (and maybe LE10 .. I can't guarantee though) allow you to configure persistent journal logs. It's intended for debugging but in your case will simply increase the time range there is data for. You will be able to see boot and can see login/logout activities in the journal, but another issue to contend with on RPi is the lack of RTC which means the clock on boot starts from glibc release date not actual time; until the network is up an ntp corrects. You can solve that by adding an RTC chip.
Another approach would be to configure Syslog export of data and track activity in a logger/SIEM tool. You will still need a solution for RTC issues, but when you see gaps in telemetry the Pi was off, and when it's on you get data.
The systemd journal includes OS information and /storage/.kodi/temp/kodi.log contains activities by Kodi. Activities with the application are not necessariily representative of activities of a user though, so you have to interpret the logs.
The single thing that will make the most difference to a nice experience in LE (and not specific to RPi) is a good remote that doesn't have lag in key presses. I have lots of 'stuttery' cheap remotes from Android TV boxes and a nice BT remote that responds like a keyboard with a nice fluid scrolling experience. RPi4 will be 'faster' with overclocking but it's 'fast enough' in stock configuration.