Posts by frakkin64

    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.

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

    2023-02-02 14:34:30.442 T:987     DEBUG <general>: CAddonInstaller: installing 'service.system.docker' version '' from repository ''
    2023-02-02 14:34:30.503 T:1010    ERROR <general>: CCurlFile::Stat - Failed: HTTP response code said error(22) for
    2023-02-02 14:34:30.504 T:1010    DEBUG <general>: CurlFile::Open(0xd024ab70)
    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
    2023-02-02 14:34:30.606 T:1010    ERROR <general>: CAddonInstallJob[service.system.docker]: failed to download special://home/addons/packages/
    2023-02-02 14:34:30.618 T:987     DEBUG <general>: CGUIMediaWindow::GetDirectory (addons://

    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:

    [    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?

    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):


    <advancedsettings version="1.0">

    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:

    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.

    Where did you pulled them from? You should apply rtw88 patches from…ges/linux/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.

    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.

    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.

    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.

    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

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

    Still totally fine here. I am guessing your DNS has been diverted, or something along those lines. Nothing suspicious in the HTML either.

    I suppose is could be regional, not sure if the LE Team has a CDN or regional mirroring. But it could also be something on your end, worth checking out and making sure everything looks right on your end (i.e. another computer?).

    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.

    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).