Posts by chewitt

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.

This was submitted upstream in the last week: Linux Media kernel patches - Patchwork so (fingers crossed) it should be merged upstream for Linux 5.9, and it should also be fairly simple to backport onto a recent kernel.

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.

"probably" .. but not guaranteed

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.

Kodi feature requests should be made in the Kodi forums.

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.

Kodi v19 (pre-Alpha) .. first alpha should be around the end of June (if things run to plan) or beginning of July (if not).

the flirc case is great .. the black Kodi version of it looks awesome too

The "X96-Max" device tree (meson-g12a-x96-max.dt) should work with that device, the specs look identical.

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.

They are nightly development snapshots not well tested release images, so it depends on your personal definition of stable

Downloading sounds dubious, and no Kodi cannot magically tell files are the same thing and select the local one.

HiassofT is our guru of all remote things. Any ideas?

The folks who maintain the Netflix add-on might have a more accurate explanation if you ask in the add-on support thread in the Kodi forums, but what I've told you is basically accurate and you will not see better than SD using any device running Kodi on a Linux OS; including an RPi4 because it's not about the device, it's about the OS environment.

The MediaTek devices are in-kernel so even if we don't have support for them turned on (not sure, but I think we do) it's a trivial process to enable the driver in kernel defconfig and maybe pick some firmware files that are needed.

You can try booting with a clean SD card installation, but if that doesn't work it will be near-impossible to diagnose what the issue is without having the early stage boot log from u-boot via a UART cable.