Posts by chewitt

I'd create a system.d service in /storage/.config/system.d to run the "route add" commands as systemd allows you to add dependencies to accurately sequence when things will occur, e.g. after network-online.target but before kodi.service (assuming the routes are needed for Kodi things).

I must have been asleep when I read the first post. if you want to "install a greek build" you're probably in the wrong forum for futher help. Our views on builds and wizards and piracy in general won't be compatible with your goals.

SSH into the box and run "tail -f /storage/.kodi/temp/kodi.log" and watch the output on-screen stream past. When it stops, Kodi crashed.

Add "ssh" to kernel boot params in extlinux.conf and then you should be able to SSH in and collect some logs, and if you're lucky there are some error messages that indicate what's going on. If not the collective shrug is "no idea" .. we're not box lairvoyants

If you look at one of the early attempts at PR'ing support project: add wireguard package by chewitt · Pull Request #3498 · LibreELEC/LibreELEC.tv · GitHub I was using a homegrown wg-quick script that works (in a basic sense). bash isn't the only challenge with the upstream script, iproute2 is missing capabilitties too.

Having never knowingly seen the cpu-z app I can't say, but as a rule Android only tells you what the manufacturer exposes in the device-tree config and box vendors have a reputation for faking info .. esp. with "MXQ" box which are cloned and sold by many different manufacturers. The one true method is, you open up the box and share post a high-resolution image of the front/back sides of the board so we can see what chips are on it

We suck at guessing so you might need to explain what kind of wifi is in the box?

HW acceleration is still a bit work in progress. It was working .. then kernel side was reworked around a newly finalised API late last year and that needed a bunch of rework in FFmpeg which has taken an age to happen. It is now being very actively looked into, but we didn't have a eureka moment that results in publc-usable code yet. However, on VIM3 you should be able to disable HW decoding and it will decode all 1080p content happily - only 4K will be too much. NB: USB Burning Tool uses a proprietary Amlogic "img" format, so not possible to use that.

The challenge with routing is that connman manages the WireGuard interface, so you can make changes, and connman can simply overwrite them again. Connman support for WireGuard is still rather new and initial testing was limited to specific use-cases. Now that a wider audience started to use it other ways, we're sure to find some things that need code changes. I'm sure it will be resolved, but don't ask when.

I've reported the PresharedKey issue so that bad config handling can be improved. The routing issue remains unresolved. It's been reported but the main connman developer working on WireGuard has been offline for a while. He's resurfaced in the last week so hopefully we might see some progress.

It's been reported to connman devs. The main one who's been working on WireGuard support has been offline for a bit for good reasons, but he's resurfaced so I hope it will progress again soon.

This should probably be reworked as a GitHub repository so the contents are under version control and are in a flat structure that would be suitable for programatic use within distros. This would also allow users to submit new/corrected files. I'll have a think about it. NB: All meson-ir files should be converted and submitted to the upstream kernel so ir-remote details can be included within device-tree files (which also need submitting) to improve the out of box experience.

It sounds like the USB died (or is dying). This would also explain the original issue.

I have low expectations that future CM boards will allow Slice upgrades. I'm not really able to expand on why that would be the case.

LE does not include/support lvm in any image so I'd guess the /dev/mapper devices aren't going to exist.

I use ours (USB/SD Creator) but Etcher/Win32DiskImager/Rufus/etc. all do the same thing.

There are two ways to boot the VIM3 .. from SD card, from eMMC.

From SD card: write LibreELEC-AMLG12.arm-9.80-devel-20200426060538-38764c8-box.img.gz to an SD card, download Dropbox - u-boot.ext - Simplify your life and place it in the root folder of the SD card, then put the VIM3 board in update mode, it will find the SD card, and LE will install.

From eMMC: follow the SD card install procedure, then run the following commands:

cd /storage
wget https://test.libreelec.tv/LibreELEC-AMLG12.arm-9.80-devel-20200426060538-38764c8-khadas-vim3.img.gz
emmctool w LibreELEC-AMLG12.arm-9.80-devel-20200426060538-38764c8-khadas-vim3.img.gz

This downloads the eMMC install image to /storage and writes it to the internal eMMC storage, overwriting Android. Now power off the board, remove the SD card, and power on again. It should boot into LE on the eMMC. If you ever want to reinstall Android to eMMC, Khadas have an SD card tool called krsecue that will help you do this.

USB/SD Creator works fine for writing SD card images for all the test images (not just KVIM) but install to eMMC is a two stage process.