Posts by chewitt

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.

I'm usually working in a kernel that's +1 release ahead of all the media_tree DVB drivers so they never compile and there's not much point in including them until that changes. Oleg's images might be different.

It might be technically possible to do some of the things you state, but the primary reason for migrating/regenerating the DB between Kodi versions is that it makes Kodi developement and support easier. The all-volunteer Team Kodi staff needs to strike a balance between spending their limited time on coding new features and fixing bugs .. and multi-version backwards-compatible SQL database support has "huge amount of effort for little reward" written all over it in mile-high flaming letters. Throw in "MySQL vs. MariaDB" and DB versions for extra hassle.

I know people have tested Krypton migration and I would expect a few to have done Jarvis, but I doubt anyone on Team Kodi has tested migration from as far back as Isengard. The reality is that developers develop on v.next not v.old and the staffing is limited; there's no QA department

NB: The Kodi wiki has some workarounds for DBs that fail to update including "export and reimport" if that's needed.

If the NAS is old it is may be using SMBv1 and you'll need to force the Kodi SMB client to use min/max SMBv1 via Kodi settings (not LE settings) else it will default to SMBv2 and it won't connect.

The log appears to show you navigating around. I can't see a video being played.