Kodi has a comprehensive wiki here: https://kodi.wiki/view/Main_Page and a reasonable amount of LE specific things are covered here: https://libreelec.wiki .. there are no tutorials largely because it's an effort to write them (anyone could contribute them to the wiki but nobody does) and there are lots of use-cases (so more effort).
NB: It's generally easier to ask a specific question and then people will give you specific help and answers.
RomanHT You didn't understand the answer and need to read up on rsync. In short: as long as the other device has SSH enabled rsync can push/pull files to/from it without needing to mount a remote filesystem first. You can also mount and then sync between the local filesystem source and local filesystem (remote) target destination.
If you enable Samba sharing of removable media AND configure samba.conf .. the OS adds a share, and then you manually added the second share. Delete /storage/.config/samba.conf and reboot and it should just work.
If you have the original Android ROM image for the box feel free to experiment at your own risk in the knowledge that Amlogic burning tool can always recover the box to its original state. If you don't have that ROM, don't attempt anything.
Chrome is only available on Generic-legacy, because it needs X11 as display server.
I would assume he knows that since he tried to boot Legacy.
basubasu see if adding something like video=HDMI-A-1:1920x1080M@60 to kernel boot params in syslinux.cfg has impact. If not, add ssh to boot params so you can login over Ethernet to run "pastekodi" and share the log URL generated. The rest of the OS will be functional even if Kodi/Xorg has an issue with something.
the non-legacy generic and generic nightly install and run just fine
You have a working system then. What's the problem?
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 = yesSee 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.
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).
LE13 not al used addons are working.
Do we have to guess which ones?
echo "sleep 10" > /storage/.config/autostart.shKodi 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.