No idea what the issue is, but you already found the solution (out first move would be to try a curretn LE12 nightly)
Posts by chewitt
-
-
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.
-
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.
-
WeTek still manufacture devices, but these days their business is focussed on ISP/Telco and Hospitality IPTV systems. Their forums are long gone, but there are still users here and LE still has current releases that run on their hardware (with some caveats) and I have Android recovery images and raw "dd" backups for the Hub and WP2 boxes in case anyone ever wants to reset them back to factory spec.
-
I've never booted either of them (someone else's problem) so can't really comment
-
It's supposed to work (has not been intentionally broken) but everything in the Bluetooth world seems to have a lot of moving parts and dependencies so I wouldn't be entirely surprised if it was broken.
Let's start with asking for the usual debug "pastekodi" output
-
ah my Intel issue has labels now.
And a reply: https://gitlab.freedesktop.org/drm/intel/-/is…99#note_2270390
Support works a triage script like all support teams: start with testing latest to eliminate bugs that have already been fixed, then if the issue still exists start digging for more. Be responsive, as they have hundreds of other things on their to-do list
-
The patch I sent upstream adds 0b95:1790 to the "USB_NET_AX8817X" driver but there's a separate "USB_NET_AX88179_178A" driver in the kernel which already has that combo inside, and both drivers are enabled in our kernel config. This means the patch I sent to the list is fundamentally wrong (as it's the wrong driver) but now we need to explain why there's no attempt at probing and loading the correct driver in the logs.
To ensure I'm looking at the right thing. Please update the RPi5 (not RPi4) to the image in my test share. This 100% doesn't contain any patches, and I want to see output from "dmesg | paste" after booting with the ASIX adapter connected before power-on.
