Posts by chewitt

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.

It sounds like the HTPC was the browse master and when you reboot it an election is forced and it takes time for the remaining systems to figure out who is now in charge .. and until that happens name resolution is impacted. As the NAS should be always-on you can "Enable Local Master Browser" in Synology SMB settings (advanced tab) and future elections should be avoided (unless you restart the NAS). You might need to "turn it all off and on again" after the change before things settle. ZeroConf doesn't have the same stupid process

Two methods:

a) Compile your own image with this value changed: https://github.com/libreelec/libreelec.tv/blob/master/distributions/libreelec/options#l203

b) Install using the default image which creates a 512MB partition and then reboot from an Ubuntu (or similar) LiveUSB and use gparted to shrink /storage and then increase the size of the boot partition.

LE images are currently 235MB and much larger full debug development builds fit in a 512MB partition. Generic sizes will drop considerably in LE10 once we remove 2x nvidia driver blobs from the image.

I don't keep track of them all .. but they're all in this section of the forums.

Online docs talk about global limits but I believe you can set them in individual service files too, and /storage/.config/system.d/ allows you to override any of the embedded .service files with your own (stop/disable the embedded service, then enable/start the custom one). LE doesn't allow you to install things to the core OS (everything is inside a read-only squashfs image) so any extra things you added via docker (or things wrapped as Kodi binary add-ons) must be using the persistent /storage area which is writeable so you can make direct changes.

8GB is the normal minimum we quote for any Kodi install (hence the previous CM1/CM3 with 4GB are limiting) but 16GB is probably a better size to have headroom unless you want to experiment with retro gaming or docker in which case the 32GB card might be attractive (and only $5 more).

As the Slice has a solid metal case a heatsink that achieves contact can conduct more heat away, but there's never been an official heatsink that does this - only homebrew designs that users created for themselves, and the extremely exact dimensions required probably need adjusting for the newer chip design. So the easier option is to get the normal stick-on RPi heatsinks and use those. The result is not as efficient, but it's still an improvement on having no heatsink(s) at all, and you can get them from any Pi reseller for $1.50.

There's no generic S805 image but there's a couple of community releases in these forums which you can experiment with .. it'll be a trial and error process to find something that works.