Posts by chewitt

As a random thing to try .. do you have any USB/external WiFi adaptors you can try?

Have a read of Infrared Remotes [LibreELEC.wiki]

The flirc case has an internal heatsink 'finger' that requires the SoC to be in exactly the same position as the RPi one so I suspect the answer is no, but I can't give you an answer until I finish a work trip in a couple of weeks time. The black case is awesome though..

Backporting media_build driver for support to the older 3.10 kernel is challenging and the main developer who works on that doesn't have a WP1 so the status is probably "could probably work but doesn't and isn't being tested" .. and I doubt that will change. That's probably not the response you'd like but that's the honest reality.

MikeKL the memleaks and other glitches are known to the panfrost developers. Panfrost still has a high overall rate of change and some of the leaks won't be resolved until a proper kernel driver evolves (at the moment we're still using a hacked version of the ARM driver). VIM2 lite WiFi should be able to work with the right combination of firmware/nvram files but VIM2 max was still lacking mainline driver support last time I looked; although that was last summer .. I'll get around to it eventually. No need for logs at this stage.

openssh: drop support for ssh-dss keys by chewitt · Pull Request #3316 · LibreELEC/LibreELEC.tv · GitHub

PROJECT=RPi DEVICE=RPi2 ARCH=arm scripts/create_addon customtest

^ that will build the add-on (assuming the package.mk is good) but this outputs the add-on zip file for an online repo. It does not embed the add-on into the image.

To save me looking at the debug logfile on a phone .. are you using the onboard Pi wifi or an external dongle?

Tos26 the log is good .. and appears to show connman attempting to connect to 0/1/2/3.pool.ntp.org servers. The DNS record for each host returns multiple A records and each time you query the ordering of A records in the response changes (aka DNS "round robin" load balancing). Connman picks the first entry in the list of A records and makes an NTP request to the server. If it gets no response it goes through the list of NTP servers and repeats. If it completes the entire list, it goes into a retry pattern that waits progressively longer before trying the list again. Eventually it hits "95.81.173.74" from 3.pool.ntp.org which responds and the time is adjusted. It will now continue to use that server unless it fails to get a response (and the process restarts) or you reboot the box (and the process starts again).

Connman devs modified the ntp workflow in the last year based on feedback we gave about common ntp failures on Pi hardware. I was involved in that and connman is following what I understand to be updated workflow. I can't explain why you get no response from 3-4 ntp servers before finally getting a response. Some ISP's do block NTP but they're not common and it tends to be a "block everything apart from our own server" and this looks to be more random.

Configure "95.81.173.74" as the only NTP server and reboot. Does that solve (work around) the problem?

If you care about 3D support get an RPi3B+ as the Kodi/Pi codebase has the best support and all 3D media is 1080p which is within the capabilities of the Pi hardware. On everything else YMMV as most maintainers have written 3D off as a fad that passed and it's not really being tested.

LePotato will handle 4k60 and the people behind LibreComputer are committed to good open-source support. Most of their core board development work is outsourced to the same people who maintain the Amlogic sections of the Linux kernel and who are leading mainline kernel work. The kernel doesn't have official reference hardware, but if it did, LePotato would be on the list.

If you're okay with the extra cabling of an external antenna etc. another option is to get a small WiFi router and use it as an Ethernet bridge. It will have better reception and Ethernet connectivity makes it compatible with every box/board device you have today and in the future. Avoiding the "which shitty realtek driver does it require?" lottery is a big win. I have some Apple A1rport's for this purpose .. the later gen ones support ac and I've picked them up for $20 on eBay before, e.g. grubby looking ones that nobody bids on, they clean up fine

For WiFi dongles I've always been a fan of devices that use the ath9k_htc driver because it's completely open-source and it uses an in-kernel driver that's well written and supported. It's 802.11n but not ac though. Avoid anything realtek make that doesn't have an in-kernel driver (which is most of their stuff) else LE10 will drop support when we change from wpa_supplicant to iwd.

You might find a v1 board and v2 board have different wifi chips but that's about the only deviation you'll see from Amlogic's reference designs. It's either going to be a hardware issue, or it's down to crap code/drivers in the older Amlogic kernel. All three distro's are currently using variants of the same crap kernel codebase so are likely to show the same issues. You can try @balbes150's mainline kernel image which uses a completely different kernel, and if you see the same issues, it's probably hardware.

It's not possible to install misc. packages to LE but most useful things in the OpenHAB ecosystem are available in a docker container format and there's a Docker add-on in our repo.

It's technically possible to custom build images with deployment scripts and such embedded, but from past experience a low-tech solution is usually better and I'd go make some screenshots that step-by-step show how to switch the first-run wizard to local language and restore the tar file that's on the SD card. Print the guide out and give copies with the SD card. It's probably more effective for the recipient and less time consuming for you to make than learning how to make a custom image.

I'm not sure what the issue is. It would help if you boot with "debugging" added to boot params. This will make connman log output more verbose and the systemd journal should be persisted somewhere (but I forget where). I think we need to get a trace that demonstrates the problem, and then I can nag one of the connman developers to look at it.

Quote from jaaara

I do not see a build for Cubox i2/i4 and Hummingboard - will there be Leia build for imx6 platform?

No. iMX6 support was broken for the first 6+ months of Kodi Leia development and since nobody stepped forwards to act as maintainer the dead code was eventually removed, so it's not possible to make an image. It should be possible to reinstate support using modern kernels in the future, but some technical (driver) things need to be resolved first to make that possible. It's something we're continuing to track.

Amlogic meson 8/8b/8m2 hardware (S802/805/812) has reasonable mainline kernel support as much of the IP is common with the newer GXBB (S905) platform. The missing and essential driver for LE support on newer kernels is an HDMI driver. One of the Linux community developers has taken the work done for the GX platform driver and is trying to adapt it, but so far there's no eureka moment. If/once that happens it should be reasonably simple to come up with a working LE image (as is the wonderfulness of working with a modern kernel).

It sounds like you're using Confluence not Estuary? (because in Estuary you'd go up to power-off, not down). If yes, the place to give feedback to the maintainer of that skin is the Confluence add-on/skin thread in Kodi forums.

Kodi (core code) logic changed between 17 and 18 so the second case isn't something you can control. It's just how (newer) Kodi works now. It's probably just easiest to not-hide played items so they're visible and can be deleted.