Posts by chewitt

    Please run "dmesg | paste" and share the URL, to see if there are any error messages in the log?

    The one remaining experiment I can think of is writing the WP2 (not box) image to emmc. This replaces vendor u-boot with upstream u-boot and changes the early boot process. That said, I'm not sure it would resolve anything as I've not had other reports of what you're seeing and there's a growing number of users (most of whom are probably booting from SD card). I have a raw (dd) copy of the original factory image that can be restored to emmc if you wanted to put Android and vendor boot code back.

    https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-10.85.0-wetek-play2.img.gz

    backup-wp2.img.gz
    Shared with Dropbox
    www.dropbox.com

    To install to emmc download the WP2 image to /storage/ and then run "emmctool w LibreELEC-AMLGX.arm-10.85.0-wetek-play2.img.gz" and it will install everything. To restore the backup, boot the WP2 image from SD card (so emmc is not in-use) and then download the backup and write it with "emmctool w backup-wp2.img.gz" .. until it eventually finishes.

    LE fixes a kernel major version for a specific release and then sticks with it. So LE10.x is built around 5.10.x (on RPi at least) and on LE11 we're currently at 6.0 but will probably end up on 6.2 by the time we enter beta and lock the kernel version. There's no trick to it, or penalty for being on 5.10 in the current stable release. If you want to replicate our stability you'll need to replicate all the same major versions and the patches that we use; kernel, kodi, mesa, firmware, etc. - it's not just the kernel.

    There are several people on staff with RK3588 boards including the Rock B. There's quite a few drivers to be written before we'll be able to create usable images though so I wouldn't get too hopeful of seeing anything soon :)

    I've long advocated that if you want reliable DVB with LE or any of its derivatives you should separate the head-end from the client, because it makes it much easier to e.g. run RaspiOS on the head-end (easy package installs, any drivers you like, older kernel, etc.) while the client side runs LE. Separating things allows you to keep the client current, bumping as frequently as you like, while the server side remains on whatever works (and no need to bump it).

    Code
    mount -o remount,rw /flash
    cat /sys/devices/platform/soc/d0100000.vpu/drm/card0/card0-HDMI-A-1/edid > /flash/edid.bin

    SSH in and run ^ those commands, then shutdown, remove the SD card, and on a PC copy the edid.bin file and attach here so we can poke it.

    There is almost zero linux codebase in common with CE so the comparison there nice to know but not technically helpful.

    autostart.sh runs at the start of userspace boot long before networking is up, so the only way to sequence things is backgrounding with a sleep delay and then hoping the timing remains consistent over time. Using a systemd service allows proper sequencing to remove all the guesswork on timing.

    If you're using the box image from an SD card the boot params are in uEnv.ini. If you installed LE to the eMMC storage then boot files are a bit different and there's an extlinux.conf file. However, configuring (forcing) an HDMI mode will do nothing when you're connected to the TV with a composite cable. You can try the following but I doubt it will work: video=Composite-1:1920x1080M@60

    Use an HDMI cable and you'll get proper modes.

    WG support is ultimately all about what's in the kernel (and WG is there) so there's techincally nothing that prevents LE being used to host a server, but there is no plumbing to facilitate that in the GUI or in ConnMan, which is client focussed (and no intent to add anything) so you'd have to self-create whatever scripts are needed to create interfaces and do things on boot, etc.

    Create /storage/.config/system.d/mtuchange.service with ^ then "systemctl enable /storage/.confg/mtuchange.service" and "systemctl start mtuchange.service" .. it's a guess (not tested) but should run after connman starts and before the network goes online.

    Run "modetest | paste" and "cat /storage/.kodi/temp/kodi.log | paste" and share the URLs, but the logs will probably just confirm that we don't see normal 1080p modes. You can also try forcing 1080p60 output by appending "video=HDMI-A-1:1920x1080M@60" to kernel boot params in extlinux.conf (on the SD card). This forces the DRM driver to a specific resolution. Resolution is about the modes detected from the EDID data on the HDMI connection, it has nothing to do with CEC. Older TVs are more prone to bad EDID data and that's an era when "HD Ready" TVs with 1080i. Kodi only outputs progressive frames so 1080i will not be selected for output, but those TVs normally have 720p modes that we'd find and use instead. It's always worth experimenting with another HDMI cable and using different HDMI sockets on the TV to see if you get different results.

    Please do I need to copy any latest box image to /storage/.update for future update?

    The LE11 nightly box image or the tar file from my share are fine for updates. I don't increment the version number on my share, but the file dateTime shows you when it was last updated. If it works; keep a copy so you can always revert to it.

    I have an Amiko A9 Blue TV BOX currently with Android 9. This box has Amlogic S905X3 (A55 64bit). These test images like 'LibreELEC-AMLGX.arm-11.0-nightly...' are compatible with this harwdare

    There's no dts for that specific box, but they're all much the same so you can try the following dts:

    meson-sm1-h96-max.dts

    meson-sm1-x96-air-gbit.dts

    meson-sm1-a95xf3-air-gbit.dts

    Note that you'll need to disable hardware video decoding (and CPU decode) on an SM1 box; the drivers were written for older GX devices and need major work to make them compatible with newer hardware. Anything @ 1080p should be fine but forget 4K. For that reason CE is still a better option than LE on SM1 devices.