I didn't use drm-tip, I just picked the single fix patch from GitHub and dropped it and the HDMI (alsa) reorder patch in packages/linux/patches and rebuilt the image; along with a general bump to RPi ffmpeg 6.1.1 sources which is in my Amlogic dev branch.
Using actual drm-tip probably isn't too hard, but you'll probably need to pull sources from GitHub or GitLab using a githash instead of using a release number. See how the Amlogic sources are handled for Linux; it'll be similar.
I have little experience with playlists, but have you tried the node editor? Nodes are things like "recently added" and are constructed from content in the library using filters. The add-on is in the Kodi repo.
NB: You have PM regarding the Kodi forum account.
LE is largely packaged into two large compressed files (KERNEL and SYSTEM). If anything corrupts them, they cannot decompress and LE won't boot, whereas with a more conventionally packaged OS with thousands of files scattered over the disk; if you corrupt a couple of files it will usually manage to boot and you might not notice the things that failed due to the corruption.
Cards with corrupted filesystems can be fixed with 'fsck' from the USB stick install or another distro. If you can fix the filesystem you can boot from the card again, and/or copy data off the card to make a backup. Cards can also fail with dead memory breaking the filesystems. This cannot be fixed with fsck, so if fsck fails to repair the card or hangs .. you lost data (and learned why taking backups is a good idea) and you need to start over with a new card (or remain on the USB stick).
Boot the RPi4 from USB, then connect the SD card. Then SSH into the RPi4 from Windows, unmount the filesystems on the SD card so they are not mounted (in use) and filesystem check (fsck) them:
umount /dev/mmcblk0p1
umount /dev/mmcblk0p2
fsck -y /dev/mmbclk0p1
fsck -y /dev/mmcblk0p2See how that goes.
ARM SoC images like RPi5 intentionally have no "installer" function and there's no tooling to create boot media from inside the OS (as there's not really a requirement to do that) but it's possible:
cd /storage
wget https://releases.libreelec.tv/LibreELEC-RPi5.aarch64-12.0.0.img.gz
umount /dev/mmcblk0p1 <= Unmount existing partitions
gunzip -c LibreELEC-RPi5.aarch64-12.0.0.img.gz | dd of=/dev/mmcblk0 bs=1M
umount /dev/mmcblk0p1
umount /dev/mmcblk0p2
shutdownThis sequence ^ assumes the SD card is pre-formatted with a single partition (which is usually the case). LE auto-mounts the default partition(s) so you must unmount them before writing data to the card.
After running 'shutdown' remove the USB, leave the SD in, and power on again. If all went well it should boot from the card.
This just tells me the issue reported in the other thread is either PEBKAC or something is weird with your board.
I've you've created LE images before you understand the build process. Just create a Generic-Legacy image so everything compiles normally and sources are downloaded. Then change the PKG_VERSION in packages/graphics/mesa/package.mk to reference the older release (set PKG_SHA256="" so it's not used) and respin the image. I'd expect mesa to simply rebuild with the older version as its compile/build process is stable (so probably hasn't changed). If that works, go test.
Do I simply use the LibreELEC SD creator, select the img.gz file, write to the SD, then put into the device and boot? Or do I need to make changes after I have written the image?
Correct. No changes needed. All I can say is, current images boot/run/work here for me, and project stats (active installs) show that Odroid C2 boards are the most-used device with the AMLGX image. UART log showing early boot is the way forwards, as it will show exactly what is or isn't happening. NB: The same image boots from SD or eMMC.
No idea what's the issue, but leave it for a while until old add-ons are replaced by new ones and it will sort itself out. It somehow that doesn't work, run "systemctl stop kodi && rm -rf /storage/.kodi/addons/* && systemctl start kodi" to clear the binaries (but not the add-on configs and settings which are stored separately in /storage/.kodi/userdata/addon_data) then reinstall the add-ons again and you'll be up and running quickly. It's no more than a 5 mins job unless you over-think it.
CE have been trying to make 3D work properly for years (copying the same OSMC patches). If you're one of those people who thinks in code; good luck with the endeavour. If you're not (and people who show up here looking for patches usualy aren't) I'd skip ahead to the bit where you get a cheap RPi3 (not RPi4) and waste time watching movies instead 
This image contains the patch from drm-tip (which was no issue to backport onto the LE kernel sources) and the channel allocation reorder patch that was suggested with RPi recently: https://chewitt.libreelec.tv/testing/LibreE…_64-12.80.0.tar
Let me know if the issue is resolved and/or whether the 4.0 > 5.1 workaround is required?
I plug power in, the red light turns on, no blue light, and after a few seconds the network jack lights start to blink.
That comment ^ suggests the board is booting, because network LEDs blink because code tells them to, not magic. If you add "ssh" to boot params in extlinux.conf it will force the SSH daemon to start, allowing you to login over the network with an Ethernet cable connected to see what's happening. If you add "video=HDMI-A-1:1920x1080M@60" to boot params it will force the kernel to output 1080@60 on the HDMI connector, in case there's something odd with HDMI cables and the monitor. It's not a cure-all for an HDMI issue, but you'll have a screen to look at, maybe. Perhaps connect to a proper TV instead of a monitor?
FWIW, I dug out my C2 board here and it boots fine using the image in my test share.
The mainline u-boot default boot method is extlinux.conf. Petitboot doesn't support extlinux.conf and HK devs have resisted the idea of adding support for some reason (more customers are forced to run BSP based images which keeps them inside the HK ecosystem perhaps?). Fortunately this dumbfcuk decision is easily solved by flicking the SPI boot switch to the right so Petitboot (which resides in SPI) is completely removed from the equation. Then LE boots fine from SD/USB and eMMC.
Those are the correct images (so u-boot is included). You cannot update from LE9.x using those files as the image name is not the same as the legacy one; and if you manually override/workaround that it will fail in later steps because I intentionally changed the boot filenames to force people into a clean install: to avoid the accumulated cruft from old installs, and prevent add-on issues that cause problems with the Python2 > Python3 change since Kodi 19.
See if https://chewitt.libreelec.tv/testing/LibreE…droid-c2.img.gz boots for you (it does for me). Please ensure the boot partition of the SD card is readable, i.e. prove you have correctly written the SD card and not just put the file on an SD card or direct-wrote the compressed image to the hardware (needs to be uncompressed). Do not rename files in the root folder of the SD card as done with some legacy images else it will break boot.
I don't have any links to UART guides: As a rule people with UART cables have figured out how to use them. If you have one? there's probably some instructions on the Hardkernel wiki.
There are no objections to it being submitted to the LE repo. The alternative will be to create an "argon40" repo for the add-on (ab)using GitHub free hosting and then have people install the add-on from that repo. The LE repo is easier for users since there's nothing extra to install, but an independent argon40 repo will probably be easier for the maintainer as fixes can be pushed on their own schedule. If there's any intent to support install on RaspiOS too, the independent repo is the right direction.
I added the GitBook app link to the wiki homepage: If you think there is documentation missing .. feel free to add it.
I've recently tested LE12 images booting from SD card and an eMMC module without problems. Are you using the "odroid-c2" image with upstream u-boot, or the "box" image? .. the latter has no u-boot so won't boot the board. If that's not the issue I'll need to see UART logs. NB: LE proactively disables the flashing blue LED activity indicator, but it will still flash at the start of boot until the disable script fires and stops it, which is usually around the time Kodi starts.
Would it affect importing/updating a large library or is that mostly network bound?
If you added content it makes negligible difference as most time is spent querying internet sources. If you didn't then it will complete faster as the small file read/write is improved. Overall, as said before, you're not missing anything.
