Posts by chewitt

It was merged to the master branch so is in current LE11 nightlies. It wasn't backported to LE10.

Kodi has no support for "tonemapping" (converting HDR content to SDR and vice versa) so does your 'old' NUC support HDR? If no, there is nothing to do. If yes, when HDR content is detected the display pipeline will configure itself to use the best-matching output.

You need to follow a "backup > clean-install > manual restore" process to update the box. Clean install requires you to trigger recovery boot mode so the box reads new/updated bootscripts from the SD card; then it can find the new upstream device-tree (configured in uEnv.ini) and the boot files. Once Kodi is installed and running you can copy the backup to the box and do a manual restore of the essential bits (databases, thumbs, sources, add-on settings) and then restart Kodi. Then reinstall new Python3 versions of any add-ons you were using and you're done.

You cannot directly update - it will either refuse the update or if you force it, it will break boot (the box is not bricked, but you need to do the recovery process to get a working system again).

Or you stick with whatever image is on the box now .. if it all still works, nothing is forcing you to update.

99.999% of LE users have no idea that a local console exists (in debug mode) and thus have no need to access it, so we haven't wasted space in the image adding font-size-changing binaries that 0.001% of users or less will use.

Have you tried experimenting with fbcon=font: options in kernel boot params? https://www.kernel.org/doc/Documentation/fb/fbcon.txt

Quote from razvanelgsm

Hello! I have in hand Vontar X2 box with s905w2 and I manage connect serial wires and dump a boot log when i try to boot it from sdcard (armbian), I can provide this dumps and play more on this if you want to try.

I'd prefer to see output from the LE "box" image (not Armbian) since we normally use a newer kernel and I know what patches are being used with it - I don't track Armbian kernels. Please experiment with different SM1 device-trees and share logs.

https://test.libreelec.tv/11.0/Amlogic/box/ <= LE11 nightly images with K20

These images are using the upstream kernel codebase that isn't 100% feature comparable to the legacy vendor codebase, but it's still quite usable for most users (and the only option for S912 devices in the future anyways).

https://hub.docker.com/r/honeygain/honeygain should be usable via the Docker add-on

You don't configure the OS in LE to give bigger console text. You connect via SSH using an app and you set font size in the app. Or - you need to explain what you are trying to do - because it is not clear.

You might need to explain what "pb" is to get an answer.

Since you don't specify the OS or app that you are using for the terminal/console it's impossible to say; but most apps have an option to increase the default font size in their settings. If you want more help, be more specific.

The majority of users always go looking for something cheap, and they encounter a ton of friendly and easy to follow online articles about building a (historically, given current pricing) cheap RPi based NAS vs. buying some expensive pre-built NAS box .. so that's what they do.

I personally value the million man-hours of evolution and development that Synology have in their latest box vs. me with a NAS-oriented or NAS-specific distro and an arguably above average knowledge of hardware. I also value not needing to think about it much too; so I'm firmly in the "if you want a NAS box, get a NAS box" camp

Use the iptables firewall with custom rules?

*THE* thing that differentiaes RPi in the ARM/SBC world is the software ecosystem around the boards. Users (of all kinds) can achieve more with average hardware that is excellently supported, than with excellent hardware that is averagely supported. As a general rule, no other SoC manufacturer 'gets' this, and while some SBC vendors do an okay job with better than average support, it's only better than average and not the A1++ support in the RPi ecosystem. The x86_64 world has similar levels of support, but generally with a higher price tag.

NB: RPi Trading (the for-profit bit that raises funds to the non-profit Foundation) openly recognises that their primary audience these days is more interested in industrial use than education or the hobbyist sector, although things like Home Automation (and Kodi) are still strong; but nowhere near the percentage they were a few years ago. So RPi4 is already more industry friendly than previous generations and I would expect RPi5 to continue that trend. There is still a strong desire to hit the $35 price-point (or the principles behind it) but it's just not possible in the current screwed-up supply-chain post-covid ukraine-war world.

Despite the current short-supply.. I would expect RPi boards to continue being the best supported devices in our line-up.

ION2 has no support for hardware HEVC so it will be software-decoded on the (slow) Atom CPU.

Using alternative players is possible in some OS (Windows, maybe Desktop Linux) because there's a Windowing environment that handles the display of things and the instruction to play something can be somewhat delegated. LE has more complicated distro packaging and we run on the DRM framebuffer so there is a VERY tight integration between Kodi and FFMpeg and the display hardware; so you would first need to compile mpv into the LE image (as we have no package manager or means to simply install it) and then you can configure it as an external player; at which point you'll almost certainly find that mpv is not the solution to whatever problem you think it might solve.

SMB is active by default and visiting the \\ip-address\logfiles share will generate a zip file with logs from the system. If you can share this we can have a look. If you can't .. the description suggests a cable issue or perhaps a port/speed conflict that prevents Ethernet from working properly on the board.

WireGuard itself only operates on IPs (NIC interfaces can have an IP, but not an FQDN) hence in the current ConnMan-VPN implementation this is also a hard requirement. The wg-quick script that some WireGuard implementations use to create and tear-down WireGard interfaces has the advantage of being able to resolve an FQDN to an IP address before creating the interface. I haven't tried wg-quick on LE for aeons but it probably works, or you can create your own up/down scripts for systemd to make connections if you like; WireGuard support is in the kernel and making connections is not tied to ConnMan. The advantage of using ConnMan (and reason our default support uses it) is you can see and enable/disable connections using the LE settings add-on in the Kodi GUI.

Host needs to be an IP address, not an FQDN, may be the issue.