The Kodi crashlog doesn't really have anything interesting, but for completeness
In future "completeness" means sharing the whole log to include all the useful information that's ommitted when people try to be helpful and share incomplete snippets 
Start with testing the latest LE13 nightly as there are numerous interesting changes recently and there will be no more 12.2 releases; meaning even if we did investigate and find something the fix goes only into LE13, so best to start there.
I never put devices on static addresses, I use DHCP reservations in the router so that what has what is easily seen in a single place.
LE has a firewall. It's off by default, but if enabled it probably blocks ICMP (ping) requests.
I'm confident there is no LE software issue here. It's either environment or PEBKAC
Honestly no idea what you're talking about
LE doesn't mind if Lakka things are discussed occasionally, but LE has zero Switch support (and isn't looking to change that) so it's not really on-topic for here. Perhaps better to discuss in Lakka/Retroarch forums?
I only suggested you use AI tools to explain things in a user-appropriate level of detail.
If you also want to make AI based Kodi feature-requests (the technical developer term for them is Al-slop) those need to be directed to the Kodi developers in the Kodi forum. LE only packages Kodi, we engage with them to support development, but we aren't often responsible for changes and this is 100% not in our scope of activity. Kodi features should work across all possible platforms to be considered. In this case changes would need to work on "Linux" and not be Broadcom specific. Any changes that target a single silicon vendor will be dismissed on principle.
If you haven't already figured out that the LE codebase is not the one to be concerning yourself with, I suggest you go poke around in Kodi pull requests to look for interesting things. If you find something, pay attention to the extensive PR summaries, individual commit descriptions, and detailed code comments.
The list of open ports in the nmap scan results suggest 192.168.1.17 is some kind of Linux NAS or appliance device; it is not a good match for an LE device. I think you have an IP address conflict happening. Two devices claiming the same IP would probably explain some of the behaviours you are seeing.
The current TigerVNC add-on appears to be compiled against X11 libs so I doubt it runs under Generic, and it probably runs into the same zero-copy video pipeline issues that all the Ambilight setups (that depend on copying buffers that can no longer be copied) enounter under GBM/V4L2. If my guess is correct the add-on will need to be dropped when we remove X11.
The flatpak add-ons require Generic (GBM) and will not run on Generic-Legacy (X11). The flatpak changes are an essential step on the journey to discontinuing the Generic-Legacy image; along with changes that enable the few remaining nVidia cards that can work in LE to use GBM/VAAPI via the elfarto VAAPI shim until future GBM/NVDEC support lands in Kodi. Unless you are "blessed" with an nVidia GPU and thus forced to remain on Generic-Legacy, you should switch to Generic.
If you run avahi-browse --all on the Linux box (assuming avahi is installed, it probably is) it will show all the mDNS services that are being advertised on the subnet. Is the LE box visible there? .. e.g.
ROCK5B:~ # avahi-browse --all | grep RPi5
+ eth0 IPv4 RPi5 _ssh._tcp local
+ eth0 IPv4 RPi5 _sftp-ssh._tcp local
+ eth0 IPv4 root@RPi5 _pulse-server._tcp local
+ eth0 IPv4 root@RPi5: Null Output _pulse-sink._tcp local
+ eth0 IPv4 RPi5 eventserver _xbmc-events._udp local
+ eth0 IPv4 RPi5 jsonrpc-tcp _xbmc-jsonrpc._tcp local
+ eth0 IPv4 B827EBB5E9A2@RPi5 _raop._tcp local
+ eth0 IPv4 Librespot@RPi5 _spotify-connect._tcp localLE13 nightlies now allow the Retroarch flatpak to be installed from the LE repo. No idea if that helps or makes things easier?
If the laptop and iPhone can connect the LibreELEC side of things is working fine. That means the issue is either Android (possible but IMHO unlikely) or the network (my guess).
Auto-discovery features normally use mDNS broadcast on the network (and LE supports this) but if you have multiple switches in a daisy-chain or bad config in a managed switch the broadcast traffic might not be forwarded. Another common mistake is having a wireless router plugged into a switch and not configured as a wireless bridge; meaning a NAT firewall runs between LAN and WLAN segments and the firewall blocks the traffic.
Describe the layout/devices of the network.
I'm in the UK for a few days so I packed a WeTek Play2 box on the off-chance I'd be able to test the DVB-T driver that me/Claude came up with recently. The above screen grab is from VLC on a MacBook (as there's no TV to use Kodi with) streaming BBC1 from Tvheadend installed from the LE repo, and running on the box. I'm genuinely surprised it works 
NB: Reworking the current driver code into an upstreamable driver is an entirely different challenge!
At the moment HDMI (and things like audio which are related) and 4K/HDR/decoding patches that were originally created back in 2019-2022 need to be reworked against current kernels which have moved forwards in a few areas. Some of that work has started, but I need it to get a little further along before I can pick and integrate patches into the already huge kernel patchset (of things now being actively upstreamed) that's used with newer Rockchip boards like RK3588. Until that happens, I'm aware that current (older) patches have some breakage. Whether that's the root cause of your audio problems or it's something else is unknown, but until we can get older boards using the same kernel as new boards (with updated patches) I'm also not too interested to investigate; audio is not my area of expertise and trying to get developers (some ours, some upstream) interested in known-outdated and downstream patches will be frustrating. You are welcome to try nightlies, but as the same patches are used there currently, I won't guarantee anything is better. No harm in trying though.
The USB keyboard should have worked. Historically there was a bug that caused the USB hub to not reset and detect things but that claims to have been fixed in the upstream kernel some time (a couple of years) ago.
HDMI-CEC should also work, although this is something I never normally test because I have too many CEC capable devices attached to the same AVR and it causes problems; so I disable/block it on the AVR.
If you add ssh to the boot params in exlinux.conf the SSH daemon is forced to start on boot, and then you can SSH in to the device and use kodi-remote to navigate the screen same as a remote control. The Odroid remote is also supported OOB if you have one.
I've pushed a clean rebuilt Generic image to https://chewitt.libreelec.tv/testing/LibreE…-12.90.1.img.gz - I think the issue above is the result of an unclean build after we switched the Generic image from OpenGL > OpenGLES last week.
Please try again.
Clean boot with Kodi in debug mode and then share a log URL using "pastekodi" .. else we have nothing to investigate.
Over time people wanting to use Kodi in a Kiosk use-case wrote their own scripts to manipulate Kodi .. but .. THERE IS NO SUCH THING AS KIOSK MODE. Feel free to prove me wrong with a screenshot from the Kodi GUI - anywhere it says Kiosk.
There is a chance that kiosk mode uses more RAM
That's a load of BS because there is no special 'kiosk' mode in Kodi, only 'normal' Kodi being used with a repeating playlist in a kiosk scenario. Ergo there is no difference and thus no magical increase in RAM use.
Go test this image https://chewitt.libreelec.tv/testing/LibreE…-12.90.1.img.gz and report back. Note that this image is LE13 and we switched Generic from OpenGL back to OpenGLES so if you have screensaver and visualisation add-on installed those will need to be removed, the cache in /storage/.kodi/addons/cache deleted, and then the add-on needs to be reinstalled else things will crash. Just leave settings present and it's no big deal.
NB: I'm not answering the Q's above as there are known rendering bugs solved and notable changes to rendering in this image; and the combination means triaging anything on LE12.2 isn't a productive use of time (there are no plans for a 12.3 release).
