Posts by chewitt

RPi3 and RPi5 have completely different display hardware so the comparison isn't particularly relevant. Anyway..

Boot the RPi5 board using the latest LE13 nightly and update firmware. If there's no improvement, remove the SD card and boot the board. The firmware will show a bunch of display info on the screen - take a pic and share this. You can also share the EDID file that you captured so the RPi developers can have a look at it. NB: EDID capture only solves the problem of the RPi board being turned on before the TV (so it thinks the TV is connected). If the board dislikes the EDID data (or more often, there is a problem with the EDID data) capturing the file doesn't magically fix anything.

Our distro packaging assumes SYSTEM is a squashfs file, and thus there are dependencies/assumptions about squashfs all over the place. What's the actual problem that you are trying to solve?

Nothing running an upstream kernel supports HDR10+ or DV .. but capabilities exist in devices with downstream vendor kernels. The de-facto Team Kodi recommendation for a device that receives regular updates from its vendor and supports everything is an nVidia shield, athough I'm not a big fan of Android and the shield box(es) have been around for aeons now (older ones are dated). Another option would be the latest OSMC vero box as Sam recently figured out how to handle DV media without an HDR10 fallback.

I've sent you a PM on the topic. In short, share a config for me to play with and I'll see if I can get a connection working.

Quote from w46n3r

Oh well. Intel could at least point us which AVR it used for testing (if any). At the very least it would serve as a starting point for us to begin bothering Denon/Marantz about it.

Go ask them then. I doubt they are using an AVR though, and it shouldn't matter what brand (or whether one is used) as the issue is unlikely to be related to the HDMI display device and more likely to be related to DP to HDMI converter hardware/firmware or some issue or inefficiency in the driver that results in video+audio requiring more bandwidth on the HDMI connection than the current chain provides, resulting in audio dropouts.

Your Ubuntu image will be using the Allwinner (downstream) vendor codebase. It would be a good first-step to compile the latest Kodi for Ubuntu and understand if (and how) it runs there. These days LE is heavily oriented around a modern kernel and overall codebase that supports GBM/V4L2 graphics and this is often the opposite of what vendor codebases provide.

LE is not derived from any other OS and is loosely based on Linux from Scratch principles: https://www.linuxfromscratch.org

The wiki has basic buildsystem instructions on how to self-compile: https://wiki.libreelec.tv/development/build-basics

Our buildsystem is full of prior-art and acts as it's own instruction manual. One of the trueism's of the project is that people with the right skillsets/background to succeed with device bring-up/porting occasionally show up with esoteric questions on distro packaging or some compile issue, but they never show up asking how to approach the task as for them it's obvious and they're already neck-deep in the required changes. At the risk of being "Mr Negative" on the idea: I can tell from what and how you're asking that you're in the wrong camp (as I would also be .. it requires non-trivial effort).

Quote from Degeurige

LE13 not al used addons are working.

Do we have to guess which ones?

echo "sleep 10" > /storage/.config/autostart.sh

Kodi only checks for audio hardware at startup and LE boots fast, so run ^ that and reboot to ensure audio drivers have finished loading and the hardware exists before Kodi starts. No guarantees that's the issue.

Just take the confs from the VPN provider and tweak them to work on LE instead of Ubuntu or whatever distro is documented on their help pages. The confs are normally self-contained with certs/ca details embedded. I'd expect only paths might need changing.

There's no special/secret repo that we're sandbagging support for that chip in .. support doesn't exist and you need to adapt Linux kernel drivers for H6 and H616 to the H313 hardware and/or author new drivers for anything missing. There is no guide for how things are done, only prior-art from the Allwinner BSP codebase as an example: mostly an example of how to write low-quality code that needs to be rewritten for upstream frameworks, standards, and acceptance.

We'll be happy to test anything you come up with.

Use path substition: https://kodi.wiki/view/Path_substitution

tequomo there are no geolocation restrictions on the addons server. The curl request also shows "failure to connect" which is different from a "connect and server rejected" message you'd see if we were blocking. The issue appears to be at your end.

I'll have to have a look in older branches then.

Reducing the number of drivers being inluded reduces image size and build time, that's no problem. And yes, you'll need to enable the kernel driver in projects/Generic/linux/linux.x86_64.conf - the PR that I linked only adds the userspace Xorg bits.

If a file is marked hidden in the remote filesystem, it's up to the client (app/OS, etc.) browsing the remote filesystem (over CIFS/SMB) to show the hidden files. It's not a server side configuration.

On most Amlogic devices you hold the recovery button, apply power, release after 2-3 seconds, then you see the LE boot splash once KERNEL has been booted. Some devices need 1 second, some 6-7 seconds. I've no idea what you box needs

Box vendors can add a custom boot splash to u-boot (although most do not because it requires effort) and to customise the Android boot splash (most do, because it's simple). I've no idea which one you see

If you box does anything different or needs some different process .. it's impossible to triage what's required without connecting a serial UART device to the board so we can see what happens or fails in the early boot process. That requires a) having a USB serial UART tool, and b) opening the box up to install it, which often requires wires or pins to be soldered to the board. Otherwise we are blind, and blind guesswork is a recipe for frustration not success.

The 'Android' and 'LOST.DIR' folders were created by Android during recovery boot, it's harmless.

Install the add-on and then exit/reconnect over SSH and the stress-ng binary should be in the default $PATH.

Or run openssl speed -multi 4 .. that usually does the job.

Johpin I'm not sure this is complete, but it might be helpful: https://github.com/LibreELEC/LibreELEC.tv/pull/5917