Posts by chewitt

From a technical perspective timezone is a "nice to have" not "must have" function. The OS runs exactly the same on UTC as it does with one configured. There is also no need to define NTP servers; we fallback onto pool.ntp.org servers by default so as long as the network is functional, devices like RPi boards with no hardware RTC chip will have time corrected during boot.

NB: Adding a timezone setup option in the wizard would be great. Our all-volunteer project staff working for fun in their free time looks forward to reviewing your contribution on GitHub to make that possible.

ix.io is dead/down for some years now, so a working URL from our own paste server is the correct behaviour

Quote from Ubuntu_is_life

"***Error in mount_storage: mount_common: Could not mount UUID=d2f120b6[...]83 ***

The UUID is for the partition on the original USB/SD (or whatever you wrote the LE image to) and that UUID will change once things are moved to the HDD. So fix the boot=UUID and disk=UUID params in whatever bootloader config file is being used to ether use the correct UUID(s) or use LABEL or point directly to the relevant /dev/device(s) for the partitions.

K22/LE13 nightlies contain changes to the Kodi SMB client that might be interesting. First you can select SMBv2 without large MTU support (which likely isn't helpful to a remote connection). You can also fiddle with the SMB read chunk size; as smaller is likely to work better on a remote connection. It may also be worth experimenting with smbclient at OS level (locally mounting a remote filesystem using systemd mounts) instead of using the SMB client.

The Tvheadend server addon is also present since this morning https://addons.libreelec.tv/12.80.6/ARMv8/…ce.tvheadend43/

K22/LE13 supersedes all the advancedsettings.xml cache tweaking (that most users misunderstand and thus get wrong) with some sensible defaults and also reworks the SMB client. Perhaps update to a current nightly and see if that resolves issues.

Refresh the repo, it's there: https://addons.libreelec.tv/12.80.6/ARMv8/aarch64/pvr.hts/

Ahh yes, Hub = 1GB while WP2=2GB. I'll need to go build that image..

Accessing shares over the Internet? .. I think you need to explain the topology of things better.

Configure /storage/.kodi/userdata/sources.xml and /storage/.kodi/userdata/passwords.xml manually and use password auth on the SMB shares. I have three WireGuard tunnels active and a local NAS, and no issues accessing my SMB shares.

Okay, I'll dig out an N2 and run a test over the next couple of days.

The hardware decoder is reporting missing information in the media; which normally indicates a media problem and not a decoder problem. FWIW, i'm running my own RPi5 development image (LE13 not LE12) with a broadly similar setup and I don't see the same errors with a wide selection of test, broadcast, and self-ripped 10-bit HEVC media.

Feel free to test https://chewitt.libreelec.tv/testing/LibreE…-12.90.1.img.gz - make a backup of /storage/.kodi first as Kodi does not support downgrades. There are also some binary add-ons missing in the repo that image uses right now, but that will resolve itself over the next 24h or so as they are built and published.

If you remove the eMMC module (to ensure it's not used) and create a new SD card from a current image, will that boot?

How have you determined that it refuses to start? .. do you have a UART cable connected allowing you to see that output stops at a specific point (if so, which point, share logs) or simply you see nothing on the screen? .. which usually means the OS is running but something stopped Kodi from starting (meaning you can SSH in and share logs).

Put Kodi in debug mode and then run "pastekodi" to share the Kodi and system log after OOM kills Kodi again. I've also seen some OOM events in recent days; albeit on an RPi5 and RK3588 device that are running my own LE13 development images which have little in-common with the LE12.2 codebase so no guarantee it's the same issue. NB: the logs aren't going to reveal the source of the problem, but will contain info on wider Kodi configuration which might be helpful.

Quote from GloriousShield3576

ailed to start display.service. If that is of any importance. I didn't find it in the log.

This is harmless, there is no VFD display found. You can stop with systemctl disabled display && systemctl mask display

There is no mirror redirection for add-ons, and these days we don't block any IP/CIDR ranges either, so if the device cannot connect to the repo the issue is likely something on your end.

FWIW, I have no issues downloading add-ons on an RPi5 here, and RPi4/5 use the ARMv8 add-on repo so that's correct.

Have you tried force-refreshing the repo in Kodi?

In the absence of any technical detail (debug logs and such) .. no idea what the issue is