Posts by chewitt

I'm confident there is a bug in the LE settings agent error handling code for a long time now, but as none of the staff appear to have hardware or USB dongles that exhibit the issue it remains unresolved. The LE settings add-on has its own dbus agent so the connmanctl console agent being off or on is irrelevant to the problem.

Current C2 releases are aarch64, future C2 releases and kszaq current release are 'arm' so the update process aborts. Instructions on how to override that are shown on-screen under the error/abort message.

Most people with large numbers of devices PXE boot them. It doesn't result in config files being replicated, but it does result in all the config being stored in a single server, which makes updates and the process of changing config easier.

Auto update works fine. If it is not working for you, you are either using some kind of community release that has no update available, or the issue is localised to your environment.

Kodi auto-detects the available hardware at boot so it sounds like a race condition where the soundcard drivers are not always loaded before Kodi starts and thus it cannot enumerate the previously configured card and defaults back to HDMI which is available. Put a startup delay in LE settings (aka wait for network) of 5-10 seconds and see if the problem goes away.

All Windows versions since Vista should use SMB2 natively.

No idea as I don't use it. You'll also need to check with one of the S912 image creators to see if they build it in their repo.

It's probably worthwhile pointing out there is no single config.ini file for our distro, so even if TFTP did work it's still not going to be the magic thing that configures lots of boxes for you.

NAS boxes sit in the network, the Android/LE box accesses over Ethernet (ideally) or a good wireless connection (less good).

Quote from JefffromNJ

Any idea if this will work?

MX10 - Android 7.1.2 RK3328 4GB DDR4 32GB eMMC KODI 17.4 4K HDR TV BOX 802.1.1 b/g/n WIFI LAN VP9 HDMI USB3.0

Not right now. However, the lead developer for our current RK work is also the lead developer for OpenPHT so I'd expect it to get some love at some point in the future. No schedule though

LibreELEC.tv/package.mk at libreelec-8.2 · LibreELEC/LibreELEC.tv · GitHub

Master branch builds with pre-Alpha Kodi Leia and newer ffmpeg are in circulation for most hardwares. Go test.

The only other thing I can suggest is trying LE on some other kind of hardware which might prove that the crappy old 3.14 kernel that's used on Amlogic boxes is at fault. It's a long shot though. I wouldn't personally buy more/newer drives. I'd get a NAS and put everything in the network where life is easier and fewer cables are required.

LibreELEC.tv/linux.arm.conf at master · LibreELEC/LibreELEC.tv · GitHub

^ the kernel has the driver enabled

Now that you are on 8.2.1 there is a manual update function in LE settings; updates can be done from the GUI.

Did you set legacy security (not just SMB1)? .. the reason that option was added in 8.2.2 was that we had reports of ASUS routers could not handle NTLMv2 and this option forces NTLMv1. Someone reported that the latest firmwares still contained ancient versions of Samba.

[Unit]
Description=Create alias IP addresses
After=connman-wait-for-network.service
Requires=connman-wait-for-network.service

[Service]
Type=oneshot
ExecStart=/sbin/ifconfig eth0 add 192.168.178.18

[Install]
WantedBy=multi-user.target

Save ^ that to /storage/.config/system.d/ip-alias.service and run "systemctl enable /storage/.config/system.d/ip-alias.service" and cross fingers.

From: ConnMan, need to add secondary and third IPv4 addresses - Raspberry Pi - OSMC Forums

Our build-system compiles its own toolchain.

All prior issues that I've seen where devices mount under Windows but not Linux have either been unclean dismounts from Windows or the result of low quality firmware in the USB > SATA interfaces of the drive caddies. Windows blindly accepts whatever geometry is reported and attempts to mount the device. Linux validates what's reported, and if the data was bogus the validation fails and the drive is not mounted. That normally results in a load of error messages in the system log to let you know something is up though.

Can you swap a 'bad' drive to a 'good' caddy to see if things work?