In LE 9.2 there is no support for HDR in the RPi4 image so HEVC files will play with washed out colours. It's currently the same in LE10 dev images but we're nearing the point where some of the plumbing for HDR falls into place, and then we can start figuring out how to use shaders to remap colours so HDR > SDR works on non-HDR screens.
Conclusion: LibreELEC configures itself to turn on the TV during the installation process.
The conclusion is wrong. LE does not turn on the TV, but Kodi stores the active video output interface in /storage/.kodi/userdata/guisettings.xml so if you install with HDMI2 and then change the interface to HDMI1 this invalidates the stored configuration.
I use a Bonjour/Zeroconf broadcast app called "Discovery" to track test devices in my network as the IPs change over time (due to DHCP) and when I clean install a new device I can see the SMB share appear in the list (so Samba is active) and then when I enable SSH and disable Samba in the first run wizard; Samba disappears from the list and SSH appears .. i.e. the respective services are being correctly stopped/started.
I haven't touched Samba and SSH. Both work for me 
The last LE image for WP2 that supports the internal tuner is LE 9.0.2. I'm not sure what you think is incomplete about it?
Sorry.. not in Armbian forums, here on the Amlogic u-boot mailing list:
Re: meson-gxbb regression since u-boot v2020.04
and
[email protected] | meson-gxbb regression since u-boot v2020.04
Netflix does not want an official Kodi add-on due to perceived security issuess (and Kodi's reputation which is tarnished by piracy add-on shitware like superrepo) so if we push it into the official repo and/or create official documentaation to make it easier to find/install/setup Kodi will receive takedown requests; so we either make do with the current unofficial route or have no add-on at all. That's a simple call to make.
Google has also made it progressively harder to get an approved 'app' through their screening processes, and if you aren't an approved app you have restricted access to their APIs. i.e. a limited number of daily requests and Kodi has millions of users; so the daily limit is consumed fast. Google is also a commercial entity which charges for access to their services; unless you're using their official apps on their OS. There is an effort to get something through screening which might improve upon the current situation.
And feel free to write and submit an official browser add-on that runs in Kodi and works on an asssortment of Linux (including no-Window-manager environments like LE), Android, macOS and Windows platforms (Kodi will not accept platform specific features). There is an effort to do this but it's not a simple task and it's remained a one-man effort (and like all volunteer developers, he has a busy day-job). Until then the current Chrome add-on for our x86_64 releases is the only option because Generic still uses X11. Once we reach LE11 (Kodi v20) we will probably run Kodi in a windowless environoment so that route dies too.
btw, Install superrepo and you receive no further support in these forums or Kodi forums.
There's a bug in recent u-boot where a clock is set incorrectly and this impacts mmc on C2 and likely other GXBB devices. It's reported in the Armbian forums but I forget where and didn't test the hack that was posted (which is a hack not a fix).
I'm fairly sure the many authors of third-party Kodi skins might disagree with that statement.
This is not supported by the default (Estuary) skin, but is something that can be done by other skins (so i've been told in the past - I don't have any specific recommendations).
I can create 720p 10-bit H264 samples that will play, and then I can tweak the encode settings so they will not play. How your 720p files play on an RPi4 is something only you can answer, unless you share samples that others can test. NB: Animé fans normally use high-spec Intel x86_64 devices to handle 1080p 10-bit H264 media.
i dont have any ssh access to libreelec. And there is nowhere a option to enable ssh.
Nowhere apart from the "Enable SSH" option in the first-run wizard that you clicked past, or the SSH service options in the settings add-on.
10-bit H264 is not an industry standard so no hardware supports 10-bit H264 hardware decode. So you must software decode, and that requires a device with enough CPU to handle the media (the PC has enough, RPi3 does not). If you share a sample someone can test it on an RPi4.
It's not a debug log, but it shows Kodi starting and attempting to open a stream via plugin.audio.radio_de which fails due to "Temporary failure in name resolution" and the LE settings add-on shows similar errors. I can't see how this is due to partymode, but I can see a general networking error that probably results from Kodi starting before the network is up; so enable "wait for network" in the LE settings add-on (under Network) and see if that resolves the issue?
The dmesg shared shows me that:
a) This is Linux 4.4 which we stopped all development on some time ago
b) Nearly every major kernel subsystem shows a catalogue of errors, so the booted device-tree is not an accurate description of the hardware
c) Including the SDIO subsystem, which the WiFi/BT device is attached to, hence no WLAN
I don't track Rockchip development closely so I've no idea whether there is a device-tree file upstream for your box, but I would start over with current Linux 5.9 based images, because then codebase is the upstream mainline kernel not the vendor BSP and there's half a chance of someone caring to assist. Old Linux 4.4 images are an archaeology trip .. and we moved on.
^ this URL gives me the icon so I'd guess the add-on in the repo has been updated to use newer add-on structure with image asssets in /resources and you have an older version (cached?) that requests a URL that genuinely doesn't exist.
Enable additional logging for curl, reboot, demonstrate the problem, then share the full debug log.
