I have two 3.5" 4TB hard disks, plugged into an external drive dock ... and used the Storage Spaces utility to combine the two drives into an 8TB volume (setting up RAID 1)
To be pedantic: If you combine 2x 4TB drives into an 8TB volume you have RAID0 (striping) not RAID1 (mirroring) so data is "at risk" under any OS because RAID0 provides zero redundancy.
Any ideas on how I fix this and get my IVACY subscription running on LibreELEC?
LE10/LE11 images use Python 3.x, the last release to use Python 2.x was LE9.2. So options are:
a) Persuade <insert name of whatever VPN service> to provide a Python3 compatible version of their add-on
b) Find and extract the connection details and credentials/certs used from the add-on and use them with e.g. Zomboided's add-on.
Option A has no further action from us (the add-on, the service, and everything related to it is someone else's problem). If you go for Option B redirect future Q's to Zomboided's add-on support thread.
You probably need to test the specific (not Open) SUSE images provided for these devices as those are more likely to have some tweaked power management code. If not, you're needing to read up on ACPI debugging and/or sending emails to the Linux kernel mailing list asking for help on how to debug it. Understanding power states is one of those less-easily understood bit of the kernel .. I don't have any docs I can point you to.
The Kodi shows that there is no HDMI source detected. You can try appending "HDMI-A-1:1920x1080M@60" to boot params (same as the 'ssh') but this will only give you limited resolutions. You an also try an LE11 nightly: https://test.libreelec.tv/11.0/RPi/RPi4/
jim_p As per the wiki, AMLGX images are for 64-bit hardware (S905 and up) and AMLMX is for Meson 8 (S802/S805/S182) although S812 is not functioning. There hasn't been much upstream work done on the Meson 8 codebase in the last year as the sole developer (Martin B) has been keeping himself busy with other things.
The last AMLMX pre-pre-Alpha test image I created was in Feb '22: https://chewitt.libreelec.tv/testing/ - It did boot on an Odroid C1 but I can't speak for anything else.
LE provides all core downloads via 3rd party mirror servers: https://releases.libreelec.tv/mirrorstats
It is possible for some users to download direct of our infrastructure, but those downloads are a minority and do not use enough bandwidth to concern or cause expense to the project. So we don't really care if you set rate limits or run at full speed. The other 99.99% of users will be downloading from a mirror; so all the bandwidth consumed is someone else's - donated for free for that purpose.
Almost all open-source projects do some variant of the same thing (hosting on GitHub, via mirrors, via some major repo, etc.) so while it's nice to be a good netizen, you're probably over-thinking this issue.
NB: Userspace shutdown scripts are not the problem or solution here. The issue (and any resolution) will be in lower-level code.
^ I'll quote myself again.
I'd like to run the latest LibreELEC image that used the vendor GPU drivers. Or is anyone aware of LE9.x images usable for the Radxa Zero ? They seem to have all disappeared in the end.
LE (or me) has never created an image using vendor GPU drivers for Radxa Zero. We switched to mesa/panfrost before support for the Zero was added upstream.
frakkin64 I'm not sure that bug would be found in LE images since we aren't using EFI boot code paths in u-boot? - I can see how it would show up with dekstop distros though.
I'm curious how to use widevine with pure aarch64 kernel and system.
Google ships 64-bit versions of Widevine for x86_64, and 32-bit versions for ARM. There are no known sources for 64-bit ARM libs.
Comparisons with another Linux OS (Ubuntu, Fedora, etc.) are relevant - if it works fine there, there's some level of proof that the hardware and firmware combo can play nice with Linux. Proof that it runs great under Windows isn't particularly insightful since a) You'd expect a product built to run Windows to play nice with Windows, b) The Windows power architecture is completely different to Linux.
Issues with Shutdown/Restart are normally related to BIOS/firwmare versions (supporting ACPI states correctly) and power/config settings in the BIOS/firmware (what's needed for Windows isn't necessarily what's needed for Linux). And some hardware is just broken and there's not much we can do about it. You might want to start by telling us what hardware you have?
The OVA image we spawn from Generic images is designed for vmware to make booting in a Desktop environment simple, and with the sole purpose of supporting development of project GUI items like the settings add-on. Any other kind of platform or use-case is deliberately "not officially supported" to keep project maintenance simple. Over time the number of other environments it might work in has probably grown, but we do not test that image much, have no intention to start testing it much, so anything that happens to work is accidental.
In all cases LE needs to boot with a supported GPU, which is either real hardware mapped for our use, or one of the working virtual GPUs in the kernel. The Generic kernel defconfig is probably missing drivers for whatever GPU that proxmox uses; or the GPU that is there doesn't support the OpenGL video pipeline that Kodi requires.
Glad that you got it working 
If you're only going to be playing SD media I'd suggest that you disable hardware decoding in Kodi playback settings. The upstream decoding drivers are fine with H264 but aren't perfect with older codecs or HEVC. However the S905X chip never runs particularly hot and small filesize media isn't too challenging to software decode, which will avoid hardware decoding glitches.
Suggestion:
Connect directly to the (working) TV, dump the EDID and set this for use, reconnect to the AVR, than hope it all still works.
info <general>: Found resolution 1280x720 with 1280x720 @ 50.000000 Hz
debug <general>: CGBMUtils::CreateSurface - created surface with size 1280x720Kodi is started and apart from there being only a single resolution ^ available (720p@50) everything looks normal. I guess the head-unit is expecting some other resolution as input? - so you may need to force the CVBS output to something else using kernel boot params.
e.g. something like "video=TV-1:1920x1080M@60" added to params in /flash/extlinux/extlinux.conf
NB: I'm not 100% sure of the connector name (TV-1) or what resolutions are possible.
Hardware decoding on a modern kernel codebase requires patched kernel + patched ffmpeg. LE sources are currently as good as it gets:
The manjaro folks are tracking patches fairly well to result in a useable 'current' distro. Performance and feature completeness on the vendor kernel (used by CE) is better, but compatibility between old vendor kernels and the rest of a modern distro codebase can be a challenge.
The main negative I've seen in the LE/AMLGX image with LePotato is 100-BaseT Ethernet (common to all S905X boards). If trying to play large ISO rips Kodi often warns about slow sources etc. - S912 devices are normally better since most have Gigabit NICs.
NB: CE is run as a separate project so report any issue to their forums, we don't track their images at all.
Two suggestions:
a) Drop the kernel.img and SYSTEM files from dtech images into /storage/.update/ and reboot to udpate to 9.2.8 which might behave better than Ye Olde 9.0.2 image now.
b) Have a play with https://chewitt.libreelec.tv/testing/LibreE…lepotato.img.gz which is using K20rc1 and modern uboot and Linux. Hardware decoding isn't perfect and there are some features on the long-term to-do list still, but as long as your media requirements aren't too challenging it's quite usable.