If you would try, you'd be able to replicate the issue! Important: only after ungraceful shutdown! That's why it seems random to many users. It is not!
I have tried, with an RPi4, and lots of ungraceful shutdowns. I managed to corrupt something in Kodi one time, but I don't have any issues connecting to WiFi with the board in the same room as the router (1.5m distance) or in the next room (2m distance, but walls 50cm thick and full of steel rebar). I simply do not see the issue.
Can someone please suggest what I can do to resolve the above and get a HDMI signal?
The 'getedid' script can be used to workaround scenarios where the TV is powered on after the RPi board. It does not perform any other magic to make connections work. There is normally no need to use it, and it can complicate troubleshooting.
Start over with a fresh/clean SD card to remove getedid changes and because most of what's added to config.txt and cmdline.txt is no longer supported or incorrect.
The video= param will force the kernel DRM connector state to 1080p@60 to avoid issues with 4K modes the TV (or cheap cables) don't like. Does that solve the problem?
NB: CEC control will only work on the HDMI-A-0 connector nearest the PSU, it is not supported on HDMI-A-1.
It's a bug in iwd and/or the underlying broadcom driver. It doesn't have to do with signal strength or WPA mode as others suggested.
Unless you can prove it, this is opinion not fact.
pcie_aspm=off
There are numerous reports of PCIe issues on kernel mailing lists for Rockchip and Amlogic hardware due to ASPM changes merged for Linux 6.18 that are now surfacing in rc1/rc2 tests. On those platforms earlier kernels don't see the problems (and LE12.2 is using Linux 6.16.y) but I'm wondering if x86_64 is somehow different ..
The Kodi GUI won't show until the 'wait for network' timeout is reached and date/time will be wrong as NTP didn't correct it, but Kodi should still run without a network.
Lots of RK boards ship with some kind of older/vendor u-boot installed in SPI flash and these might not support our extlinux.conf boot files. The solution to that is erasing SPI flash so the mainline u-boot on the SD card is found/used instead.
LE9.0 used the Rockchip Linux 4.4 vendor kernel and we've since switched to the upstream kernel.
I've added an item to my list to investigate further but the latest vendor kernel (Linux 6.6 + mountains of patches) lags so far behind the upstream kernel (Linux 6.18) the differences are huge and playing "spot the difference" isn't fruitful, and that's before you factor in the general impenetrable-ness of kernel audio things.
In short, no promises.
I'm new to the world of Rockchip and unaware of past changes and workings, but PT is not working with any of the newer boards I have and unhiding the option via appliance.xml doesn't achieve anything.
For my knowledge, was the previous version an official LE release or a homebrew community image? .. and what version?
I have no issues booting a 5B from SD or eMMC module 
AFAICT neither log shows anything unusual
I would suggest using the AMLGX .tar file in my testing share as this is running a newer kernel (6.17.4 not 6.16-rc3) and the newer Kodi version also has bugfixes. If you're going to use the TX3 device tree you should stop/disable/mask 'display.service' as this is started to drive the VFD display which your box doesn't have.
Nothing obvious stands out to me in the log, but I'd start with an update to the latest 12.2 nightly on the test server and see if that resolves anything. There are some Kodi fixes included since K21.2.
Always share the whole log (and system log) else you're missing a ton of useful info. Just run "pastekodi" and share the URL.
No need for 4GB or 8GB unless you plan to run other services in the background, 2GB is enough for playback.
LE mounts the second partition on the SD card as /storage and uses this for persistent data, e.g. Kodi saves to /storage/.kodi - the rest of the filesystem is decompressed from the SYSTEM file on boot and is read-only so it's hard to mess things up.
See https://wiki.libreelec.tv/configuration/…ration-advanced for instructions on creating and configuring a custom IR keymap. The remote will use the rc6 protocol so there might be existing keymaps that work, but it's normally quicker to transcribe one from scratch than test all the existing ones trying to find the one that exactly matches (there are lots of them).
It's impossible to guess what might cause Kodi to get stuck on the logo without seeing log files. If there is an issue in the OS it might be visible from the UART output. If there's something in Kodi .. you can enable persistent logging via the LE settings add-on and then check the logs (or look for crash logs) on the next clean boot.
CE and Armbian should be able to boot using the same u-boot, but their boot files are differently named, e.g. CE uses dtb.img and kernel.img so you might need to rename their files to match LE conventions. Updates would also not work, although GXL devices are no longer supported yb CE so there will be no updates. Armbian will be different again. I'm not sure what changes bumerc has hard-coded in u-boot, but as long as you can boot to the u-boot console via the UART cable changing the scripts stored in the u-boot environment will always be possible.
Kodi does not support downgrades so place the .img.gz file in /storage/.update/ then stop Kodi and remove /storage/.kodi so that on reboot after update it starts with a clean Kodi config.
I would stick with the LE13 image though, it won't be less reliable than LE12.2.
"Reliable" and "Runs Amlogic vendor kernel" should never be used in the same sentence.
Your nVidia GPU card has Linux drivers that either require Kodi to run under Xorg which doesn't support HDR let-alone DV, or GBM/Wayland which supports HDR, but doesn't support DV, and LE doesn't support due to the lack of refresh-rate changing support for optimal playback. Our general advice for the last decade is to avoid purchases of nVidia hardware as future support in LE is not guaranteed. The exception is the nVidia shield which is still the Android reference implementation for Kodi. I understand that it supports DV, whatever that means. I hear the OSMC vero5 box is good too. I can't speak for what CE claims this week/month/ever.
N2/N2+ use DDR4 while N2L uses LPDDR4 so it probably needs a dedicated image. I've never added one as the omission of onboard Ethernet means few people are likely to use one. It's simple to build though. See if this boots?
https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.aarch64-12.90.1-odroid-n2l.img.gz
If it doesn't boot I'll need to see output from the debug UART to see where things go wrong.
Now how do I access my media files from LibreELEC? I have installed the Jellyfin addon in LibreELEC.
Have you configured the Jellyfin add-on with the Jellyfin server URL and user credentials?
NB: If you installed the LE 'Jellyfin' add-on, you installed another Jellyfin server on the RPi4 and this isn't going to help you connect to the existing server. ISTR that Jellyfin has it's own client add-on which is sourced from their own repo.
