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.
You're better off posting Q's to the RPi developers directly via their forum. While we work with them and support them with a ton of testing effort, the actual development of RPi drivers/ffmpeg is done by RPi Foundation staff.
nuive if the upstream application has a load of problem hardcoded paths; fix the upstream application
Sometimes the "hard" option is actually the easier and better option.
I'm impressed with what's been achieved. The legacy code was an unholy pile of .... to start from
In LE if you create /storage/.config/firmware/ and place the firmware .bin and .cfg files there, they will be overlaid onto /lib/firmware at boot time. I've done that but it makes no difference to load. Here's dmesg: http://ix.io/3NrC and ssv6051-wifi.cfg content: http://ix.io/3NrD
NB: If having samples of the chipset in other SoCs (e.g. Amlogic) would help with the upstreaming effort LE will be happy to fund them.
EDIT .. I noticed this in dmesg:
TX3:~ # dmesg | grep meson-gx-mmc
[ 0.373380] meson-gx-mmc d0072000.mmc: Got CD GPIO
[ 0.376230] meson-gx-mmc d0074000.mmc: allocated mmc-pwrseq
[ 1.164926] meson-gx-mmc d0070000.mmc: allocated mmc-pwrseq
[ 11.361455] meson-gx-mmc d0070000.mmc: DMA addr 0x000080001218b430+8 overflow (mask ffffffff, bus limit 0).
[ 11.364105] meson-gx-mmc d0070000.mmc: dma_map_sg failedHave a look at the recent history of changes to drivers/mmc/host/meson-gx-mmc.c in the kernel .. I suspect the issue has to do with memory use and alignment.
I also rebuilt the kernel all the way back to 5.10 and MPEG has been broken since 5.10 (December 2020)
Did you bisect to a breaking commit? .. just that's how far back you've looked? - MPEG2 was the first codec upstreamed (H264 and VP9 were added later) so while it's had less focus it should also work. If 'we' can find the breaking commit it would be a good lead for investigating why the codec is currently broken.
Removing content from "vdec_platform.c" is the correct/easiest way to disable it.
--- a/xbmc/windowing/gbm/WinSystemGbmGLESContext.cpp
+++ b/xbmc/windowing/gbm/WinSystemGbmGLESContext.cpp
@@ -145,7 +145,7 @@ void CWinSystemGbmGLESContext::PresentRender(bool rendered, bool videoLayer)
}
else
{
- KODI::TIME::Sleep(10);
+ KODI::TIME::Sleep(40);
}
}^ If someone is compiling their own images and understands how to track CPU usage, that might be of interest.
Interesting. One of the contributors is ilmich and the other is known(ish) to me via Armbian. I was able to compile the driver and trigger probing on a Tanix TX3-mini with a small device-tree tweak to the SDIO node but the driver didn't load: http://ix.io/3Noj - it probably needs some firmware/config stuff adding - it's not clear what though.
NB: Existence of the driver is one thing. LE would want to see it being upstreamed to the kernel before we'd consider picking/backporting the upstream submitted patches to images. Community images are something different.
Here's an example of another panel device listed in that yaml file being added to a device-tree:
How well that transcribes to your (different) panel .. I can't say. I'd be asking the vendor/manufacturer for examples. The RPi forms are also probably a better source for help on that kind of thing than here - our expertise rather stops at "connect HDMI cable"