HDMI is connected to port 1, and needs to be in port 0 nearest the power connector. Also note that 99% of users have no need to force 4K60 modes since there is very little 4K media in 4K60 format.
NB: If you reinstall the banned add-ons shown in the first log, further support will be refused.
LE is using the default libc resolver and this caches records according to their TTL values so I doubt caching is the issue. I'd make an educated guess that Kodi makes some form of discovery request which is being denied or sinkholed by Pi Hole and so the request is being repeated (ad infinitum) hoping to get a response (which never comes). There is probably something in Kodi that could have better failure logic. In the same breath Pi Hole improvement to not break the world's most popular mediacentre app would be a good thing too. The decision to use Pi Hole also makes it a self-inflicted problem, sort of, so both sets of developers will probably point fingers at the other.
More verbose logging from Pi Hole and/or perhaps a PCAP of the traffic to look at would be useful.
I'm able to use SSH from PowerShell on a Win11 Pro (arm) VM under vmware Fusion so I assume it can/should work from the x86_64 version too. Please ensure that you didn't enable the 'disable password auth' (allow only key-auth) option in LE settings, because this is confusingly worded and will not stop the box from prompting for a password; but does prevent password auth from ever working. Assuming that wasn't the issue, install PuTTY and use that instead.
Would there be any chance of getting it to recognize 3gb?
CE kernels will report whatever RAM size the boot code reports (true or fake) while upstream kernels report what is actually there. So the only way to make your 2GB box report 3GB is hacking the kernel or GUI to report 3GB. IMHO, since it works .. don't fix it.
It's a known challenge. There is no solution at the moment.
It will persist, we don't touch boot config/params ever during updates.
FileZilla copies files. It is not an SSH client. Use PuTTY.
This shows older Kodi GUI but the process is the same:
Cold boot with the box connected to the TV and then run "getedid create" from the SSH console. It will capture the EDID data from the HDMI connection and then hardcode the HDMI connector to use it so the box sees the TV as always-on/always-connected. Then it shouldn't make any difference if the TV is turned off/on again.
I have no knowledge of these mini Beelink devices, but whereas CEC is native on most ARM SoC boxes (aimed at the Android STB market) most x86_64 devices (aimed at Desktop Windows users) don't natively support CEC control over HDMI.
Add "textmode" to boot params in syslinux.cfg and the OS is forced to boot to a local console instead of Kodi. This allows you to connect a USB keyboard to poke around a look at the system log with "dmesg" .. which will probably reveal the box can see the SDIO module but is missing a firmware and nvram config file to make it work.
The missing files should be in this repo: https://github.com/LibreELEC/brcmfmac_sdio-firmware/ but you'll need to download it on another machine and copy it to the root folder of the USB stick, then boot the box into textmode and copy the files to the /storage/.config/firmware/brcm/ folder before rebooting. On reboot the firmware will appear in /usr/lib/firmware and the card should work.
If you confirm that fixes it, we'll have a think about how to resolve things properly in the normal image.
Fake RAM size isn't uncommon but it's rare to see 512MB configurations outside of industrial boards, even on older platforms like Meson8. I'd guess you still have the wrong boot ROM for the box and the RAM configuration in early boot code means it's only seeing 1 bank of RAM, and the second (missing) will add another 512MB to give a more normal 1GB.
Then again; this is an era where all kinds of shady manufacturing has been done. If it works and doesn't cause problems; don't fix it 
If you follow the [1] link in the wiki it links to the PR: https://github.com/xbmc/xbmc/pull/21973 .. which shows this is only on Windows.
Does anyone have a solution for this?
Update to (or reimage with) the current LE11 beta which is more than stable and has lots of fixes for RPi blank screen issues. Run "pastekodi" again if issues are not resolved.
video=HDMI-A-1:d
video=eDP-1:d^ Pick whichever connection you want to disable (HDMI or eDP) and add the relevant string to kernel boot params in /flash/syslinux.cfg to disable that output. This assumes you have an Intel or AMD GPU in the laptop. If it's nVidia; there is no GPU support in the Generic image now that we switched to GBM/V4L2 graphics and you will need to use the Generic-Legacy image that heitbaum mentioned.
If it starts with this, your Android is unfortunately only lying that you have 2GB of RAM, but in fact it only manages 1GB.
^ Android hacked to fake RAM size is not uncommon. We even see "Amlogic" boxes with Rockhip boards inside 
You run the command over SSH.
Connect the HTPC to the TV, capture the EDID and setup audio/video as you like. Reconnect HTPC to AVR and use.
As Dr. Spock once said.. "The needs of the many outweigh the needs of the few" and we (still) have no interest in adding IPSec client support for a tiny hanful of people to use. NB: If you have need for VPN to play media remotely WireGuard is a much better option than IPSec and you have either a NAS or general server device at home that can support WireGuard (or a container that supports it) with the router doing basic port-mapping to allow access.
If your distro runs Xorg as the windowing system HDR is not possible (and not likely to change). If it uses Wayland it's possible with the right kernel drivers and mesa for codec, colourspace and colorimetry support, and right now that's more complete with OpenGLES (which is not standard) not OpenGL (standard). And then you'll be challenged by Wayland lacking support for dynamic refresh-rate switching which is essential for a better playback experience. So it's possible, but a conventional desktop distro is probably missing essentials due to favouring stable code over latest code. And even if you pick a rolling and more bleeding edge distro you're probably swimming uphill with a few things to resolve. LE isn't constrained with 'Desktop' requirements so we have it a little easier, but even LE is cannot avoid the reality of Kodi only supporting rather basic HDR things on Linux today. There are PRs on GitHub for some (but not all) missing bits of the puzzle; there are still several unresolved "chicken vs egg" issues between kernel and userspace that need to be addressed. RedHat are sponsoring a Wayland meet-up next month which aims to get enough 'name' developers in the room to agree on a path forwards for the main problems. Hopefully that succeeds, as the discussion has been been rolling on for some time now. Once there is a clear statement of technical direction Kodi developers can plot a course on the missing pieces. Right now Kodi only really supports HDR on Android and Windows; because the underlying OS support HDR and thus we can leverage that. LE is next-best (or least worst) ignoring the existence of some ARM vendor kernels (built for Android) but LE is still dependent on a number of "Work in Progress" pieces that aren't upstream yet, and moving slowly.
