Posts by frakkin64

On Samsungs make sure Input Signal Plus is enabled.

1. Settings > General > External Device Manager > Input Signal Plus

2. Choose HDMI port you Pi4 is plugged into.

Reboot your Pi4, after enabling 4k60 in config.txt, and you should see the 60Hz refresh rate.

The other thing you may want to do is disable motion smoothing, that is only available when a 4K resolution is displayed (and I think you have to adjust it for each refresh rate). That is under Settings > Picture > Expert Settings > Picture Clarity Settings, you will want that Off.

As a side note, I personally have yet to see/find any content in 4k60.

Quote from chewitt

Is that the 4K (S905X) or 4K+ (S905D)? .. I'm still waiting on a positive test report to send it upstream.

I have the 4K+, which we tested already and I am enjoying the labors with LE & Armbian. Just being lazy with the extra character, it's too far from my fingers.

Quote from chewitt

Sam did promise to submit the FIP sources for his boards at some point (prob. minus the BL32 bits, but those are optional) .. but then he's also promised to test the 4K (for six months) and send me samples (for two years) so I'm not holding breath. Running your own business is time-consuming

Yeah, that would be nice to see. The FIP sources, maybe, are in Github -- but considering the last commit is 2017 and I have received bootloader updates since then I don't trust it's current. It's minus the bl32 bits, of course. All of the commits after Amlogic are purely cosmetic.

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.

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.

There is another addon for installing Widevine, you can google for "SlyGuy Common" and see if that works. It doesn't use ChromeOS images, instead he hosts installs for the library.

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.

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

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:

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

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:

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

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.

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.

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.

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.

Looks like SQL is poorly formatted in Kodi. It appears it was introduced in PR #19578 upstream. There may be other SQLs that were reformatted with similar issues.

You can try applying this patch and spinning your own build of LE:

net: phy: add support for Motorcomm yt8531C phy - Patchwork

Looks like it is deferred until 6.2.

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

Totally fine here.

Quote from praaattee

Unfortunately, I am unable to get full debug logs because Kodi does not start.

If you can login via ssh, then run "pastekodi" and paste the URL. It's mentioned in the wiki link.