Posts by chewitt

Most USB dongle WiFi devices normally trump on-board WiFi as the antenna is larger (albeit still small) and separated from other chips and RPi5 may or may-not be an improvement on earlier models, it's hard to tell. If you are in a poor/difficult signal area USB dongles also allow you to choose a device that can be hooked up to a proper external antenna. As a rule we avoid making wireless hardware recommendations due to the ephemeral nature of success; what works amazing for one person often sucks for someone else. This page from a linux-wireless maintainer is worth reading: https://github.com/morrownr/USB-WiFi/

Revert of the PR will restore the previous driver to the buildsystem, but you'll probably need to update the driver source version or add some source patches to compile the driver against newer kernels that we are using now; Realtek downstream drivers often break when we bump the kernel major version (hence we dumped them in-favour of in-kernel ones).

The RK3588, RK3567, RK356X images in my test share have been updated to use Linux 6.19.0 and HDR is now working on RK3588 and hopefully RK3576 too (limited tested on RK3588, no testing on RK3576 yet). I'm finding the output a little dark compared to the family daily-driver RPi5 board, but different hardware will always give different results, and most users won't have multiple devices wired up to the TV for comparisons; meaning you can tweak TV settings/profiles to get things as you like.

LE was created using https://www.linuxfromscratch.org principles. It is not a derivative of any other distro. It should boot and run on any type of x86_64 hardware but LE is not a general purpose OS and it intentionally targets HTPC/SBC hardware and will be lacking drivers useful on non-target devices like tablets and laptops. In some cases you can enable drivers in the kernel when building an image. In others not, it depends on the specific hardware you're trying to use and what drivers exist for that device. As a rule we avoid trying to curate lists of "what works best" because the lists are never maintained for long and are outdated; and you won't find lists of tablets in our forum because people rarely use them and we don't have experience with them. There's not much need for touch-screens among our userbase so support for them is a bit of a grey area and our experience is limited/non-existent.

Our 'Generic' image runs Kodi under GBM, while Generic-Legacy (not something that I'd guarantee is around for much longer) runs under Xorg. It can also run under Wayland which exists in our buildsystem to support the Lakka retro-gaming fork that leverages our codebase; but we don't release LE images that use Wayland (as no need to) and our buildsystem is missing lots of things you would need to create a desktop environment.

Kodi implements its own rendering engine so you'd need to learn their UI and skinning process to do something. Kodi plays media well, but it is not a kiosk systema and does not support ebooks, email, or much in the way of communications. It could of course do more, but that's down to you and your development skills. IMHO you'll get further faster using a conventional distro or perhaps Yocto/OpenEmbedded which has a much broader hardware audience and more packages in its ecosystem.

Please test a current LE13 nightly image without the EDID hardcoding. Same result?

There is no such thing as an audio-only HDMI connection, so the AVR is advertising video on HDMI-A-2, hence the 4K mode seen in the modetest output. The AVR on HDMI-A-2 passes through the EDID capabilities of the non-existent upstream device; ergo that connector has no HDR support. So if Kodi were using the output of HDMI-A-2 for decision making it would explain why HDR is not seen as possible, but the log shows it selected HDMI-A-1 for DRM output. At that point I have no clue

What, like this one? https://kodi.wiki/view/File_manager .. or the Web File Browser add-on in the LE repo?

Images in my test share are updated to Linux 6.19.y and with a change to the uImage.lzo kernel entry point that's currently needed to get the kernel booting on S4 boards; so I'm interested in reports of boot failures after updating. As part of that work I've added support for the Khadas VIM1S board, although this is not real-world usable at the moment (and thus won't be in official nightlies for a while) due to issues with the S4 DRM driver that result in a flickering screen when Kodi is running, and new alsa incantations being needed for audio routing/mixer settings. Khadas shipped a bunch of VIM1S (S905Y4) samples so there's common hardware among those needing (or wanting) to test the new stateless video codecs and dependencies (DRM, audio, etc.) Amlogic are working on.

