Posts by frakkin64

  • Official LE11 Test Images for Amlogic (Kodi-20)

    Quote from chewitt

    Some of these differences are intentional; partly to align with LE standard namings, but also because we (me) don't want users "updating" from all kinds of unknown legacy images to AMLGX and then showing up with tricky-to-solve support issues. Boot is already "fun" before you factor in large Kodi major version bumps and the Python2 to Python3 change which causes add-on carnage.

    After digging through the whole u-boot process, aml_autoscript, etc. I can fundamentally see why you wouldn't support eMMC's at all on Android TV-boxes and not even touch them. It's a nightmare, you would have to format & partition the eMMC to be supported by mainline, you probably would have to replace u-boot, and it just starts piling up with bricking scenarios.

    I have only worked up the nerve to chainload mainline u-boot on the Vero4K, pretty reluctant to format the eMMC and load that mainline u-boot. And naturally all working from SD cards. It's just not worth it, so far I haven't seen an SD card failure, and I have weekly backups anyways of /storage.

  • Official LE11 Test Images for Amlogic (Kodi-20)

    Quote from chewitt

    2. Once you initiate recovery boot to load LE the u-boot environment is tweaked to use LE boot files (else it won't boot). If you remove the SD card (or USB) and force recovery boot again it should rediscover the AE install. You can't swap between distros solely by removing the SD card.

    I don't know how AE or people format the eMMC. But on the Vero4K they still use the original Amlogic u-boot from Android, plus the Android partition layout, and if you go toothpick mode on it without an SD card in it (or a valid aml_autoscript) then it wipes the "instaboot" partition (it's in the u-boot script). The problem on the Vero4K is they take several (most) of the Android partitions and throw it into an LVM and use that as the root filesystem. I don't remember the exact scenario, but I have wiped instaboot many many times playing with LE/CE/Armbian and had to reinstall OSMC. :)

    Hopefully it's just a unique scenario with the Vero4K, easily fixed, but I know the u-boot sources are not complete (missing bl32) and doubting if there is other pieces missing (just because I see package updates in OSMC but no source code updates in their source tree).

    Anyways, the point of this meandering is to share that toothpick method can kill eMMC installs depending on whether they use the instaboot partition in a similar way.

  • Docker or librelec add-on install fail

    Quote from Kakooll

    But how can i fix this error ?

    503 is usually a server-side error, hard to say. I suppose it could be on your end, but maybe try accessing the download link in a web browser.

    I thought at one point they were whitelisting certain user agents, but I tried downloading it via wget and the speed is pretty slow (20KB/s). So assuming the whitelisting is gone, but there may be an issue with the server/network-path I am hitting.

  • Docker or librelec add-on install fail

    relevant bits from log likely, 503 error fetching from https server:

    Code
    2023-02-02 14:34:30.442 T:987     DEBUG <general>: CAddonInstaller: installing 'service.system.docker' version '10.0.0.134' from repository 'repository.libreelec.tv'
2023-02-02 14:34:30.503 T:1010    ERROR <general>: CCurlFile::Stat - Failed: HTTP response code said error(22) for https://addons.libreelec.tv/10.0.0/ARMv8/arm/service.system.docker/service.system.docker-10.0.0.134.zip
2023-02-02 14:34:30.504 T:1010    DEBUG <general>: CurlFile::Open(0xd024ab70) https://addons.libreelec.tv/10.0.0/ARMv8/arm/service.system.docker/service.system.docker-10.0.0.134.zip
2023-02-02 14:34:30.606 T:1010    ERROR <general>: CCurlFile::FillBuffer - Failed: HTTP returned error 503
2023-02-02 14:34:30.606 T:1010    ERROR <general>: CCurlFile::Open failed with code 503 for https://addons.libreelec.tv/10.0.0/ARMv8/arm/service.system.docker/service.system.docker-10.0.0.134.zip:
                                                   
