Posts by chewitt

I'd start with trawling the Radxa forums and refererring to upstream kernel submissions. RK3399 is pretty mature at this point so as long as the device-tree files are in the kernel (or submitted so can patches can be picked to a self-built image) .. things probably work. That's a rather vague answer but Radxa have been breeding/iterating boards a lot in recent times and it reached the point where tracking all the variants and sub-variants results in

Current state of upstream is being tracked here:

mainline-status.md · main · hardware-enablement / Rockchip RK3588 upstream enablement efforts / Notes for Rockchip 3588 · GitLab

Collabora GitLab

gitlab.collabora.com

HDMI exists in downstream kernels but wasn't reworked and submitted upstream yet, and there are media codec bits missing. AV1 was submitted (to asssist completion of a work package for Mediatek SoCs) but other codecs are still missing. As usual there's a reasonable amount of inheritance from earlier generations but always some changes to work though, and because the primary interest on these SoCs in the Linux world is industrial/IoT applications the media stuff is nearly always done last.

TL/DR; previous statements are still valid

Log shared is nNot a debug log .. so not enough info on media and playback to investigate.

I'd suggest starting with a current and vanilla state LE12 nightly (newer kernel/drivers, no config) .. put Kodi in debug mode, then reboot and run "pastekodi" over SSH to generate a log URL to share here.

It would be nice to have a binary add-on that installs the command-line tools and make them accessible. The challenge historically is that flirc deliberately ships only pre-compiled versions of their binaries, and the way those are (not) versioned (and the lack of sources) would require us to break rules around the content we allow in our binary repo (only things compiled from source, and properly versioned). The workaround for that would be for flirc to run their own repo (to their own rules) and we could embed their repo installer in our repo instead, but that needs some new tricks to be learned on the flirc end. It's something I'll chat to Jason about.

Those customer RR builds are nothing to do with the staff team so we don't provide "support" for them. For that you really need to find the creator .. who appears to have disappeared.

The issue is, the 10.80.12 repo is (was) a pre-release repo and once LE11 shipped we updated the repo version to 11.0.0 and eventually some cleanup removed all the pre-release stuff to save disk space. Hacking an 11.80.2 repo onto the system is a wrong move since that's a pre-release repo for LE12 so things might not be too compatible with LE11.

The better solution would be to hack the current 11.0.0 repo in the image; although whether that's fully compatible with the pre-release state of the rest of the image still isn't something we can answer.

The correct solution would be to rebase the RR changeset on current LE11 (not a pre-release version) and build a clean image.

The system is up for some time before the crash so it's unlikely to be something with the core OS, and more likely to be something that result from use. Hard to say what though, the current logs don't reveal much (Kodi log is not a debug log).

Flirc software needs a "desktop" OS to run the IR receiver setup app; Windows, macOS, or something like RaspiOS. There are some command line binaries/utils too, but last time I tried to run those they didn't work on LE - although I'll admint that was more than a few years ago now so things might have changed. I did try to download them and test before replying, but LE12 (which I'm using) uses aarch64 (64-bit) userspace and the tools are armhf (32-bit) so don't run - I've pinged Jason (who runs flirc) about that.

[   14.878121] ntfs3: sda1: failed to replay log file. Can't mount rw!

In 99/100 cases when a "Windows" flavoured filesystem is being used and either won't mount or goes read-only, chkdsk.exe is the answer.

Hard to comment on what the issue is from that info. I'd suggest approaching it as an upgrade opportunity: start with a new installer USB but interrupt boot and type "run" instead of allowing to default to install (and running the installer). This should give you a working LE install on the USB, from where you can a) prove the current release boots/runs okay on the hardware, b) copy/backup any essential config you want from the original installation, c) figure out what update or reinstall path is appropriate.

The TVH client addon data will be in /storage/.kodi/userdata/addon_data/pvr.hts .. so you will need to enable support for "hidden files and folders" in Kodi GUI settings else the file manager will ignore the .kodi folder (in linux the . prefix denotes a hidden folder).

You should be able to connect a serial UART device to the GPIO header on the board, see https://pinout.xyz/pinout/uart for the pinout.

What distro/version and host hardware are you building on?

You need to repair the NTFS filesystem on a Windows box with chkdsk.exe, and then unmount cleanly and it should work.

The "clean install" advice is all about mitigating add-on update problems that can occur with the Python2 > Python3 change from LE10 and later. If users have a simple setup there's generally no problem with the direct update. However if users have third-party, or not installed from a repo that contains the updated Python3 version of the add-on things can crash, and if that happens it can be challenging for less technical users to self-recover and we're not staffed for the effort. If your update went fine.. "if it works, don't fix it" applies

Quote

Is there any way to get it both (Boblight AND hardware decoding)?

Yes/No. Devices that run GBM/DRMPRIME graphics do not support software grabbers at the current time, and I have low expectation of that changing anytime soon as it will be a non-trivial feature to implement. Ambilight/Boblight setups either need to stick with older images that use legacy display pipelines, or switch to an external HDMI grabber (which being a hardware solution, has no dependency on software).