In Kodi debug logs there is normally a section after debug <general>: CDRMAtomic::InitDrm - initialized atomic DRM and before the debug <general>: CWinSystemGbm::InitWindowSystem - initialized DRM line that displays info on the EDID data presented on the active HDMI connector Kodi is using. This data is missing from the log. However, in addition to colourspace data, the EDID data contains info on audio capabilities and in the audio section of the log names of the TV and AVR are visible so this appears to be read from the HDMI connctor okay. Most odd..

popcornmix there's been a couple of similar reports in LE12.2, any ideas?

ConnMan will show show a valid service as long as the config file is complete; doesn't mean the config is correct. The main item that you might need to figure out is the host IP of the server. ConnMan cannot currently resolve an FQDN to an IP so you need to replace any hostnames in the Mullvad config with an valid IP. Most VPN providers use hostnames because they are frequently changing the IP's that their nodes resolve to, and most hostnames resolve to multiple A records.

Extracting the dtb from an Android image is guaranteed to result in boot failure. Even if you rename dtb.img and configure uEnv.ini to use it correctly, the Android vendor kernel you pulled the dtb from has no code in-common with the mainline kernels that LE uses in the AMLGX image and kernel and dtb need to be version aligned.

If the box has an S905W chip the only device-tree files that might work are meson-gxl-s905w-p281.dtb or the similar Tanix TX3 mini device. It's a cost-engineered box with a CPU that runs/clocks slower than other GXL designs so p212 or similar may attempt to run the CPU faster than it can boot or reliably operate at. I would only use LE12.2 or perhaps an LE13 nightly image to attempt boot. LE9 images predate the existance of S905W (so don't support the chipset) and we no longer support those images.

If the device isn't booting to the LE splash screen or Kodi the only way for us to provide any support is to see the early boot log. This is obtained by connecting a USB serial UART cable to TX/RX/GND pins on the board; assuming they exist, and if not they need to be soldered in-place. The log will show what Amlogic u-boot attempts (or not). In the absence of the log we are blind to the issue and it's not worth the time/effort to guess at things.

NB: read https://wiki.libreelec.tv/hardware/amlogic to understand a little more about LE differences

Most providers simply generate all the keys needed for a client node to be configured to work with their server. This is technically less secure (as they generated and thus could know/store the private key of the remote device) but that doesn't seem to bother most users who only care about a connection that hides their presumably dodgy activity. I've never seen the Mullvad device generator tool but if they allow you to provide a public key and optional preshared key, which they store to authenticate your client node, this is more secure, but not really more complicated; the tool will still generate a conf with the content you require.

If there was a general problem with DHCP on WiFi connections with LE13 nightlies there'd be a ton of posts on the topic, and there aren't. So whatever the issue is, i'm confident it's local to your environment.

ConnMan debug logs are verbose and somewhat human-readable, but if you have a poor signal the inherent 'noise' that will add to the logs will make it challenging to spot any real issues. Poor signal is not the cause of the invalid-key issue, but as the issue is likely to be an unhandled radio/wireless error condition (the patch on the list is addressing that) poor signal correlates to the problem.

Quote from tandpijn

Can you confirm if it is worth trying to add sunshine DIY?

It doesn't matter whether you wait for core devs to implement something that can't work or DIY it yourself.

The release notes for LE10/11/12 have longer comments and warnings on the general state of Amlogic support, but in-short: H264 works well but the HEVC code was never finished and there has been nobody actively working on that codec since 2020 so there are no expectations of improvements to that driver. The config described here https://wiki.libreelec.tv/configuration/4k-hdr will give the best (or least-worst) results but some issues with HEVC seeking are known and expected. The S905X chip in the box is a typical ARM SoC with a weak CPU so software decode isn't a viable option for anything larger than SD media.

