Posts by chewitt

LE has always required a formatted target. The installer script uses the "blkid" command to identify potential install targets and blkid won't show anything unless the storage has been formatted with a filesystem first. It doesn't matter what filesystem is used, only that there is one.

If you attach a USB keyboard you should be able to run commands. It's attempting to follow the boot=UUID=UUID-5BE6-0135 param to mount /flash and the SYSTEM file to continue booting. The UUID is presumably wrong and boot params in extlinux.conf need to be corrected.

Yes, if you use the correct device-tree file.

ping CvH ^

The main issue with current Amlogic hardware is low-quality kernel source full of bugs and proprietary code and the amcodec interface which has lots of hacks to workaround the bad kernel source. We've cleaned up some major issues over time but there are lots of minor ones that aren't resolved - and won't be resolved (on that codebase). The long-term solution for Amlogic hardware is to move up to mainline kernels. This won't be a magic cure-all (new code = new bugs) but since the underlying codebase will be common to all our platforms (Generic, Raspberry Pi, Amlogic, Allwinner and Rockchip) the process of fixing stuff will no longer depend on someone working up the enthusiasm to poke sticks at a bad kernel source where fixing one thing frequently results in fresh breakage somewhere else. We are months (not years) from making the mainline jump.

NB: I wouldn't read too much into the S912 future story as the situation has changed. Open-source alternatives to the missing libmali are taking shape, we are well engaged with the developers and Kodi support is a mutual goal. I'd estimate we're about six months from a usable solution.

You can ignore the false warning (because os.libreelec.tv is installed) and continue or wait until the next Alpha release is out where we've added a temporary patch to prevent the warning - pending Team Kodi doing something to properly fix the issue.

Has that been flagged to any of the kernel mailing lists?

Quote from chessplayer

Anyway, thanks to you (and all the other active developers) for making it possible for users like me to play with our toys! I do hope that you also profit from donations made to LibreELEC

We profit from the personal experience of participating in the project and having fun, but otherwise we are non-commercial and aim to raise no more funds than we need to cover the project's running costs.

Nope, because decoding and rendering are separate things. Even if FFmpeg supports NVDEC for decoding we still need to render the decoded video via a zero-copy code-path and this is where the issue lies. Kodi supports GBM and nVidia's driver supports a competing "standard" (used only by nVidia) called EGL Streams. So Kodi will need to add another vendor-specific code path just for nVidia. The two logical candidates to do that within Team Kodi are lrusak (who wrote the GBM code) and the main architect fertnetmenta (who maintains VideoPlayer) and so far neither of them are interested.

Could be a while. Our efforts with the RK 4.4 kernel codebase have been a stop-gap until VPU support for the mainline kernel was available and the changes to add this now been submitted so we've started the lengthy process of rebasing against Linux 4.19 - which means no more real-world effort against the 4.4 codebase.

NB: Next 9.0 Alpha will come out with changes to Kodi but nothing much more. We have no plans to release Rockchip Beta or full release LE 9.0 images - Rockchip will remain in an Alpha state until at least LE 9.2.

The StiH206 chipset does not support OpenGL or OpenGLES so it cannot run Kodi. Even if that wasn't a showstopper it wouldn't be worthwhile when a Raspberry Pi Zero (costing $6) has a higher spec and is better supported.

It should be supportable, and if they care about good Linux support for their product they will submit a device tree file to the upstream kernel. If you don't see any submission .. they're just another clone vendor who expects "the community" to do all the leg-work for them.

Any addons that include drivers need to be version bumped after the recent Linux 4.14 > 4.18/4.19 kernel changes to trigger a rebuild against the newer kernel version. It's been flagged to our release manager - thanks for the tip/reminder

Having never owned a Chromebox I can't speak from experience about the process, but I strongly doubt you have to restore ChromeOS to update the BIOS on the device.

It sounds like the problem is with your phone not the LE device - it's the phone's decision to incorrectly route data. We consider the code behind the hotspot feature to be well proven and stable (not thousands of daily users, but a few hundred at least) and if there was a general issue we'd be seeing more bug reports, and we're not.

connman/connman.git - Connection Manager

^ describes how the NTP logic was changed a while ago to resolve issues with Raspberry Pi and NTP calls being made before the network stack was fully active due to slow loading network drivers. It's quite plausible that the first two NTP attempts on Raspberry Pi fail and the third succeeds; which would result in it being marked as the primary active server. The #1, #2, #3 positions no longer dictate which server is primary. Since all RPi are basically the same the 2-fail, 3rd-pass behaviour would be quite consistent.

I'd guess you originally installed OpenELEC a few years ago and you have the older 230MB partition size. We have grown a little over time and and this is now too small. You have two options:

a) Take a backup of the data in the /storage partition and move off-box, reinstall using the LE 8.2.5 image (or current Alpha) as this will create a 512MB boot partition, then restore the data from /storage.

b) Boot from an Ubuntu (or other favourite distro) Live USB image and use gparted to shrink the size of the /storage partition, then move it to create space so the boot partition can be expanded to 512MB or 1GB size.

Either approach gives you the same end result. The reinstall process is typically a lot faster as less data is being moved around. Bonus credit if you update the latest Chromebox BIOS from MrChromebox.tech. Extra credit for doing a selective restore of data from the backup and a spot of belated spring cleaning at the same time

You can experiment with the order of defaults by copying /etc/connman/main.conf to /storage/.config/connman_main.conf and editing (reboot to force the change).

No, because until the upstream graphics drivers situation improves it's not worth anyone's time. You can probably build from the NXP branch but this will be some way behind master now, it needs rebasing.