2023-02-02 14:34:30.606 T:1010    ERROR <general>: CAddonInstallJob[service.system.docker]: failed to download special://home/addons/packages/service.system.docker-10.0.0.134.zip
2023-02-02 14:34:30.618 T:987     DEBUG <general>: CGUIMediaWindow::GetDirectory (addons://repository.libreelec.tv/xbmc.service)

  • Dvb tuner unrecognized

    Quote from dtech

    The problem is that no low-level USB functions seem to work at the moment.

    It looks like a Pi Zero (don't have one), interestingly not even the internal USB hubs are detected. Something like this should be in dmesg:

    Code
    [    0.896406] hub 1-0:1.0: USB hub found
[    0.899593] hub 1-0:1.0: 1 port detected

    Which is why lsusb is empty. Possibly the wrong DT/overlay?

  • What "box" to buy ??

    Quote from Knotte

    Wifi hardware is pretty crappy on the Pi, I only get about 10 MB/s which is 80 Mbit/s, with my movies having about 65 Mbit/s.

    WiFi on the Pi4 is constrained by the bus, so 80Mbit/s is pretty typical cap. A supported USB dongle with 802.11ac will get you more bandwidth (270Mbit/s is what I get with a USB dongle).

    I would try using the cache settings in Kodi's advancedsettings.xml to smooth you through high-bit rate scenes and see how that goes, this one sets up a 512MB cache (which works fine on a 2GB Pi4, but you could probably live with 256MB):

    /storage/.kodi/userdata/advancedsettings.xml:

    Code
    <advancedsettings version="1.0">
    <cache>
        <buffermode>1</buffermode>
        <memorysize>524288000</memorysize>
    </cache>
</advancedsettings>

    HOW-TO:Modify the video cache - Official Kodi Wiki

    NOTE: It says it uses 3x memorysize, from my testing this is not accurate. Maybe it is outdated documentation, not sure. From what I could tell is memorysize is the limit and then it splits the buffer into a read behind & read ahead cache. IIRC read ahead cache is 75%, read behind is 25%.

    Also make sure you followed the recommended settings for 4K/HDR:

    https://wiki.libreelec.tv/configuration/4k-hdr


    As for the Vero4K+, it's relatively old hardware (S905D SoC released in 2016). As you noted, it is weak on the CPU side, it couldn't handle software decoding of Netflix @ 1080p, if you have a SmartTV then that would be the route to go. LE is also pushing mainline, which is where Amlogic SoC's still have gaps in support for HW decoding.

  • 0bda:b812 rtl88x2bu kernel module

    Quote from jernej

    Where did you pulled them from? You should apply rtw88 patches from https://github.com/LibreELEC/Libr…patches/default

    Same patch for linux-121-rtw88-linux-next-6-2.patch, and a newer version (Jan 8th) of linux-122-rtw88-fix-rcu-lock.patch (4 patches in the series, only noticeable change is a static assert to validate the structure size). Not the SDIO patch series. But I tested with SDIO patches and it was similar with an RTL8822BU dongle.

    Quote from jernej

    In aforementioned patches is a lot of locking fixes but hard to tell if a additional fix is needed without dmesg output.

    I'll have to borrow the dongle and put it in another Pi that is a bit more accessible. This one is in one of those aluminum cases and getting to the GPIO header requires removing the case.

  • 0bda:b812 rtl88x2bu kernel module

    Quote from chewitt

    Probably not for all hardware (e.g. I haven't picked all those changes for AMLGX) and I'm not sure they're present for RPi images either.

    They are not in RPi, but I pulled the rtw88 USB patches + fixups in and tested them. The USB drivers cause lock-ups and performance (~100Mbps via iperf) is worse than out-of-tree modules (~270Mbps). I haven't bothered to attach a serial console to see what is causing the lock-up, if it is a kernel crash or something else.

  • A95X F3 Amlogic S905W2

    Quote from chewitt

    frakkin64 I'm not sure that bug would be found in LE images since we aren't using EFI boot code paths in u-boot? - I can see how it would show up with dekstop distros though.

    I don't think it matters if your using EFI or not, at least that was my experience. I ran into it on S905 with Armbian, which isn't EFI either. Setting CONFIG_EFI_LOADER=n in u-boot fixed it up.

  • A95X F3 Amlogic S905W2

    Quote from lafleur

    found out that the kernel panics with an external synchronous error (I could post the traceback if needed)

    There is a known issue with U-Boot 2022.07 and later that causes a synchronous abort on Amlogic devices. The current workaround is to disable EFI in U-Boot, or use 2022.04 until it is fixed.

    Here is a recent chat about it:

    #linux-amlogic on 2022-12-28 — irc logs at libera.irclog.whitequark.org

    It may be the same issue, since it looks like LE11 is using 2022.10.

  • ERROR: cannot read `./usr/lib/libsqlite3.so.0.8.6'

    Quote from praaattee

    Is it all possible to force an update to replace that file?

    Yes, you would drop an update file (.tar or .img) in /storage/.update and reboot. But that won't fix your underlying issue, and likely would fail the update. You really need to investigate why you have bad blocks, i.e. some sort of surface scan/badblocks and resolve the uncorrectable errors. I don't know much about SSDs, never owned one, but if it has SMART then maybe initiate a extended or long test via SMART and review the device information when it completes -- no idea if that will work for an SSD. Maybe someone else with failing SSD experience will chime in to clarify the best approach for you.

    Quote from praaattee

    Or perhaps I can mount the disk rw, replace it, and then try?

    Not really, it's a squashfs filesystem mounted via loopback, so it's essentially a compressed single file on the /flash partition that is uncompressed and presented as a read-only filesystem. The /flash/SYSTEM file is that squashfs filesystem. As mentioned above, none of this would resolve your underlying problem and likely would make things worse, got to fix the root cause (which may mean a new SSD).