Posts by chewitt

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.

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

Quote from sky42

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.

You can cross-grade betwen Generic and Generic-Legacy images with the caveat that all binary add-ons compiled against graphics libraries will need to be uninstalled and reinstalled as the graphics stacks in the images are different and incompatible (Generic uses GBM/V4L2, Generic Legacy uses Xorg/X11). As part of that change you need to clear the package cache in /storage/.kodi/addons/packages as Kodi checks the cache for matching filenames before downloading from an online repo; if you don't clear it you'll be reinstalling the now-incompatible add-on that you just uninstalled.

VNC should work in the Generic Legacy image.

Most client applications will generate multiple concurrent sessions in normal communications with their server target and thus use randomly assigned source ports to distinguish each session.

Some background reading: https://www.geeksforgeeks.org/difference-bet…stination-port/

EmuELEC images are based on downstream Amlogic vendor kernels (CE not LE) which means device-tree files are not compatible with LE images using mainline kernels.

2024-02-05 22:57:56.439 T:970      info <general>: Running on Amlogic Meson GXM (S912) Beelink GT1 Ultimate with LibreELEC (official): 11.0.6, kernel: Linux ARM 64-bit version 6.1.38

^ That's not the LE12 image from my share. To share blame I'm also guilty of saying "debug log" when I meant "pastekodi" (or show the dmesg log) as I need to see the system boot data not Kodi things. Sorry..

FYI, this is the patch submitted upstream. I've noted that while the NIC 'works' for you the "-32" errors being logged show something is off and these will need to be resolved before changes can be merged:

[1/2] net: asix: add 0b95:1790 to AX88179A device list - Patchwork

As I don't have the hardware I'll need you to do more testing - once I figure out how to implement the next-steps suggestion from the mailing list.

The cec-ctl/cec-client/cec-compliance tools are there. You'll need to Google for help though.