Posts by chewitt

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.

Index of / has nightly images from Jenkins.

TVH is running on a dedicated port (9981) which is being proxied so there's no need to change the root path.

Passthrough will be supported, but (again) what can be passed-through will depend on what the hardware supports running under Linux.

Not supported.

ir-keytable needs to be listening on the right protocol to see anything and some remotes have odd vendor invented stuff for power-on events; for the same reason you might not be able to teach a remote that only understands specific protocols and doesn't just capture/record whatever signal is transmitted to it. I'm about to start playing around with the current official HK remote to ensure it works on mainline kernel images using mainline u-boot, but that's not an endorsement and might not be a quick solution.

The connection manager (connman) stores static connection details against the MAC address, and if you investigate you'll probably discover that the kernel is assigning a random MAC address on each reboot, so there is no matching profile and it defaults to DHCP again. The cause is the hardware manufacturer being too cheap to spend some $$ getting a block of unique MAC addresses for their hardware. To advise a workaround we'll need to know what hardware you have?

Users often and wrongly believe pass-through is some magic "hardware doesn't touch the bitstream" method, but in reality the hardware has to support the stream format to correctly detect and handle it as a pass-through stream. Raspberry Pi doesn't support any HD formats.

Good point

Add "textmode" to kernel boot params in uEnv.ini and connect a USB keyboard. You'll boot to a console where you can run commands. After running them, remove textmode again, then reboot.