Posts by chewitt

/storage/.cache not /storage/.config .. there will be subfolders for the connman service name and then a settings file

I repurpose Apple A1rport Express basestations as cheap WiFi > Ethernet bridge devices. I get better range and performance than any USB device that I've ever used and there are no drivers involved so it works on all kernel versions and any device with an Ethernet port.

You're wrong. One setting is in the OS and our settings add-on controls that. The other is entirely within Kodi and the Kodi setting controls that. Kodi does not have code for controlling our background service (which looks like an add-on but is still external to Kodi and has no API) and while Kodi has APIs our settings add-on deliberately doesn't attempt to figure out the relationship between supported OS and GUI language. For example, Generic x86_64 hardware has different keyboard languages and layouts to Raspberry Pi which has a more limited range of supported options.

I'm not saying it cannot be done .. but it's not a straightforward thing. So far it appears the ~70% of project staff who are not native English speakers are okay with the inconvenience of setting it in two places during setup. Unless that changes, the status quo will remain the same.

Minor increments maybe, but I'm not expecting any .. but then I don't experience general performance issues with the GUI as-is. What is the issue?

mkdir -p /storage/.config/firmware/mrvl
wget -O https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/mrvl/sd8897_uapsta.bin /storage/.config/firmware/mrvl/sd8897_uapsta.bin
reboot

^ that should get the BT device working - dmesg shows the firmware is missing in our Generic image, and since this is an SDIO module (M2 interface according to Google) there are no drivers in our current kernel. The WiFi probably needs the following kernel defconfig options enabling:

CONFIG_MWIFIEX=m

CONFIG_MWIFIEX_SDIO=m

See Linux Kernel Driver DataBase: CONFIG_MWIFIEX: Marvell WiFi-Ex Driver

ping milhouse

We use "udevil" to mount filesystem devices dynamically instead of storing/editing static content in /etc/fstab. You can place your own udev rules in /storage/.config/udev.rules.d that will either add-to the rules (most specific rule wins) or if you name them the same as an existing embedded rules file they will overwrite/replace the same-named rules file.

The active config files are in /storage/.cache/connman but these need to be edited via "connmanctl" as connman directly manages the files. If you edit them by hand the changes won't take effect and are unlikely to persist over a reboot.

Update to a current image and retest.

Post to the Zomboided thread, we don't provide or support any of those add-ons.

Index of / <= latest AMLGX nightly "box" image on an SD card with one of the p200 or p201 device-trees might work.

Currently no, as our settings add-on runs in the background independently of Kodi and there is no way for Kodi to tell the OS layer that the keyboard layout has changed (and vice versa).

It's a known issue, but not a high priority for investigation as LE does not currently release aarch64 images (as we need arm userspace for libwidevine compatibility). If you build with ARCH=arm the image will complete.

If the TP-Link requires some firmware to work let me know (it will be reported in dmesg as a failure to load something) and I'll add the firnware to the image. If it requires an out-of-tree driver, sorry but I don't have time or interest to chase down patches for realtek drivers that break with every kernel bump so all of them are disabled (and no current plans to change that).

Restart and shutdown now wait for Kodi to gracefully shutdown instead of killing the process after 5 seconds if it hasn't existed (it never does). This avoids frequently reported issues with Kodi trashing configs which are saved at shutdown, but does drag out the shutdown process compared to older LE releases. It's known and is a general Kodi problem not anything specific to Amlogic or these images. There is a long-term plan to refactor/rework some bit of Kodi which should improve timings .. but don't hold breath.

Hardware decode is still only partially working. H264/VP9 are now reworked and merged for Linux 5.7 and HEVC (not hardware supported on C2) will be next, but ffmpeg stateful API support and the Kodi side still need reworking. Most of the effort on that is currently focussed around Raspberry Pi but since Amlogic shares the same code paths that's not a bad thing.

No ideas about CEC as I don't use it. I do have a patch in the codebase to disable dmesg log-spamming when CEC is not supported (as I disable it in my AVR) but this is only //commenting out the message and it doesn't/shouldn't prevent actual functionality. Check Kodi settings?

cdu13a drop me an email with the wiki consistencies and I'll correct them.

LE (and OE before it) has never supported installation of debian packages (or any other form or packages).

Kodi only looks for CD/DVD hardware at startup so if you connect a USB/removable drive after Kodi starts it will not be seen unless you restart. This is a long standing "works as coded so not technically a bug" issue. Some of the related code in Kodi is an exercise in archaeology .. it needs overhauling but there's not many volunteers in that area of the codebase. lrusak were you poking that stuff semi-recently?

We have never officially supported generic S812 boxes, only the WeTek Core (also S812 but no guarantee the device-tree works on your box). There are some other community images available in the forums that you could try on an SD card .. but again, no guarantees.

K19 alpha/beta/launch has nothing to do with it .. DVB support is all about kernel (and out-of-tree driver) versions.