Posts by chewitt

The "not supported in this forum install2internal script" repurposes two Android partitions for /flash and /storage. I forget exactly which ones are used but let's assume /system = /flash and /data = /storage. The goal of the script is to not mess with the Android partition scheme (some of which is intentionally hidden from Linux to stop users from bricking Android) so you are stuck with the sizes the original Android ROM for the box implemented for /system and /data (in your case, 4.5GB). It is possible to repartition the internal storage to create more space, but this is a non-trivial task using low-level tools (not normal userspace utilities) and it's not fun to resurrect devices or spoon-feed complex instructions to their pissed-off and panicing owners when things inevitably go wrong and the device is left in a "bricked" state. Hence we avoid the entire issue by not supporting install2internal. If you run from internal storage; whatever you problem is, it's not our problem.

To provide more info: The OS boots from KERNEL (the Linux kernel) and SYSTEM (userspace). On devices with more than 1GB RAM SYSTEM is expanded into RAM to create a virtual (read-only) filesystem. The /storage area has nothing to do with SYSTEM or the use of squashfs, so you cannot gain space by removing squashfs from the LE image. It is possible to create images that do not use a squashfs filesystem; but then the contents of SYSTEM have to be installed to internal storage not RAM, which will reduce the internal space available for /storage.

TL/DR: if you can't solve the issue yourself (as we don't provide guideance or support for the activity) you are stuck with 4.5GB and the best solution for everyone is that you continue to boot and use LE from the SD card.

[TOSHIBA]
path = /media/TOSHIBA
available = yes
writeable = yes
browseable = yes
public = yes

See if this ^ works. I've added available = yes as per the default shares we provide. Also note that modern versions of Windows require SMB auth to be enabled.

NB: The correct way to add the share is to rename /storage/.config/samba.conf.example to /storage/.config/samba.conf and then make changes. You need to reboot to effect the change. This is then copied to /run/samba/smb.conf during boot and used as the active Samba configuration.

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.