Posts by chewitt

Running the "box" image from SD card is easiest, the -wetek-play2 image is the one that needs emmc wipe etc. and that is not trivial or recommended for most users. Update is simple; drop file in /storage/.update and reboot. If you track my private test images you should pay attention to file dates not the numbers.

Can you share "dmesg | paste" from the KIII pro as I'd like to see if the BT is working now. If you also have a KII pro box (S905 or S905D?) it would be good to see the dmesg log from that too. Also, if you can share pics/photo's of the two remotes it would be appreciated. I like to reflect the physical device layout in the keymap code.

The .img.gz file is for writing to SD card. The .tar file is for updating an existing (LE10, not 9.x) install. Otherwise they're the same. You might prefer the images I have here Index of /testing/ which have changes to ffmpeg that allow seeking in H264 (not perfect, but an improvement on the nightlies). In either image you need to set Kodi to "fixed" 44.1KHz "Analogue" output to get multi-channel audio without glitches in the audio. These images are still experimental..

cd /storage/.update
wget https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-9.95.1.tar
reboot

^ run those commands to update to an image which should (in theory) have the missing firmware for the WiFi card, and a revised device-tree file to enable BT support. If this works I can send the device-tree changes upstream to the Linux kernel.

For the IR keymap, either identify the keymap file or name that CE are using or record the keycodes, see Infra-Red Remotes - LibreELEC.wiki (which is not that hard). Make sure you note the button press order to match the recorded codes. Most Amlogic remotes use the NEC protocol.

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.

Quote from Da Flex

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.

Quote from linuxuser

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

Quote from sweetthdevil

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.