Posts by chewitt

    From version 10.0.2 and up, also nightlies. TV detects HDR but displaying striped, green/purple toned image.

    I must have been Zzz .. the issue here (in all releases that have ever claimed to support HDR) is that you're playing files with DolbyVision HDR encoding which is not supported under Linux. You'll need to use Kodi on a DV licensed Android box to play them.

    LE supports the static (and open) HDR and HDR10 formats, not the dynamic (and proprietary) HDR10+ and DV formats.

    The core OS will downgrade without problems, but Kodi does not support downgrades so you'll end up with a bunch of add-ons at a higher and incompatible version and that can often have crashy consequences. Things like DB content will be fine as Kodi simply uses the older DB files that still on disk (or tables in MariaDB) and ignores the newer ones that correspond to new Kodi version.

    Crossgrades between release and nightly versions are generally okay as long as Kodi API versions haven't changed. At this stage of the cycle things are stable on that front so it won't be an issue. If we're still in the pre-Alpha stages there are API bumps and that will cause issues from time to time.

    Quote


    bootargs=boot=UUID=2604-0049 disk=UUID=f660cd3d-904b-452a-ae8e-3584aab3e106 quiet ssh systemd.debug_shell=ttyAML0 console=ttyAML0,115200n8 console=tty0

    Create a clean SD card from the same image. Set the DTB name in uEnv.ini and add "ssh" in the boot params ^ (beware the forum is wrapping lines - it should all be one line). This forces SSH to start, even if the GUI doesn't come up etc.

    Then login over SSH and run "pastekodi" and share the URL so I can see the boot log (and what's going on with the mount/unmount).

    If the issue was firmware I would expect to see errors when the hardware probes and fails to find/load the right firmware. However I don't see any mention of anything related to WiFi/BT at all which suggests the hardware isn't probed/detected at all. I'd go (re)check the card is seated correctly - is it detected/shown anywhere in the BIOS (if the BIOS is sophisticated, often they are dumb). Or perhaps the card is bad? / can you test it in anything else?

    Settting "meson-gxl-s905x-p212.dtb" in uEnv.ini should work with the box (except for WiFi/BT perhaps) although the ability to boot does still require the vendor bootloader to support looking for boot.scr or s905_autoscript on startup. Most do, but not unless you invoke the recovery boot process (holding the reset button during power-on and releasing at the right time, which might take some attempts to get right). If the recovery boot flow is not triggered the box will continue booting into Android or existing Linux OS. Sadly a) it's not as simple as just inserting the SD card, and b) the only real way to understand what is/isn't happening if it's not working is to attach a serial console. That generally needs the user to open the box and solder header pins to the board (as box manufacturers omit them to save pennies) before connecting the USB->UART device (which 99/100 users don't have). When it works it's great. When it doesn't it can be a hoop-jumping exercise /shrug

    Code
    find /path/to/share -type d -name '.@__thumb' | while read ITEM; do rm -rf "${ITEM}"; done

    From a quick read it's the DLNA photo sharing features on the QNAP that creates them, so this needs to be disabled for the content/media folders you share to Kodi. Then you can run ^ that (on the QNAP) to exorcise the existing thumbs. Then you can either clean the current Kodi DB or start over and scrape again.

    QNAP NAS? .. Google throws up lots of QNAP related hits for these filenames and several solutions for how to disable them (on the NAS) and then do some cleanup (on the NAS). ISTR there's something similar that happens on Synology too when the Photostation app is installed (now banished from mine).

    It's still hard to make out, but I think RTL8189ETV is an educated guess on the WiFi chip. This is a basic b/g/n WiFi only module (no BT). The RLT vendor driver can be found here: https://github.com/jwrdegoede/rtl8189ES_linux and while it's relatively simple to package it's not a driver that LE will package due to the long-standing policy of not adding more damn RTL vendor drivers. Unfortunately this is an old and cheap chip and I'm not aware of anyone making the effort to port the (equally old and cheap) vendor drivers to the upstream kernel. WiFi sucks for streaming most media anway, so stick to Ethernet.

    PCB's can be fun to get without reflections and such obscuring the info. However, that's a nice clear pic and there are definitely no buttons on that side of the PCB. Have you tried creating a new install SD from dtech'd image? .. not booting?

    At the end of the day it's probably just an unsupported Realtek chip, so unless you really really need BT, maybe just quit while we're ahead?

    I got bored in my lunch hour so this image has a device-tree for tx9-pro which uses the IR remote from tx3-mini .. if you have the larger Tanix remote with numbers on it those won't work and you'll need to capture the key codes for me. I've also added something for the clock on the front, which might work if it's the same type as the TX3-mini box. If not the same, it might show nothing or garbage.

    https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-10.95.1-box.img.gz

    Again, run "pastekodi" and share the URL so I can see the boot log.