Posts by chewitt

RPi4 can run Android and RPi4 can support the RPi TV HAT so something could be possible; but exactly what and how is way beyond the Linux + Kodi scope of the LE forums so I'd suggest you take the questions to the Pi forum.

Update the RPi5 to https://chewitt.libreelec.tv/testing/LibreE…h64-11.80.0.tar with the ASIX adapter connected and share the log URL from "journalctl | paste" please. I've made the drivers built-in to the kernel (=y) instead of using loadable modules (=m). That's not necessarily the right fix, but takes udev (which I think is the issue) out of the equation temporarily.

Dies ist ein englischsprachiges Forum

Nope.

It's not a Kodi debug log so it's missing info on codecs and format, and by snipping out the bits you thought were relevant you've removed all the useful environment info that we'd like to see.

I'd suggest testing an LE12 nightly as LE9.2 is no longer maintained. Even if we confirm a problem, it's not going to be fixed.

No idea what the issue is, but you already found the solution (out first move would be to try a curretn LE12 nightly)

Commit device-tree changes for the different audio setup to an upstream kernel git source (Linux 6.6 for RK boards) then use "git format-patch" to create a diff patch that can be imported to "projects/Rockchip/patches/linux" in the buildsystem. When you build the patch is applied and the resulting dtb file has the changes built in, so no need to mess around with true overlays.

This wiki article describes how to self-build: https://wiki.libreelec.tv/development/build-basics

This describes workflow to enable a different kernel module: https://wiki.libreelec.tv/development/git-tutorial

LE12 is stable and firmly on the "sooner than later" horizon.

nVidia drivers now support MESA/GBM which can do HDR, but only through Wayland; which official LE doesn't use, and even if it's made to (with a self-built image) Wayland doesn't support dynamic refresh rate switching so the desktop refresh rate is fixed, e.g. 60Hz so you may find media playback has glitches and such as 23.976Hz or 25Hz content is adapted to that rate. Or you can use Xorg, but that doesn't support HDR at all. Oh, and Kodi only supports VDPAU not NVDEC.

I haven't used x86_64 hardware for a decade so I'm not going to recommend alternate GPUs (in part because vendors breed new stuff faster than I can keep up with it) but the general advice is: Intel = #1 choice, AMD = #2 choice, nVidia .. distant #3 choice.

Please retest with a current LE12 nightly. Thanks.

Add "video=HDMI-A-1:1920x1080M@50" and "ssh" to kernel boot params in cmdline.txt and it will force initial HDMI output to that resolution/refresh and force the SSH daemon to start so you can access the device to investigate.

Quote from sky42

update 1st to a sky42 release with a device that official LE knows

The "error" message on-screen is telilng you exactly what to do: create /storage/.update/.nocompat and put the update file there again and reboot to update.

I've always understood the Ultimate boxes to use Broadcom modules. If it works fine, use it.

If you follow the recommendations in the wiki, the desktop is set to 1080p and Kodi scales media under 1080p to 1080p (easily done, and Kodi handles this well) and the TV scales 1080p to the native 4K panel resolution. If you play 4K media Kodi will switch to 4K for playback and the TV has nothing to do.

NB: 3840 x 2160 modes should be used not 4096 x 2160, as these are better aligned to media dimensions. The 4096 modes will often result in black bars being visible.

RK3328 has VC1 hardware decoding capabilities in silicon, but AFAIK nobody implemented support for them, so decoding will be done in software and most low-power ARM boards are lacking the necessary CPU grunt for the task.

Not possible. Kodi doesn't support streaming to an AirPlay target and the HomePod doesn't support BT or have a physical line-in port that you can connect the RPi5 to. I've been an Apple user since 1996 and love lots of their tech, but for this kind of thing the closed-source Apple ecosystem sucks balls.

I'm not sure that makes much sense. The TV HAT is designed for the physically exposed 40-pin GPIO arrangement on an RPi4 board and while S905 does have GPIO capabilities the WP2 doesn't expose that header or the required pins easily so you'll have a major soldering task to wire something up; and then you need to backport a modern kernel driver onto a decade-old Android oriented 3.14 vendor kernel (full of low-quality vendor code) which will be quite the software task. It would be massively easier an long-term much easier to maintain the HAT running natively on a recycled and inexpensive RPi2/3 board.

The LE12 image in my share has some additional fixes for playback things, but nothing earth-shatteringly important. I need to bump the kernel for LE12 sometime soon.