Posts by chewitt

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.

Netflix changed things some time ago so Widevine L3 certs (which is what we use, we fake a browser) can only receive SD media. It might be that you found some test media that still allows HD, but as a rule everything else on their service is SD only, and L1 certified devices are the only ones that can receive HD and 4K media.

I use SMB without issues for a decade (and deliberately, as it's the lowest-common-denominator among user installs) and I tend to rip original media with high quality settings so 40GB+ files are not uncommon. I have never fiddled with cache settings, because there is no need to if your network functions okay. NFS might work better for some - no harm in trying that. The network tools add-on includes iperf, but this is more designed for throughput than reliability testing so YMMV.

Railink and Qualcom (Atheros) devices are normally a good option, as the drivers are almost always in-kernel which improves performance, stability and support. Sadly Realtek devices are cheap so everyone buys them, but they are a pain to maintain and have more bugs/issues.

There is no official list. There will be no official list. Why? .. because we're a small team and we have many better (and much more interesting) things to spend our limited personal time on than generating innacurate lists of wireless dongle chipsets from manufacturers that fail to upstream support for their products to the Linux kernel. As most HTPC devices these days include a wireless chip that is normally supported (and using Ethernet with an HTPC device is strongly recommended anyway) it's also a declining issue. You may have other views, but that's generally the team opinion.

The skin might be at 1080p but you set the Desktop to 4K and the whitelist is not used so everything will be scaled to 4K. In other words, roughly the opposite of what I described. Kodi has to work on everything from Android phones to small embedded ARM boards, to high-end Intel chips. Hence it deliberately starts with neutral defaults.

Please take some time to read the Kodi manual Official Kodi Wiki

We manage 100% of the OS inside the KERNEL and SYSTEM files and it is not possible for "cruft" to accumulate in the OS because it's all contained inside a read-only (thus cannot be written into) file that is uncompressed to create a virtual filesystem on boot. You (and Kodi) manage 100% of the /storage area and this may accumulate thumbs, add-on installers, add-on caches, crash logs, etc.

Editing connman config files (service files) works if connman is stopped before editing and restarted after. Connman manages the files so if you do not stop > edit > restart connman can (and probably will) overwrite changes made at some point.

Some rough patches to address using an FQDN were posted to the connman mailing list about two months ago. I shared links to them at the same time and so-far received zero feedback. From this I conclude that nobody cares enough to contribute a little effort to testing. I blow hot/cold on my desire to do everything and have other priorities on my to-do list, so I suggest someone else pulls a finger out for once.

aptalca ^

Thumbs and other artwork are downloaded and cached uniquely on each device, but should use common URL references to the original art locations which are stored with the media in the DB, so it's inefficient (multiple downloads, multiple caches) but you should end up with the same art images on all devices.