Clean boot, wait 30 seconds, then run "dmesg | paste" and share the URL generated. In theory the device-tree has WiFi enabled, but I've never seen the box and have no idea what WiFi chipset is used inside. The log can help.
NB: I'm also interested to see what remote and IR keymap is used, as the current keymap named in the device-tree doesn't actually exist. If you share working IR codes I can add it.
Make the SD card again, but this time a) set the dtb name to boot in uEnv.ini, b) do not move or rename the dtb file.
Add "ssh" to kernel boot params in extlinux.conf and the SSH daemon is forced on at boot time.
LE project staff aren't very knowledgeable on Chromebox boot, so I'd start with MrChromebox.tech for ideas. You probably can't do an update migration from OE > LE because the OE install will have a 232MB boot parition and this is too small for the current 250MB-ish LE files.
I find K19 generally better than K18, but then I also don't think the K18 is sluggish. I notice a large difference in navigation scroll performance between IR devices and a BT device and remotes using a flirc dongle; but the same difference exists in K18 too.
After checking the Linux kernel defconfig we use with RK boards it looks like we don't compile XFS support. We have support with other boards so it's an omission. It's been flagged to devs and should get fixed.
Newboxuser Wrong forum, we don't do CoreELEC support.
Well.. CE forum would also be the wrong forum for an RK device, so LE is what they meant.
The reason why i want to do that is the lack of hevc videos support.
I'd wager that current LE10 nightlies have better HEVC support than LE 9.2.6 achieved (apart from 4K60, which is never really needed). What issue do you actually see?
Please test the latest nightly: a) because there are a lot of Interl firmware/driver updates between LE9.2.6 and current LE10, b) because even if the issue in 9.2.6 is identified there will be no more 9.2 releases to fix the issue. Forwards is the only direction!
<?xml version="1.0" encoding="utf-8" ?>
<sources>
<video>
<default pathversion="1"></default>
<source>
<name>TEST</name>
<path pathversion="1">smb://user:pass@SERVER/VIDEOS/TEST/</path>
<allowsharing>true</allowsharing>
</source>
<video>
<sources>I've never understood how/when passwords.xml gets used .. I've always defined sources in sources.xml which has a similar format, see above. I'm not sure that's even remotely a solution to the problem. For kicks, use CAPITALS for server names and paths.
I'd guess that you've install a bad/broken add-no and this is causing Kodi to crash repeatedly which triggers safe mode. Debug logs will show what the problem is, but if you've been installing pirate crapwhere (which is a frequent cause of such issues) please save yourself the effort as we'll auto-refuse support. NB: Disabling safe mode will probably give you a system that you can't get into due to crashes/restarts .. so not the best advise.
I'll summarise that i've never even heard of it and i'm as close as the project curently gets to a Samsung maintainer (the Exynos image for XU4 devices which is broken for 4+ months due to my work/life busy and deliberate neglect). So there is no LE image for this board and I doubt you can create one since mainline Linux kernel support for Samsung hardware isn't so great (boot = maybe, hardware video decoding in Kodi = forget it). Stick to RPI 
thank you for your reply, your announcement was giving me hope that my box wouldn't be redundant. Although I can carry on using Kodi 18 for a while I will have to have a look for an alternative
The "box" image should still boot a hub (using vendor u-boot on emmc) if you want to experiment with a spare SD card, but I can't claim to have tested with 1GB devices recently and as noted there are some challenges with hardware decoding. Using WP2 for a bit recently it's annoyingly close to being quite good, but also far-enough away that the initial euphoria of booting a modern kernel etc. wears off.
RPi4 is my recommendation for replacements. There are technically better spec'd things but the software support on Pi hardware (as in, the level of people and engagement in supporting the software) is in a different league to everything else.
LibreELEC-AMLGX.arm-10.0-nightly-*-*-odroid-c2.img.gz files contain mainline u-boot and are designed for writing to SD card or eMMC module. You cannot update older installs as we move to extlinux style boot which has different files in the first/boot partition. Clean install is required.
NB: The image in Index of /testing/ has better playback performance than current nightlies due to some experimental ffmpeg changes and other bits. Don't pay any attention to version numbers of files in that folder, only dates count.
Hello there,
Thank you for the information and the hard work provided by the libreELEC team!
May I just confirmed that my understanding of the announcement is correct, LE v10 which will run Kodi 19 - Matrix will be available for Wetek Hub (Soc S905-H revision C) done the line?
Also, following the announcement from coreELEC to stop supporting amlogic S905 & S912 due to their kernel not being maintained by amlogic any longer. Is there plan to stop supporting those SOC in the near future?
The statement makes it very clear (or so I thought) that there will be no LE10 release for Amlogic devices. Nightlies exist but mainline kernel support for Amlogic chips is not where it needs to be; there are challenges with hardware coding. I've been poking mainline u-boot support for the older WeTek devices and now have Play2 working well (within the caveats on hardware decoding) but I've been unable to get the Hub to boot so haven't done any work on it in some time - I need to dig up the vendor files and test the hardware with those again. If the status of decoding improves we can release something in the future. S912 is easier since it has more CPU grunt and you can disable problem hardware decoderss and use software decding on 1080p content (forget 4K). Same for newer chipsets with have even more CPU power. There is currently nobody working on the hardware decoding as I don't write code and nobody is funding commercial development. So not likely to see progress anytime soon, but we'll get there at some point. The images in my team share Index of /testing/ are a little more usable then current nightlies due to experimental ffmpeg work. Note - the "box" image is the one to use with any device that uses vendor u-boot.
The Samba change on 26/1 is where fingers naturally point, but I use SMB(2/3) from an assortment of devices in the same share configuration that has not been touched in several years (Synology NAS with SMB shares and SQL) so it's something nuanced and not a general SMB problem.
Start by describing the sharing environment with SW versions, and if Windows is the server target, state the credential types being used.
You probably need to run the Gamestarter image not the default LE image. The error suggests missing compile dependencies so I'd guess the other image has them and our main images don't. NB: I have zero knowledge on the Gatestarter releases.
lx.io sometimes has DB and disk space issues
