Posts by chewitt

The last LE release that will support a GeForce 6100 GPU (released in 2004) is LE 7.0.3 from 2016 when the project was new. This is still available in the project archive, but it won't be much use for anything except local file playback today, as anything that talks to the internet will have issues with expired SSL/TLS certificate chains and outdated Kodi add-ons.

So the error message is 100% correct .. GPU is not supported. On hardware that old it's not worth swappiing the GPU for something newer unless you have cards kicking around. If you don't, better to save pennies towards something like a Raspberry Pi board or a small form-factor Intel box.

You can add a custom firewall profile to suit your needs, and since the profile file(s) are stored under /storage/.config/iptables they will be included in any backups you take using the LE settings add-on.

NB: I don't see any issues with the WireGuard sample template running on my own setup.

Parallel build failures are either a genuine issue with multi-CPU building on a particular package, or sometimes the result of missing dependencies. In the latter case, re-running the build command may result in a new package build-order, and if other packages are now built before the failed package is cleaned/reattempted, it can build correctly. It's not guaranteed, but free to try..

Look for \\LibreELEC\Logfiles on the network. When you click into the folder a zip file with logs is generated. Share that.

Or read this: https://wiki.libreelec.tv/support/log-files

There's no point in adding Kodi debug info until Kodi runs, so just do "dmesg | paste" over SSH and share the URL generated.

There are multiple issues being flagged in that thread, and some of them are likely due to silicon bugs in Amlogic hardware. So hard to comment on anything, and you share no logs, so ..

Correct, although I'd rephrase it as a general problem with commercial VPN services. It's nothing specific to WireGuard, and not all WireGuard configurations use class A addressing, although that's probably true for commercial services.

Quote from ihipop

any plan to support this?

I'm happy to backport merged patches to our current kernel(s). I'm not interested in adding unmerged stale patches that nobody is working to upstream. I suggest you build an image with the RFC changes, and if they work (or don't) comment on the mailing list thread to revive it and perhaps trigger some activity with the developers.

Those kind of products swap internal chipsets between batches based on what's available and cheap(est) to use. The internals are far from being guaranteed.

The 'Generic' LE12 image supports Intel/AMD GPUs, the Generic-Legacy image supports nVidia GPUs; although only as far back as the 340.xx driver series. Also note that 340.xx has been dropped from LE13.

Quote from donbeaupapa

I am openSUSE tumbleweed desktop KDE.

You're in the wrong forum then. We create and support LibreELEC not openSUSE .. desolé

I don't think SD card capacity makes any difference, and (as mentioned above) the patches I added for LE12 are missing from LE13 so it's more of an omission than a regression.

Quote from aptalca

Do you need to build it?

Yes/No .. It's not mandatory, but building from source gives clearer provenance, and often gives flexibility around packaging.

Quote from risa2000

I am using Argon case with SSD port

The number of users that show up with an Argon case and swear it cannot possibly be their magic/favourite case; who then go quiet after we insist they remove the board and test playback without it .. is notable. So, remove the board and test.

Current images have intentionally dropped a load of "WIP" Linux kernel patches because I've had some long periods of downtime on LE during 2024 and I basically forgot what patches were added for what purpose on what device. I have fuzzy recall a change to SD/emmc speeds is needed for U9-H, but I'll need to poke around in old kernel trees.

NB: I don't think the panfrost error is itself important, it's most likely a casualty of overall OS instability caused by the I/O issues.

Quote from TomTom

Do you see any objection to this choice ? (for 4K HDR (10bit), DTS/5.1 audio and 3D content)

Yup, LE (AMLGX) does not support HEVC hardware decode on G12B chips like the S922X used in the N2/N2+ due to long-standing bugs in the codec driver that lock-up the board with 10-bit media, so hardware decode is intentionally disabled and this limits the device to 1080p output. There is also zero 'hardware' 3D support, although ffmpeg might do things in software?

CE has released images based on the vendor kernel that are allegedly more functional, but I have no idea if they still support 'old' hardware like the S922X or what state 3D support is in - it's always the bastard child that's been forgotten about. For informed info on CE support you need to ask in their forum because I pay zero attention to their releases.

OSMC vero devices might be a good choice. They also use the use the Amlogic vendor kernel, but (at the risk of being heckled by CE fanbois) are better maintained than CE based on user feedback I've seen.

Cheap Intel HW is sometimes attractive but there are regular user reports of issues with native HDMI vs LSPCON based HDMI output and with Intel breeding new chips faster than drivers get written .. Intel support is not as reliable as it used to be.

RPi5 doesn't support 3D either, but is rock solid for everything else and the higher initial cost provides better long-term value than chasing bugs in cheaper hardware. Source an old (and cheap) RPi3B+ on LE 9.2.8 if 3D support is important to you, as that's the last hardware/software combo to really support it with LE.

Do not attermpt to use old vendor-kernel device-tree files found on the internet, they will not work.

Do not rename files to dtb.img and kernel.img etc. - this also will not work.

The supported device-tree files are in the amlogic folder on the SD card.

This is all explained in the wiki instructions you didn't read.

Odroid C2 uses an S905 chip which does not support HDR. The original vendor codebase can convert HDR to SDR on-the-fly using an image processing function called ge2d, but this capability has never been implemented on the upstream kernel codebase now used in current AMLGX images. S905X (one generation newer) supports 8-bit HDR output, and S912 supports 10-bit, although only 8-bit is currently implemented in the unfinished upstream code.

RPi5 is the current go-to recommendation for something simlar with excellent software support. The 2GB model is fine for normal LE use, unless you want to run Docker containers and other things in the backgroud, then 4GB or 8GB will be more appropriate.