dd if=/path/to/LE/image.img of=/dev/diskX .. where diskX is the SD card device.
You can try this too https://www.dropbox.com/s/s4fj9ebj8278….macOS.dmg?dl=0 .. but I think it only works for me because I have the code signing certs installed on my laptop.
RPi4 2GB and up .. because it's a simple playback device and the Foundation provides the best vendor support of all hardware we run on.
Is the ! character the first character in the passphrase, or somewhere later?
Any ideas?
You either need to implement support for /storage/.config/xorg.conf.d/ mapping to /usr/share/X11/xorg.conf.d .. or (easier) patch the files that we get from xf86-input-libinput package with a custom image or (easiest) overwrite them with a file in projects/Generic/filesystem/use/share/X11/xorg.conf.d with whatever you like. All of the above require a custom image.
Just wondering if you're trying to use a passphrase that's too long.
Add-ons > Add-on Browser > My Add-ons > Information Providers > (pick category) > (disable everything apart from local info)
Rinse/repeat for other data types as needed.
Even if the GUI does not come up, the rest of the OS is probably running fine. Cold boot the box, then SSH in and run "journalctl | paste" and share the URL so we can see what is detected and what boot errors might be present in the system log/journal.
LE10/11 have deinterlacing support, but using all-new driver code (the entire video pipeline is different) so it's completely possible to have different results. Can you create some sample files to share so we developers can have a look?
Ping popcornmix ^
What exactly is your definition of a "complex password" ???
Probably a issue with an addon, I had to remove pvr.hts in ~/.kodi/addons/ . You could remove it before you update. When you're in safe mode you could remove it from /storage/.kodi.FAILED and reboot. In the log you could see which addon fails to start.
Known issue due to gnutls changes; remove the add-on files and zip from the package cache then update and reinstall the add-on (using a new build of the add-on).
MT7601U has been enabled in kernel config since pre-LE days (OE) and should just work as I remember adding it. Most Atheros/Railtek chips are upstream and also supported, but perhaps are missing firmware. Occasionally the USB device IDs aren't mapped in the driver (hence it doesn't load) but that's not common on older chipsets as the IDs have mostly been added upstream long ago.
Do the USB ports work if you connect a keyboard (checking for dead ports)?
If yes, run "dmesg | paste" after a clean boot and connecting devices to USB ports, so we can see what the kernel logs - if anything - and share the URL(s) generated.
I'm not that familiar with RK images, but I'm wondering if the CPU serial is exposed? .. in which case we could adapt the process we use for Amlogic devices to force a persistent MAC address:
LE does not support USB tethering. Appreciate you said 'no' to it, but WiFi would be the easiest option.
Turn everything off and unplug all the HDMI cables. Go make a cup of tea. Come back, reconnect the cables and power everything on. Has the problem gone away? .. as random as that sounds, some variant of "turn it all off/on again" often works to clear CEC weirdness.
The i2s encoder (which packs audio frames for HDMI) supports 16/24/32-bit output as can be seen here: https://github.com/torvalds/linux…r-i2s.c#L71-L76
However, it looks like 24 is padded to 32, see: https://github.com/torvalds/linux…r-i2s.c#L48-L59
And it outputs 2-channel or 8-channel, see: https://github.com/torvalds/linux…r-i2s.c#L61-L69
So I would make an educated guess that the hardware supports 24/32 bit output over 2-channels, but only 16-bit in 8-channel mode. This is also hinted in this comment in the code: https://github.com/torvalds/linux…oder-i2s.c#L118
That also aligns with the OSMC forum post, and this alsa conf from the legacy kernel which ensures HDMI is using 16-bit LE packing: https://github.com/LibreELEC/Libr…8AUDIO.conf#L39
So I'm right (24-bit is supported) and so is the other guy (HDMI is 16-bit). Enjoy 
LE11 uses upstream (Linux 5.19.y) kernels so there is 0% driver code in-common with the legacy image you found. AFAIK all S905 and later hardware supports 24-bit output (and you claim the image you found does, which would support that). Go test.
Install the older 9.0 image (last official emmc install image for Hub) and then update to 9.2.8
I'm not aware of anything in the upstream codebase that should prevent 24-bit audio being used, but it's not something I can easily validate, so you will need to do some testing. LE11 test images: https://test.libreelec.tv/11.0/Amlogic/box/
There is partial support for S905X3 devices; the OS is stable but hardware decoding is an issue. If you only need 1080p output you can disable hardware decoding and everything works. If you want 4K, not happening. No support for S905X4 at the current time.
