We have no plans to add support for any more Realtek chips that require badly written vendor drivers that break with every kernel update. Once their chips become supported in the upstream kernel (and thus becomes simple to maintain) we'll be happy to configure them in out kernels.
Not the answer you're looking for I know .. but that's the answer.
Devices with Atheros chips are generally well supported in the kernel, but few vendors give details on the chips inside the packaging so you've got quite a mission to find devices. As a general rule - if it's cheap it's Realtek (sadly). eBay UK might give more options for WiFi bridge devices.
Share "journalctl | paste" a minute after booting the 9.1.502 image.
Original S905 devices like the Odroid C2 do not support HDR.
Bump to 9.1.502 and retest. It has newer kernel/drivers/firmware which may resolve the issue, and even if you found the issue on 9.0.2 we're not going to put the fix in that release (there is no plan for 9.0.3 release).
Realtek breed new wireless chips faster than anyone can figure out how to support them, and 80% of their drivers are "out of tree" with low-quality driver code. Over a period of years we got bored of adding ever more shitty realtek drivers that break with every kernel bump, so we stopped adding them. In the future we'll probably move to IWD which will making it technically impossible to use half their junk too. Get a used Apple A1rport Express and run it as a WiFI bridge. It will present Ethernet to the Pi, has better range/throughput than any USB dongle, and there's no drivers required so they're future proof. You can use any WiFi bridge device, but I find the A1rport ones to be cheap ($15-20) now since Apple stopped selling them.
If your network functions correctly there is never any need to fiddle with cache settings, and the solution to a network that doesn't function correctly is to fix the network, not fiddle with cache settings. RPi 3B+ has weak wifi performance so it's best to use Ethernet or an external wifi bridge that presents Ethernet. I use some Apple A1rport Express WiFi routers in bridge mode for this .. they are fairly cheap (second hand on eBay), easy to set-up, they out-perform all USB wireless dongles for range/throughput, and no drivers are needed.
Almost all addons don't work
That's expected. Team Kodi announced the move to Python 3 two years ago but everyone sits on their arses and does nothing until a hard change is forced. Once the first public alpha for Kodi Matrix ships developers will wake up and start to fix their add-ons.
Apr 11 17:28:58 LibreELEC connmand[478]: eth0 {del} route fe80:: gw :: scope 0 <UNIVERSE>
Apr 11 17:28:58 LibreELEC connmand[478]: eth0 {del} route ff00:: gw :: scope 0 <UNIVERSE>
Apr 11 17:28:58 LibreELEC connmand[478]: eth0 {add} address 192.168.0.16/24 label eth0 family 2
Apr 11 17:28:58 LibreELEC connmand[478]: eth0 {add} route 192.168.0.0 gw 0.0.0.0 scope 253 <LINK>
Apr 11 17:28:58 LibreELEC connmand[478]: eth0 {add} route 192.168.0.1 gw 0.0.0.0 scope 253 <LINK>
Apr 11 17:28:58 LibreELEC connmand[478]: eth0 {add} route 0.0.0.0 gw 192.168.0.1 scope 0 <UNIVERSE>
Apr 11 17:28:58 LibreELEC connmand[478]: ntp: adjust (jump): +18133880.539957 sec
Nov 07 13:40:19 LibreELEC connmand[478]: eth0 {add} route 212.227.81.55 gw 192.168.0.1 scope 0 <UNIVERSE>
Nov 07 13:40:19 LibreELEC connmand[478]: eth0 {del} route 212.227.81.55 gw 192.168.0.1 scope 0 <UNIVERSE>
Nov 07 13:40:20 LibreELEC crond[281]: time disparity of 302231 minutes detectedPi devices have no RTC chip so on boot before NTP has updated the clock the time will start from the release date of the current version of glibc which probably dates from a release in April. Once the network is up NTP updates the clock and dateTime changes.
How are you running MariaDB? .. it doesn't look like the DB is up/running before Kodi attempts to access it.
You realise that on anything with 1GB+ RAM we already load the entire OS into RAM? .. and the amount of read/write generated by Kodi on /storage is not particularly high - not high enough to make those solutions worth chasing.
Badly encoded media is badly encoded media. The solution is to re-rip/encode your content from your original media. If you can't do that because it's some file you stole from a torrent network .. you also have an answer.
Running "rm -rf /storage/.cache/connman && reboot" will clear any network config that exists.
systemctl stop kodi
nano /storage/.kodi/userdata/guisettings.xml
find and edit videoscreen.screenmode to contain <setting id="videoscreen.screenmode">0192001080060.00000pstd</setting>
find and remove any content in videoscreen.whitelist, e.g. should look like <setting id="videoscreen.whitelist"></setting>
save and exit
reboot
As long as the device presents 1080p@60 modes, it should now be the desktop resolution. This should all be selectable in the GUI anyway.. but without debug logs and such there's no way to guess why not.
RPi4 requires GBM/MMAL code paths in Kodi, and while MMAL exists in the Kodi v17 codebase the GBM bits do not, so it is not (and is unlikely to ever be) possible to run Kodi v17 on an RPi4 board. There is sub-zero official (LE, Kodi or Pi Foundation) interest in exploring that direction. It's not impossible to backport .. but that depends on your personal coding and distro packaging skils?
NB: In LE the base OS, dependencies and Kodi are tightly coupled. You cannot update Kodi without updating the base OS at the same time, and you cannot just swap Kodi versions in/out as you like.
Ask the developers of the YouTube add-on to support subtitle preferences. Use the support thread in the Kodi forums.
connmanctl
agent on
scan wifi
services
connect <id_of_service>
(enter pw when prompted)^ I'm typing from memory, but something like that.
Accessing LibreELEC [LibreELEC.wiki]
^ connect via SSH, run the command that I gave you before. This assumes you copied the files to the right place (use WinSCP).
CE support is in another forum. Keep on-topic please.