Posts by chewitt

To set expectations on the N2 correctly: the mainline kernel is currently missing essentials like HDMI audio and hardware video decoding (both are active work in progress) and until G12 support reaches parity with existing GX hardware common missing items like 4K/10-bit video, AFBC and HDR won't see development effort. HDR is missing for Linux globally (pending changes from Intel being merged) but I have sub-zero concerns about LE/Kodi support and that topic. Otherwise, we already have the basics of an image working (see below). RIght now it's not much use to anyone without audio but the N2 is fast enough to software decode most 8-bit media that I've played and that's with the kernel still lacking dvfs so the CPUs are clocled to 1.2GHz not 1.8GHz. It runs cool due to the huge passive heatsink that forms part of the casing. The fact that it needs such a huge heatsink proves that some peoples concerns that S922X chips run hot are valid, but HK appear to have thought about that and it's nice to see passive cooling instead of the small heatink and fan arrangements that are being put into "Android box" packaging.

In case anyone is wondering .. S905X2 is also up/running in the same state as S922X:

I'm looking forward to a fun summer of mainline kernels and GBM/V4L2 awesomeness

SSID/passphrase can be set in LE settings. No idea about connman supporting LTE but it's a moot point as LE doesn't build support for anything but wifi and ethernet.

OpenVPN runs in the OS independently of Kodi but it depends how the connection was started and whether any controlling Kodi add-on will terminate the connection when the add-on is unloaded on Kodi stop.

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.