If the WiFi device uses an in-kernel driver it supports the required frameworks for iwd. If it depends on loading an out-of-tree driver it's probably not going to be supported.
Anyone thinking we're being awkward about these drivers should read Could someone add rtl8811au? And for Raspberry Pi support? · Issue #346 · lwfinger/rtlwifi_new · GitHub which is how the developer responsible for more realtek wifi support in the upstream kernel than anyone else feels about them 
Safe Mode swaps your (bad) Kodi folder for a temporary (safe) one, so it includes the change to oe_settings.xml where the hostname is stored.
Python3 is a Kodi v19 thing. Most of those screensavers are just neglected by their creators. One of the Kodi developers @alwinus has recently done a major overhaul of some (but not all) of the broken ones, and those changes should be picked up in Kodi 18.2.
If the external USB device was detected the connections tab in LE settings will show "duplicate" wireless networks (as there are two interfaces seeing each network) but each network is tagged with the interface that saw it, i.e. wlan0 or wlan1. The fun part is that with slow loading SSV6051P drivers and normally slow loading USB drivers .. which device is wlan0 and wlan1 is a bit of a gamble; it's determined by module load order in the kernel which is not fixed. Assuming the USB device is detected, the best thing to do is "echo blacklist ssv6051p > /storage/.config/modprobe.d/ssv6051p.conf" and reboot to prevent the driver loading .. which leaves only one interface.
Connman enables tethering by technology not by interface. It probably prefers tethering on wlan0 but honestly I've never tested that.
datrh You should be building from the "libreelec-9.0" branch not master, and this will avoid the need to build new add-ons.
Connman gained the ability to ignore ntp from gateways (e.g. the dns/dhcp service in domestic routers) in these commits which LE includes
connman/connman.git - Connection Manager
connman/connman.git - Connection Manager
connman/connman.git - Connection Manager
but I recently noticed a typo which means it cannot work:
connman/connman.git - Connection Manager
Connman was version bumped to include this and other fixes in our master and 9.0 branches in the last couple of days, so assuming this is related to the issue, it should be resolved [sic] in the next LE update.
It's worth pointing out that the Linux kernel currently has no HDR support. It is active "work in progress" from Intel, albeit rather slow progress due to the large number of other drivers (and companies with commercial interests) that will consume the same changes once merged (so lots of cooks in the kitchen sharing their opinions). One of the component patch series' is now on it's 17th iteration so things are hopefully nearing a conclusion.
Yes, we will support the Odroid N2, but using a mainline kernel image not Amlogic legacy kernels. Coming soon
Run "dmesg | paste" a couple of mins after clean boot and share the URL here
Kodi GBM/V4L2 support is still in a fluid state as the underlying changes to Linux kernel things aren't cast in stone yet, but at some point they will become a more static target, and from that point forwards change becomes much easier to manage. Support on the Kodi side really comes down to GBM/V4L2 providing a single code-path into FFmpeg which handles a small number of different code-paths (stateless, statefull, vaapi) depending on which SOC or GPU hardware is being used. There are 5-6 developers actively working on that area of code; roughly representing RK, Allwinner (stateless) and Amlogic, Raspberry Pi (statefull) and Intel/AMD (vaapi) interfaces. Once you drop lower in the stack to the kernel driver code things appear to be more of a one-man effort because kernel DRM drivers tend to have a primary maintainer driving things forwards, but in all cases there's a community of other developers actively testing and contributing towards that driver and the surrounding stack. LE tends to have a single developer 'representative' among a group of developers working on code and influencing direction. We actively and successfully position Kodi as a fun and useful test application, and since many of the community developers have competing professional or commercial interests we often fulfil a role as a neutral test-case and it's common to see "good Kodi support" somewhere on the written agenda for V4L2 graphics initiatives.
Rockchip (and others) are in limbo at the moment while we wait for some upstream kernel changes to land. This is completely out of our control but it will happen (as big companies like Intel need it to) and then we'll start to show progress again. Raspberry Pi and its legion of supporters are ultimately dependent on the same changes and will also be moving wholesale to the Kodi GBM/V4L2 stack for LE10. Many things become interconnected in a way that makes it impossible to promise that Rockchip support will not drop off, but equally these changes makes it fundamentally more improbable this this will occur
Users sometimes mistake LE being a small and efficient Linux distro for it being ideal for using on old hardware, but our focus is on current and recent hardware so we are frequently missing drivers and support for older devices. That said, unless you tell us exactly what the hardware is (and share the dmesg output) all we can do is make broad statements ^ and guess at the issue.
Your box is from a vendor who saved pennies by not securing a unique MAC address range for their products. As a result the NIC in your box does not have a programmed (fixed) MAC address. Under Android the kernel has been hacked to assign a static MAC address (normally unique to the 20k or so boxes in the production run). Under Linux the kernel hack doesn't exist. If you're lucky you get a different static MAC. If you're less lucky the kernel will generate a random MAC that changes on each boot. If can be "fixed" with a udev rule or systemd service that corrects it during boot. There's some threads on the topic in this forum if you search for them.
Not even remotely possible.
Updates are enabled, but we only publish for official images. What hardware (and image) are you using?
It's really quite simple: inputstream.adaptive can leverage the widevine libs if present. On Android where some devices have L1 certificates this allows full hardware decoding of the stream. On Linux there are no open devices with L1 widevine support so inputstream.adaptive pretends to be a web browser with an L3 certificate that most content providers allow up to 1080p streams for. Some providers allow up to 720p streams. Some providers encrypt both video and audio (Netflix is one) while others only encrypt video which results in a lower decryption load; and on low-spec hardware this can be the difference between coping and not-coping with 1080p.
What's the use-case for needing LE devices in a swarm?
The police call it "eliminating suspects from your enquiries" .. I wasn't expecting a result, but wanted to know either way. The changes prevent the issue where we attempt (and never remove) ipv6 servers from the list of possible servers to use in addition to ipv4 servers.
You're better off asking in the Kodi forums where content add-on developers hang out.
