Posts by chewitt

    I'd use the RPi5 as the main device as it's a nice bump on the RPi4, and recycle the RPi4 as the Tvheadend server (as RPi3 is working with pihole and doesn't need speed). No idea on what USB tuner(s) device to use though, as not a UK resident.

    I'm running an NVME drive on my own RPi5 and the speed difference over a fast SD card is not some "oh wow, that's so amazingly fast" gain, it's a more marginal improvement. The difference between gen2 and gen3 speeds is even more marginal and if you are perceiving there's a difference I'd argue it's more placebo effect than something you can see/feel in the user experience. If you do want to test things, iPerf can be installed from one of the tools add-ons.

    This is the custom /storage/.config/xorg.conf that I used to use with a GT520M: https://chewitt.libreelec.tv/xorg.chewitt

    The main point is "NoEdidModes" to ignore what the TV reports over HDMI and then hardcode the modelines. The original reason for doing this is to increase the accuracy of the fractional rates (23.976, 29.97, 59.94) as Xorg default calculates to 2x decimal places and this results in occasional skipping, and increasing this to 4x decimal places with fractional rates improves modeline accuracy. It will not eliminate skipping, but it will happen less frequently - to a level where it's rarely noticeable.

    The modelines in that file are based on what I saw reported on that specific TV, so no guarantees they will work on your TV, but you can crib the format and experiment with likely values that you see in the systemd journal with Xorg started in debug mode.

    if I use that test image you provided, will I be able to upgrade to the next release?

    The test image is based on LE13 nightlies and Kodi doesn't support downgrades. If you stop Kodi, remove /storage/.kodi, then update to LE 12.0.2 you'll end up with a working install as we don't touch u-boot (where the test patch was applied) after install.

    It might be easiest to stick to LE13 nightlies though. I've been using them (albeit on an RPi5) for months and things are stable. I'm not aware of anything that should be different on AMLGX other than it being AMLGX and thus less reliable than an RPi5 /shrug

    I've the same questions about why some users see this and not others. I have a hunch something changed in kernel or u-boot so it affects only new installs beyond a certain (unknown) point. I don't think it's related to board revision, although I know my board is from the last production batch that HK made; C2 was discontinued shortly after HK posted a sample to me.

    It fails to initialise the Broadcom WiFi chip on the device; hence no WiFi.

    I'm not sure what the issue is, but as a starting point please retest with the VIM3L image from https://chewitt.libreelec.tv/testing/ which is using a newer kernel.

    Code
    Feb 27 17:26:04.259217 LibreELEC kernel: Memory: 1523152K/2093056K available (13696K kernel code, 2220K rwdata, 3936K rodata, 10432K init, 856K bss, 45616K reserved, 524288K cma-reserved)

    The RPi5 2GB model was launched shortly after we shipped LE 12.0.1 and it requires some specific mesa graphics patches that don't exist in the 12.0.1 release. Use the latest nightly from https://test.libreelec.tv/12.0/RPi/RPi5/ (scroll down) and it should work fine.

    RPi4/5 boards don't support 4K60 at HDMI 4:2:0 which causes some issues with TV's that default to that mode. This is when config might be needed on the TV side to enable special modes (LG calls it Deep Colour, no idea what Sony might call it). However that issue will normally result in 4K50/59.94/60 modes not being detected and thus not being usable. It doesn't normally prevent you seeing the Kodi desktop. In your case it looks like something is being rendered (but messed up).

    If you add "video=HDMI-A-1:1920x1080M@60" to boot params in "cmdline.txt" (all on one line) it will force the initial HDMI output on the HDMI connector nearest the power connector to 1080p, which will eliminate a 4K issue from suspicion. If you also add "ssh" to boot params it will force the SSH daemon to start so you can SSH into the device to run "pastekodi" and share logs (share the URL generated here).

    Boot from USB and set "BOOT_ORDER=0xf461" via "rpi-eeprom --config" so the device can boot from NVME, then power off. Now image the M2 drive with the RPi5 image (same as you created the USB). Once imaging is complete, edit config.txt on the M2 drive to add "dtparam=nvme" then attach the NVME drive to the RPi5 and it should boot (make sure the USB drive is disconnected).

    The system log shows kernel boot in six seconds, which is overall fast. That likely means the delay happens on the Apple firmware side; figuring out what EFI firmware bootloader to use. If other OS boot faster, perhaps see what bootloader they use and think about switching the LE install to use the same one. That might ential a little experimenting and reworking of boot config files, but the format of e.g. grub2 vs. syslinux are fairly similar so it's not impossible. There is of course no wiki article or nice HOWTO guide for that so you'll need to take the initiative.

    The Apple IR receiver shows up as a Linux input device so you should be able to experiment with https://wiki.libreelec.tv/configuration/…ration-advanced to see if other remote devices are detectable (probably).