Posts by chewitt

Sudden power loss denies the OS (and services running) the opportunity to shut-down gracefully/cleanly so my uneducated guess is that some kind of session/state data is not cleared and it's presence during boot results in something like ConnMan not seeing that a new connection is required; as it believes one already exists or something of that nature.

The way to investigate that kind of wild-ass theory s starting ConnMan in debug mode (add 'debugging' to boot params in cmdline.txt) and with persistent logging enabled from the settings add-on, as ConnMan debug output is quite verbose and the default system log size will result in log rotation before you've had a chance to login and look.

ConnMan logs are somewhat human readable .. look for errors. Feel free to pastebin them somewhere (don't upload here please).

Quote from treysis

The problem exists since at least 11

This eliminates iwd from suspicion as LE11 uses wpa_supplicant and LE12 onwards uses iwd.

So it's either something in ConnMan or perhaps the underlying brcmfmac kernel driver. I'd be thinking in the direction of ConnMan first as its responsible for managing connection state. Updating to an LE13 nightly will bump ConnMan (and the kernel driver) to the latest versions available. There no guarantee that solves anything, but it would be a local step forwards.

Quote from emelsky

Sorry I really do not know how to edit previous posts

Post editing is time-limited for normal users. After about 5-10 mins post contents are fixed. It stops spammers posting harmless comments on existing threads and then editing the post hours/days/weeks later to include URL links to whatever garbage they are being paid to promote this week.

If you don't like exposing weak services to the internet, use WireGuard to put the client device on the local network.

I'd keep it simple: add the CA to cacert.pem so the client trusts the server and then authenticate the user over WebDAV within a secure TLS session. I get that mTLS can fail things earlier in the connection sequence, but that's enough to avoid issues.

Quote from Papalapa

"[FAILED]Failed to start display.service". Could be this the reason?

I need to refine the VFD service so it doesn't start when the board/box has no VFD configured. It's harmless and can be ignored.

You will need to provide a Kodi debug log that demonstrates the problem for anyone to comment on playback issues. Esp. with mkv being a container format (we have no idea what's inside the container).

In short, no .. there has never been a LibreELEC release as we dropped i386 support back in OpenELEC days.

I don't believe mTLS is possible. Kodi supports the following TLS options via URL append:

xbmc/xbmc/addons/kodi-dev-kit/include/kodi/c-api/filesystem.h at master · xbmc/xbmc

Kodi is an award-winning free and open source home theater/media center software and entertainment hub for digital media. With its beautiful interface and…

github.com

Looking wider in the codebase I only find references to defining the CA bundle used for server cert verification. It's typically done using the SSL_CERT_FILE environment variable, although LE uses another approach (as you found in the wiki).

To use mTLS you normally provide --cert=/path/to/cert and --key=/path/to/key in the curl command and unlike the CA bundle curl/libCURL does not appear to support a client cert defined through an environment variable, so Kodi would need code changes to support those being defined, e.g. through advancedsettings.xml config.

I also didn't find any existing references to mTLS in existing Kodi issues or pull requests, or forum threads. So you'd need to make a feature request via that section of the Kodi forum.

See https://wiki.libreelec.tv/development/build-basics for some basic info on the buildsystem. Both distro's use Bluez for their BT things and ConnMan/IWD for networking. Those tools have numerous common code contributors so e.g. how things are persisted end up being very similar. There's no specific info/guides for combining capabilities. Have you thought about using the retro-game capabilities in Kodi?

Quote

ROCK 4C+ is powered by RK3399-T, which is a lower freq version of RK3399, the ram speed should be 666Mhz for stable operation.

ilmich more from Radxa ^

The remote is working via HDMI-CEC?

Quote from py9399

i have to edit config.txt to be able to use analog audio ?

Correct.

Quote from py9399

does this provide a predictable, repeatable delay ?

Probably..

Quote from py9399

if you know places where i can reach other people, i am sur i am not the first one to try this ..

I don't recall anyone doing something similar with LibreELEC before; probably because we are intentionally a 'dumb' client/playback oriented distro. I would expect to find people doing more complicated projects in the Raspberry Pi forum, or if the solution is built around Kodi, perhaps the Kodi forum.

Newer "Generic" LE images contain kernels/drivers that technically support them (sort of, it's still WIP in Linux) but Kodi currently makes no use of either so it's "not supported" for now. In the long term that might change, and it might be a good solution for use with general purpose distros that increasinly use Wayland instead of Xorg; because Wayland does not support the kind of userspace driven mode/rate change that Kodi requires for optimal playback. However, even if Kodi and Wayland do gain support I doubt LE would switch as Wayland increases the code stack (more maintenance) and VRR/Freesync requires GPU + TV/Monitor support which is not guaranteed. TL/DR; even if Kodi gains support it doesn't provide real-world benefits over our current GBM/V4L2 approach.

/storage/.cache/bluetooth
/storage/.cache/connman

Those two locations ^ are where device settings for BT and Ethernet/WiFi are stored in LibreELEC. As Lakka is ultimately dervied from the same buildsystem/codebase as LE it should share the same locations. The content is updated dynamically during runtime and is not intended to be copyable/syncable in the way that you imagine though so no guarantees it will work.

RPi3 boards cannot hardware decode HEVC media so the stolen 720p media being played is probably at or beyond the limits of CPU decoding without overclocking being used to increase CPU capabilities; which needs a stronger PSU and proper cooling.

There are also a bunch of errors in the system log related to the mmc0 device. Either the SD card is starting to fail, or this is another symptom of an insufficient PSU and the system being maxed out.

There are also errors from Hyperion which won't work unless you're using an external grabber as the modern video pipeline used since LE10 doesn't support the software grabber methods used in older LE/RPiOS codebases.

So looks like an under-spec tool failing at the task being asked of it, that probably needs a spring clean to clear old config.

Quote

The Okdo ROCK 4C+ is authorised and manufactured by RS Group previously. So it's a legal clone. For the boot issue, do they use the rkbin loader or the mainline u-boot SPL?

From Radxa ^ .. so if the board specs are slightly different we (and upstream) probably need a separate "okdo-rock-4c" device so that u-boot can be built with the correct specs or tooling and/or someone needs to submit support upstream.

In case it's not obvious, i've only recently taken an interest in Rockchip boards and I'm still learning what tooling and juju is needed to boot them.

I've asked Radxa what they know about these boards. Let's see if they are official (and how they should be supported) .. or not

The root users $HOME directory is /storage so cd will take you to /storage and there is no separate 'storage' folder.