Amlogic are finally upstreaming hardware decode drivers (with plans to rework the entire DRM layer) which is long-overdue and great to see. We are working with them behind the scenes to help get changes tested and merged in the kernel, but their initial focus is H264/8-bit/1080p on S4 hardware (S905Y4/S905W2/S805X2). That effort is making slow progress due to kernel standards being rather higher than Amlogic's in-house ones, so it's going to be a while before HEVC/4K/HDR support exists and then gets backfilled to older hardware.

You might want to look at the vendor kernel image that dtech maintains. This will be more functional than AMLGX and contains a few updates to keep things ticking over, albeit add-ons and such are starting to die off under that era/version of Kodi.

Quote from update.freak

Is this still the case or what is here the current status?

It is still and will always be the case as LE runs a zero-copy display pipeline and this means frame capture is not possible. You need to use an external hardware grabber, then install either Hyperion (we use the original still, not NG) or HyperHDR to use it.

I'd be interested to see if this patch resolves the invalid-key issue: https://patchwork.kernel.org/project/connma…[email protected]/ .. as the title of the patch sounds promising but the author of the patch has provided zero info on the issue being fixed so that might be a coincidence. If you want to self-build an image to test, this is the change required: https://github.com/chewitt/LibreE…d93d6047769fb94. If you have an RPi5 board this LE13 image contains the patch: https://chewitt.libreelec.tv/testing/LibreE…-12.90.1.img.gz. NB: LE13 nightlies will have newer kernels and latest/correct drivers for the wireless chipset that you're using so I wouldn't bother triaging with LE12/12.2 images.

Quote from tandpijn

I imagine running a VM / Container with KODI on a VM server and being able to access it from any low-end device or SmartTV running Apollo/Moonlight.

This can probably be done with a conventional Linux distro, but not LibreELEC, as we use a zero-copy display pipeline. This means media is decoded from file/stream and each frame is stored in RAM using a (buffer) format suitable for rendering/output; so each stage in the display pipeline (Kodi, ffmpeg, DRM compositing, etc.) simply passes a pointer to the buffer containing the data instead of copying the data (hence zero-copy). The side-effect of this is that there is no opportunity to 'grab' the frame (as it's a pointer to data, not actual data) for display, which is how everything from VNC to fancier video streaming server capabilities obtain the frames to stream. This is the status-quo for 'Generic' (using GBM) and all ARM SoC hardware that LE supports. Only the Generic-Legacy image (using Xorg) is different, but that image is likely to be EOL at some point in the not-distant future so wouldn't be worth the time/effort of integrating around. Running LE in a VM is possible but then responsibility for streaming frames passes to the host OS and no changes are needed in the LE guest OS. NB: LE is quite intentionally a 'dumb-client' distro and this is our niche in the Linux/Kodi ecosystem. There's no real interest from project staff to diverge from that.

Quote from 2469

Can i still use it in the future?

One long-term challenge is that the latest nVidia cards are moving to an open-source (in-kernel) driver and GBM/Wayland, while more recent cards can also use GBM/Wayland but still need the vendor driver (cannot be packaged alongside the in-kernel driver) and older cards (like yours) still need the vendor driver and Xorg. GBM/Wayland is 'modern' which is nice, but Wayland does not support the userspace controlled refresh-rate mode switch that we use with AMD/Intel and ARM SoC hardware to give the best media playback experience so it's bit of a "one step forwards, one step backwards" improvement. To further complicate things, mesa has recently dropped VDPAU support and Kodi does not support NVDEC. Right now 'PlanB' would be to swap to a general purpose distro where you can install the right combination of drivers, but at some point updates will break support.

So it might be worth experimenting with the onboard Intel graphics (and nVidia card disabled). I'm not finding much info on the GPU for that MSI motherboard but it will be Intel and supports up-to HDMI 1.4, so while it would suck for games on Windows when compared to the nVidia card, its media hardware decode capabilities are probably similar and "good enough" for Kodi.