Posts by chewitt

Kodi on Android has massively improved in recent years, driven by Kodi forcing and adopting Google standards, and this reflects in general usage stats (Team Kodi doesn't track active installs, but we see download volumes and forum traffic). The weak link is thus the underlying Android kernel codebase for any particular vendor and/or device combination, and how it implements or ignores those standards. If the device follows standards, Kodi runs well. If it includes lots of hacks to make specific apps (that don't follow standards) work better, that often degrades the experience of other apps. TL/DR: there's not really an answer, but you can install and try for $free.

Add "ssh" to kernel boot params and the daemon is forced on during boot so you can login, then "journalctl | paste" to pastebin the system journal.

Just boot from the SD card. The OS runs in RAM so while there is a difference in I/O speeds, it's not that significant.

warning <general>: Failed to get an OpenGL context supporting core profile 3.2, using legacy mode with reduced feature set

This is a warning not an error/failure. It simply documents that the GPU doesn't support Core 3.2, but the minimum requirement for Kodi is 2.1 which this site confirms is more than covered: https://people.freedesktop.org/~imirkin/glxinfo/#v=Mesa%2018.0.0. The site is not updated for current mesa (23.x) but generally things don't regress much.

I've tested 12.0.2/340.108 in the last week when poking Nouveau and it worked fine with my GT520 card. That points towards it being an issue with older cards. If it also doesn't work with Slackware, that also points towards a driver issue and not something to do with distro build/packaging.

The kodi debug log isn't useful here as the issue resides lower in the software stack. Was anything recorded in the system journal?

Quote from Wetek_D

Really dont know how to do the "dmesg | paste" sorry.

You managed to type "dmesg" and hit enter. All you had to do was type "dmesg | paste" and hit enter.

[ 1.543265] mmc1: Card stuck being busy! __mmc_poll_for_busy
[ 1.544665] mmc1: Failed to initialize a non-removable card

The eMMC storage fails to init ^ and thus isn't visible to the OS, so cannot be addressed. No idea what the underlying issue is, but normally the issue with Android boxes (not specifically WP2) is the chips go bad and throw errors. On the upside, it's failed but still allows SD card boot, which is better than starting to boot and not being able to continue (which can also happen).

The WP2 "board" image you are using cannot boot with the factory Android u-boot on EMMC, so either you wiped/zero'd EMMC to use the image, or the EMMC chips have failed which means the OS cannot detect Android u-boot; thus allowing it to boot upstream u-boot from the SD card.

I'd guess the EMMC chips have gone bad. Share the URL from "dmesg | paste" and we can probably confirm.

RPi4/5 have a single i2s audio interface input, and a single audio driver that supports multiple cards, each with an HDMI connector, and the driver can route audio to either or both cards. The labelling is correct and clear; but alsa is one of the Linux "dark arts" as the terminology (and topology) of things is particularly challenging to understand.

Merged.

Quote from rosede

Any suggestions?

RPi boards simply have rubbish wireless. Use Ethernet. Use an WiFi bridge device that presents Ethernet. Use external dongles with a proper antenna. In short, do anything except try to make the internal WiFi work.

I'm not aware of any project staff that use Chromeboxes these days. Have you looked at the MrChromebox site?

Are there any specific errors with the update process?

Quote from Da Flex

According to aplay output, you've connected both RPi4 HDMI ports. Unplug HDMI-1.

Nope. The aplay -l command does not show connected state, so it is not showing something on HDMI-A-0 or HDMI-A-1 ports.

Here's the output from my RPi5 which 1000% only has a single connection on HDMI-A-0:

RPi5:~ # aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: vc4hdmi0 [vc4-hdmi-0], device 0: MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: vc4hdmi1 [vc4-hdmi-1], device 0: MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

PLEASE stop guessing at answers.

Remove all the config.txt changes (or create a new/clean SD card) and connect the HDMI cable to a different HDMI port on the TV and see if that works. I'd guess no, in which case you need to replace the Type-C to Type-A adapters with a proper Type-C to Type-A cable (no adapters). Adapters are often designed for use with desktop monitors which have no speakers, and thus the HDMI chips used inside them can omit wiring or support for audio to create a cheaper product. I can't 100% guarantee that's the issue, but from experience it's more likely to be something physical like that than anything in software.

S905X and S905W are ARMv8 chips but it's common to see 64-bit kernel and 32-bit userspace on Android devices. The older LE11 (arm) image uses the same combo. LE12 and newer now run 64-bit kernel and 64-bit userspace (aarch64). The userspace change is not the reason why the older image boots and the newer one doesn't; it will be something lower level, and the only real way to understand what is or is-not happening is to see the initial u-boot and kernel boot stages via the serial UART log. That requires you to have a USB UART adapter and the UART pins to be physically on the board to connect to - the pads will be there, but cheap boxes often need the pins soldering and they were omitted to reduce manufacturing cost.

Use an official LE13 nightly or image from my test share https://chewitt.libreelec.tv/testing/ as that's the active codebase for dev work. The S905X board should boot with the p212 dtb file in the "box" image. The S905W board should boot with the p281 or Tanix TX3 mini dtb files.

There are MXQ boxes from Amlogic, Allwinner, and Rockchip and that photo doesn't enlighten us (although the 45 degree rotation on the chip makes Amlogic unlikely). So before we go any further, we'd need to understand the specific chip on the board, and ideally see a boot log from the original vendor OS full of driver information.

Quote from lipo_pan

So i would like to ask if the support of output to both hdmi is supported out of the box or not?

RPi4/5 hardware supports use of both HDMI outputs on a conventional distro that uses X11 or Wayland. In that scenario Kodi runs as a full-screen app and you can select the single display to use, but Kodi does not support dual-output (mirrored output) and AFAIK this is true for all OS, not just Linux. In LE, Kodi runs 'on the framebuffer' with no window manager so we only support output to a single display device. TL/DR: Not possible, you need to use an external splitter.

Fix is merged .. the add-on should update in the next 24h

The majority of reports are from RPi boards but that simply reflects the demographics of a project where 80% of all users have an RPi board. The issue is probably about radio/wireless features in the network and appears to be influenced by signal strength.

It's been flagged to upstream maintainers who are keen to help resolve the issue. Debug logs from ConnMan and IWD and 'iwmon' output when the issue occurs would be useful.

Quote from atirage21

Newer chips as S922x dont have HW acceleration with panfrost.

On ARM boards hardware video acceleration has nothing to do with the GPU, and the difference between OpenGLES 3.1 and 3.2 is frankly not important for LE/Kodi use. There is simply no good reason for LE to use a proprietary closed-source blob that requires maintenance effort over an open-source in-kernel option that requires zero effort. Abandoning libmali once lima/panfrost were viable was a no-brainer (and smart) move for the project, hence we've done it. You're welcome to disagree of course (free world and all that) but your view is firmly in the minority around here.