Posts by chewitt

N2 is nice hardware although like most HK devices it has some quirks. It'll be even nicer when it doesn't run an obsolete franken-kernel, but mainline support is progressing swiftly. So far the G12A/B devices i've been playing with are noticeably quicker than GX devices. If you're not sold on the N2 there will be some other S922X devices in the market soon.

The USB/SD Creator app will write to any removable device. Some USB > IDE/SATA adaptors might not show up as removable, but the majority do and you should be able to write the image direct to the drive. The "USB" (or drive) should boot into installer mode by default, but it you hit any key at the syslinux prompt it will stop boot and you can type "run" to "USB boot with persistent storage" but it's not USB specific, it just creates a persistent /storage partition and changes the boot config from "installer" to "run" permanently. You might need to fiddle with boot settings to enable/disable UEFI or legacy boot support and in rare cases the BIOS/firmware might object to syslinux in which case you can always install grub as an alternative. The grub boot config is slightly different but extlinux.conf has all the details you need to set something up. As a general rule systems with problem firmware tend to be a bit too old and since (as a distro) we don't focus on old hardware at all, you may find drivers are missing.

.img or .img.gz files are used for install (but can also be used as updates) while .tar files are used only for updates

You can use "textmode" to prevent Kodi from starting and access a local on-screen console to poke around. Check the Ethernet port is full-duplex and share the URL generated by "dmesg | paste" so we can see the boot log (Kodi log isn't useful).

btw, "activate universal multiboot" means to put the device into update mode again, e.g. toothpick reset to force it to look for boot media on SD or USB ports. It has to read and "update" the u-boot instructions in new *autoscript files, then you have a working configuration.

LE images do the same thing .. except the AMLGX mainline kernel (test) image avoids the need for 1G/2G/3G RAM variants.

The only difference between updating from .tar file (in-app or external file) or using the .img.gz or .img (external file) is that we have to unzip and loop mount the .img file first. With the .tar file all we need to do is unpack it. There is no other difference, and Kodi handles migration of data not the LE (OS) update process. Add-ons are often a problem when updating to a new Kodi version, but that's nothing LE specific.

You're welcome to test the AMLGX mainline kernel test images on a C2 board.. balbes150 is creating them until official nightly releases start. I can't speak for how CEC works as I never test it or use it, but if there's a defect there people will be actively interested in understanding the problem and finding solutions (maybe not immediately, but it will go into the general mainline work-pile).

Two suggestions:

a) Add "ssh" to kernel boot params in syslinux.conf (extlinux.conf on some systems) and the SSH daemon is forced to start, so you can login, rename /storage/.kodi to /storage/.kodi-old and reboot to boot to a clean Kodi configuration.

b) If there's a network issue add "textmode" instead of SSH and connect a USB keyboard. Kodi will not start but you'll boot to a local console where you can run commands.

As a general rule OE installs have a ton of extra crap installed (as the result of some dubious packaging decisions by OE's creator) so it's probably best to start with a clean /storage/.kodi install and migrate back on the essential things from the previous install (thumbs, sources, etc.). Also beware that most OE installs have a 235MB /flash partition and LE 9.0 images are now around 240MB so you might need to make a backup, clean install LE to get a 512MB boot partition, then restore the backup. The backup/restore process is normally a lot quicker than trying to resize the boot partition.

First step would be to tell us what driver is used by the USB tuner?

Create an installation USB. Boot from it. Hit the keyboard at the syslinux boot prompt and type "run" and it will run from USB instead of installing.

Plan A: afl1's current work forward-ports the legacy Amlogic/Android dvb approach using the kernel backporting technique (media_build). It works but some people (not me, but kernel maintainers whose opinions count) consider this approach to be inappropriate as the legacy Android approach does not follow kernel standards. It's not impossible for afl1 to adapt his code, but this will take some time and effort and will require persistence and a willingness to accept feedback. So far he has only submitted one small fragment of code to a kernel mailing list. That was back in January and the maintainers made comments which received zero response. If he has any interest in seeing his work upstreamed (and sending the patch would indicate that he does, or did) communications will need to improve. If afl1 needs help with the upstreaming or communications there are numerous people who would like to assist. All he needs to do is ask for help.

Plan B: There are also funded commercial projects in the Amlogic ecosystem with requirements for mainline kernel DVB support so even if afl1 shows no further interest in sending code upstream; at some point a professional developer will be tasked to write and then upstream something that meets the required standards. This will not happen quickly as there are many code packages in those commercial projects with a higher-priority, but eventually it will be the top item on someone's to-do list and I am confident that it will be done.

I'd personally like to see the work done by afl1 be adapted and absorbed for the benefit of all, but I also see dvb support as a minor feature. Our overall experience as a project shows that the majority of users prefer USB tuners or independent network-based tuner devices as they are client-device agnostic, usually deliver better results, and are better long-term investments.

Two suggestions:

a) locally mount the remote filesystem(s) via systemd mount files. This allows you to place a hard dependency on the local mount completing before the Kodi systemd target can start.

b) manually update the library periodically after you add new content, not automatically on every boot.

Also remove /storage/.kodi/addons/packages .. as the add-on filenames don't include aarch64/arm and Kodi will reinstall from the cache (of aarch64 binaries) if the repo and local add-on versions match.

MikeKL you will need to uninstall any aarch64 binary add-ons from the LE repo and then reinstall arm versions. As long as you keep the config data when uninstalling (Kodi will prompt to remove it or not) it's a simple and quick process.

Please check options with whoever creates the image you're using. It's not an official one..

I'm not sure if /storage/.config/asound.conf still works as an override, but it used to (admittedly a long time ago, so no guarantees it still does).

surlary Kodi needs a patch for the Panfrost driver to work. It's missing in the image you have. It should be resolved in the next balbes150 update.