In short, is there a compelling reason to go with RPi5 rather than RPi4?
Speed and CPU grunt. Menus and screens are noticeably 'faster' and the extra CPU grunt broadens the selection of media that the board can CPU decode with ease. The 4GB RAM size isn't really required for LE but the 2GB variant isn't being produced yet. If you're on a tight budget an RPi4 will check all the immediate boxes and be a nince update on RPi3. If there's a little more room in the slush fund I'd still go RPi5 tho.
Enable debug logging, clean boot, demo the problem with local medai, then "cat /storage/.kodi/temp/kodi.log | paste" and share the URL.
If the main variable is LE u-boot vs. Tow-Boot and LE works, it implies the issue is something being done differently in Tow-Boot. In that case the "why doesn't it work" question really needs to be put to the Tow-Boot maintainers, not LE maintainers. As a general rule Linux should be configuring the hardware when it takes over from the boot environment, but in some cases you do find an underlying dependency on things like clocks where the bootloader is setting something and Linux is not (thus blindly inheriting whatever the bootloader did). LE is currently using u-boot 2022.10 with a few minor u-boot patches, but nothing that stands out as significant to me. In short.. 
Please test a current LE12 nightly .. let's see if newer kernel/drivers have fixed anything since LE11?
HarryH in addition to testing it would be easier to review changes if you push code to a GitHub repo. Feel free to reach out if you need any help with that process.
One of my guesses was right then! .. but nice work on fixing it 
After you disable the service, mask it, e.g. "systemctl disable lircd.service && systemctl mask lircd.service"
I'm not sure how time could impact on Kodi starting or SSH login which is what your comments hint at. Not least because this is a box with an RTC chip so while time might not always/initially be accurate (ahead according to the boot log; the last line shows time being corrected) it shouldn't ever be so far off it causes problems, and a single working boot (Linux or Android should keep time current.
Can you run "journalctl | paste" and share the URL; this will mostly show the same log out but with timestamps.
I understand people still want to use WP2 boxes due to the DVB cards, but IMHO most users would be better off using them as a pure head-end (server) device and an RPi4 or RPi5 board as the client device as the software support is sooo much better.
The one other thing you can try is adding "textmode" to boot params. This boots the box to a text console (not Kodi) allowing you to poke around in the OS to look for problems using a USB keyboard. If the issue is still related to Kodi specifically it's not going to be seen (as Kodi isn't started) but... you might spot something.
Otherwise I've no idea what the issue could be. I've installed AMLGX images on a couple of things using the same batch of files in my testing share earlier today and they all run without any major issues.
To see more, we really need to see the systemd journal log and/or kodi.log to see what's causing the issue.
Package description fix PR https://github.com/LibreELEC/LibreELEC.tv/pull/8243
Both "dvbscan" and "w_scan" are included with the "DVB Tools" add-on in the LE repo. The description for the add-on only mentions w_scan but looking at the package sources we bundle everything in the dvb-apps package so the description needs fixing/updating:
For the record, here's the same logs from my WP2 box (connected to a Marantz AVR > LG-B7V TV) which has no problem with EDID data, and thus we have confidence it's not a general software problem (there's also a moderate number of active WP2 installs).
dmesg: http://ix.io/4JK0
modetest: http://ix.io/4JJZ
IMHO if users want a NAS they're better off aiming for a lower-spec Synology box like DS223J which is purpose-built and easy to expand in the future to include a second drive for data redundancy. The cost difference vs. an RPi4 + PSU + Case really isn't so big and it'll be easier to use and maintain than a homebrew RPi device, and there's no rats-nest of cables and PSU's to deal with. If you do want to go down the RPi route look at OpenMediaVault or similar (NAS distro) unless you plan to use the other RPi for playback too.
But as you might know already, RPi4 does not support h264 very well.
I'll call phooey on that statement ^ .. RPi4 has no issues with any of the H264 media I've tested with.
What application or service provides the IPTV server?
Plug something else into the same HDMI socket on the TV (PC or other HTPC or .. something). Any issue? If no issue, perhaps the HDMI socket on the WP2 is damaged. These are old boxes now (8-years) and faults like dry solder joints start to show up among users.
Otherwise ..
The modetest output shows no EDID data. Either the TV doesn't advertise any, or there's a fault with the cable, or the box has a problem so it's not recieved. HDMI 1.4 cables will (or should) still pass EDID info.
Did this affect my device? Did I lose any other licenses?
Ask someone who cares about Android (not me).
