Posts by chewitt

    The boot arrangements for legacy and mainline kernels are completely different so attempting updates is just asking for a pile of support issues, so a forced reinstall is the best option. It's no problem to backup and restore Kodi data between versions as that doesn't change much, although if the backup contains binary add-ons you'll see a list of add-on "fail to start" errors until newer versions are downloaded and updated. That's nothing new though, it's the same as any LE major-version update.

    The main idea we've asked the Availink folks to grasp is; if they develop something that works on the Amlogic 4.9 kernel today they will be screwed in the future when Amlogic bumps to 4.19 (or god forbid, something newer) and they will never get it upstream to the mainline kernel as it won't follow kernel APIs and coding standards. However if they create a driver that runs on the mainline kernel today, they will be free to add whatever hacks are needed to backport it onto Amlogic bsp kernels (as no rules apply there). That's been understood, and we also persuaded them to relicense the driver under GPLv2 instead of something proprietary and restrictive.

    So things are progressing and I'm able to compile the Availink demod (or an earlier version, I didn't rebase on it for a while) but it's still early stage and only one of several components needed for DVB support. Work also needs to be done on the tuner drivers that are used with their demo, which exist in various forms (not all have good prevenance for license and future upstreaming) but these needed to be deconstructed and adapted into independent modular drivers; the Amlogic kernel compiles them into a single monolithic blob, which is meh. Then the major missing piece is a new V4L2 demux; the mainline kernel has a completely different DRM architecture so we cannot repurpose code from the Amlogic kernel. And finally if we get that done, it should all be describable from device tree so that different tuner/demod combos work without special compiling. The availink folks are not completely sold on the whole story yet, but if we can at least get their demod and tuners to build alongside a new demod, the rest can take time.

    If I were doing it myself I would unpack the backup tar file on a clean install, stop Kodi, move sources, guisettings, thumbnail chaches and the userdata addon_data folders over, then restart Kodi and simply reinstall all add-ons. It probably takes longer to investigate each add-on and work out whether it's binary or not, than it takes to blindly do all of them. If you're familiar with copy/move Linux commands this is no more than 10 mins effort.

    Are you sure that you grabbed the Leia version? .. because Python3 would be Matrix, Leia is Python2. I'm running the same add-on at home here on an RPi4 using an image built from the current LE 9.2 branch (sort of a pre-9.2.4 image).

    If you boot any of the mainline kernel "box" images, the contents of emmc can be backed up with 'dd' but this is slow and requires an SD card (or USB) larger than the emmc size to store the image. At least with S905 devices the emmc sizes are typically 8-16GB only so that's not such a big deal.

    NB: LE does not support update of legacy OS installs to the LE10 codebase, a clean install is required. If the Amlogic 3.14 kernel is detected during update we abort, and if you manually override the compat check the box will (guaranteed 100%) end up in a broken boot state.

    There are some audio/video config items in Kodi settings (guisettings.xml) that will be different due to hardware differences, but as you discovered the main problem will be binary add-ons, which must be removed before taking the backup that you want to migrate to the new device. Once you've restored you can reinstall them. When removing an add-on you can choose to completely remove or leave data behind. In theory if you leave behind your config(s) will be resumed on reinstall.

    It would be firmly in the serious development category, and it won't be done because if you want to play Kodi on one output and use a browser on the other this is possible today using Raspberry Pi OS using a normal Xorg desktop. LE is focussed on being a dedicated HTPC OS, and we have zero ambition to be a multi-purpose OS from a user-experience perspective.

    The log you've shared is the Kodi log, and we'd need the system log to see anything about drivers and such. Do "journalctl | paste" about 60 secs after booting and share the URL. NB: "lsusb" reports raw hardware info, it does not mean there is a driver loaded and running.

    RPi3 cannot hardware decode HEVC so if you've got a lot of content ripped in that format it's being software decoded and the CPU will get hot. It's fine to run hot (it will clock down and self-manage) but a case with better thermal behaviour does help.

    We've always resisted the idea of creating a list with LE, because the last decade of forum support with OE/LE proves users are rubbish at contributing to a wiki, and forum threads where people post "it worked for me" always end up being hijacked with "it didn't work for me" posts and over time (years in a forum) the thread ends up with stale information. Sometimes it's better to deliberately have no information than wrong information.

    From time to time we also have moments of self-doubt about refusing to add more Realtek drivers, but then we do a kernel bump, they all break and we spend weeks hunting patches and new driver repo's, which holds up other activities, and then we're back where we started.