I'd guess that it doesn't reset the card voltage correctly during reboot, which means the card isn't detected and thus you see the "cannot find something to boot" text on the screen. Can you do some experiments with other SD cards? - ideally something old/cheap/slow that doesn't need the voltage switch.
NB: This is also a reason to test the image installed on eMMC storage; there's no voltage switch there.
Yes, change the servers associated with a specific connection profile using "connmanctl" .. Google for documentation.
Artefacts aren't something we can do much about. Handling them better is mostly a combination of the codecs, which can surely be improved but we struggle to find anyone to do the work, and the firmware which is sadly closed source.
Intel were the source of the initial HDR support in the kernel, and Team Kodi helped them to get code merged. Over time lots of ARM SoC devices then added support for the required DRM/KMS plumbing too. Substantial Allwinner support and a moderate amount of Rockchip support for media codecs and DRM has been developed or refined by our staff developers, or in collaboration (behind the scenes) with professional developers working on Linux media support (folks from Collabora, etc.). Over time we've accumulated many of the main V4L2 'name' developers into our Slack instance; we support a broad range of V4L2 using hardware and we have a staff with lots of test devices, test media, and experience of spotting and intelligently reporting quirks in media performance and playback - so we gain from their efforts, and they gain from our testing and inputs. RPi Foundation has an excellent team of in-house staff working on firmware and kernel drivers, and both LE and Team Kodi have a long history of working closely with them to ensure RPi has great media support. Their support to us is the A1++ benchmark that other vendors are measured against (none come close). The RPi foundation's approach to RPi4 has been different to older devices; mainly as lots has been learned since 2012, but LE/Kodi have been instrumental in forcing them to drop proprietary codecs and embrace the GBM/V4L2 world and push everything "upstream" to benefit more distros and the wider Linux community. It's taken time to get things into decent shape, and while RPi4 is not perfect (not all codecs supported, etc.) it's still the best performing device for the average LE user to play with. Enjoy 
Add the repo not the individual add-on files, then install the add-on from the repo. This way you will get add-on updates when they happen.
RPi4 is not the master of all possible codecs and cannot standby, but it's the best-supported device we install on, supports all or enough of the codecs you actually need, and has low-enough power consumption that you can just leave it on all the time (even in current times). I can highly recommended a flirc case (no fans so completely silent) and flirc USB for handling remotes. It's my family daily-driver combination.
I stopped trying to figure out NUC chip names and numbers about a decade ago so can't be much help on that front, but Any recent NUC without LSPCON should be reasonable and just work too.
NB: Kodi has no official Android maintainer because nobody (sane) wants to own the entirety of Android support, but 95% of the team who run Kodi on Android (and many do) use an nVidia Shield, so when something breaks due to nVidia firmware updates (as nvidia provides updates, unlike many other Android devices) there are always people motivated to fix the problem.
Options=username=xxx,password=xxx,rw,vers=2.0,uid=1000,gid=1000,forceuid,forcegidTry using lowercase params first, and if that still doesn't work, see if adding forceuid,forcegid works?
Where can I find the list of devices compatible with the new version of Libreelec ???
Why doesn't a USB wifi skewer work in libreelec???
in coreelec it works without problems.
List of device-trees in the upstream kernel is here: https://github.com/torvalds/linux…oot/dts/amlogic
And the probably cheap Realtek USB WiFi? (not sure what a skewer is) device works in CE because their kerrnel never changes so bundling a large number of poor quality realtek drivers that break and need new patches with every kernel bump isn't a big issue for them. In LE the kernel changes frequently and we got bored of the make-work involved years ago and stopped adding Realtek vendor drivers.
It was working till now with CoreELEC 9.X with dtb for Vontar T95Z Plus S912 3GB/32GB.
Please provide the dtb name that you've been using.
The usb_modeswitch changed was merged to LE since it's harmless and will be needed at some future point when the upstream kernels that LE uses gain support for that chipset. There is support for RTL8821CU wifi in the CE codbease (for Amlogic hardware only) that vpeter works on. There is also existing support for the BT side of the module in current kernels, which is why that works.
This set of changes should add support for WiFi https://patchwork.kernel.org/project/linux-…pengutronix.de/ .. but they are not merged and seem to be taking time. I would expect a couple more iterations of the patches before they get merged (and then we can pick them up or perhaps backport).
You can probably borrow the build-system package for the vendor drive that CE uses, and use it in a home-built LE image. We refuse to add the Realtek vendor drivers into our main codebase due to low quality and the constant need to patch/update the ever-growing number of drivers every time we bump kernels (which is frequent).
Some things I would try:
- Test with TVH 4.3 not 4.2
- Test the tuner on different hardware running the same LE release, e.g. x86_64
Logs showing at least the unusual boot delay would be interesting.
[ 12.876758] meson8b-dwmac c9410000.ethernet eth0: no phy at addr -1
[ 12.876792] meson8b-dwmac c9410000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19)Ethernet works fine if the box follows the reference design. Not all boxes do. It would help to know what the box is? .. and if possible to get the Android device-tree file, or be told what device-tree has been used successfully with other distros like CE.
Patch the code so that both calls use g_memdup ?
I will have a copy of the file in a clone of the LE image archive (which is currently offline) but the 9.2 release images will be a lot more reliable than some early alpha build. Also, there will be no add-ons for that image now, becaus ewe normally delete the alpha content to save space on the server once final releases have been out for a while.
You can/could bastardize something in pulse to do this, but it will be complicated as hell to configure and prone to timing issues so I just wouldn't bother. Save pennies and get a proper HDMI 5.1 surround speaker arrangement. The result will sound better and be zero effort.
For unexplained remounting of drives I'd suspect either power, or perhaps running out of RAM causing processes to be killed/cycled which can result in things being in odd states (not specific to LE, but a general thing with any Linux distro). Enable persistent logging and then do some log review/reading.
LE10 (stable) and LE11 (stable but still pre-beta) images can do everything that LE 9.2.8 can do. Use them; they are greatly superiour than LE 9.2.8 now. If you have an issue with those images; state the problem.
It took me 10 seconds to find this in Google: https://forum.kodi.tv/showthread.php…4738#pid2484738