Posts by chewitt

The blanking is loss of sync on the HDMI connection. Common causes are using bad HDMI cables, bad HDMI adapters, the HDMI connector (the DRM device in the kernel) being forced to output using a mode that's outside the display device specs (can happen when EDID data is incorrect or has been incorrectly fiddled with), or the hardware being rubbish, and inadequate power supplies.

In general I would set this:

• Force the initial DRM state (as above)
• Set the Kodi desktop to 50Hz
• Set 'adjust-refresh' in playback options
• Enable the whitelist and only select 50/60Hz 1080p resolutions
• Enable rate doubling and 3:2 pulldown

No idea if that will work though. In general I've always found monitors to be a bit rubbish compared to a proper TV.

I'm not seeing anything in Armbian patches.

I'm no expert on Allwinner hardware, but I had a quick look at the device-trees in the Linux 6.17 kernel source, our current Allwinner patchset, and kernel mailing lists (for new patches) and I see no evidence of HDMI support for the H616 or H618 chips existing. This means you will see boot screens due to framebuffer support in the kernel, but there's no HDMI (DRM) driver, so Kodi cannot run.

If you add 'ssh' to boot params in extlinux.conf the SSH daemon is forced to start and you can login, but you'll only see kodi.log messages about there being no DRM surface or gem object to render to.

Quote from Yasai-san

Just report only, I don't make pull request for this.

The current AIC8800 driver will not be accepted into our codebase. The driver code is poor quality and needs a ground-up rewrite and Radxa has no plan for that. We would be stuck with a bad out-of-tree driver. Our instruction will be for users to vote with their wallets and not-purchase any boards using that chip; unless WiFi is not a requirement.

video=HDMI-A-1:1920x1080M@50D

On devices that boot a modern Linux kernel append this ^ to kernel boot params and the HDMI connector will be forced to that resolution/refresh on boot. This applies to AMLGX images too. I've no idea about CE images (as never used them).

a) This is an English language forum. If you want to post in your own language; also provide an English version of text.

b) We don't support Kodi on Windows; use the Kodi forum for that.

c) We don't make recommendations on hardware we don't have/use - but LibreELEC is $0 so it costs you nothing to experiment and find out what works best for you.

Quote from tokul

OP did not tell, if they are using Jellyfin or Homerun

Jellyfin does not support transcoding on the Amlogic hardware used in the current box and the OP is asking about an alternative to that box with local storage. So "being able to transcode using Jellyfin on the NAS" is not really part of the requirement, is it?

Quote from tokul

NAS setup would also depend if user wants to run network media server on libreelec or on nas.

Nope, the NAS can be just a dumb storage device in the network. You can push the local media DB there too (MariaDB, etc.) if you have more than one client, but Kodi is not a true 'server' app that supports 'client' devices. If you want to run alternate non-Kodi server apps that's a different topic, but displacing Kodi wasn't in the original question.

It was merged already so the fix is in LE12.2 nightlies.

I would invest in a NAS box that sits in the network with a physical cable connection to the playback device. Then you can keep the current "does everything I need it to do" playback device; and in future change that device without storage features dictating the hardware options. The initial up-front expense is paid back over time in lower effort and cheaper future updates.

The general advice for HDMI issues is to physically disconnect everything and leave powered off for 10-mins, then reconnect cables and see if anything fixed itself (as it often does).

The getedid script solves a single and specific problem; the TV not being powered on before the RPi starts. That's the only issue it solves. It does not solve CEC problems. It does not solve any other HDMI problems. Do not use it, unless you have that issue.

Quote from kai1024

My understanding is that I just have to add this as package.mk to packages/linux-driver-addons and it will be picked up during make image?

Not quite. Create the package folder and mt76 package.mk under packages/linux-drivers and test built the driver to ensure it compiles with e.g. PROJECT=Generic ARCH=x86_64 scripts/build mt76 then add the package to ADDITIONAL_PACKAGES in an appropriate 'options' file; either distro, project, or device level and the package will be built as part of a normal image build. Here's an example package.mk (for a realtek wifi driver): https://github.com/chewitt/LibreE…dd77d9cfa1d713e - no idea if that would work as-is or needs changes.

The easier option would be to enable CONFIG_MT7925E=m in the kernel defconfig, as it's a one-line change and then you're using an upstream supported in-kernel driver. Just edit the relevant defconfig and rebuilt the image; the defconfig change will be detected and the kernel will be rebuilt automatically. NB: I've no idea if the driver needs firmware, but that can be manually added if needed, or you can edit the firmware pick file, either at project level or the x86_64 default one under the kernel-firmware package.

Quartz64B doesn't find boot media on mmc nodes; probably because there is no eMMC module and for some reason the SD card is not detected (and shows a reset failure). I've no idea what the issue is, but I'll have a look at u-boot sources later.

OrangePi 3B is booting vendor u-boot (2017.09-orangepi) so you need to erase that from SPI or wherever it's been stored.

Yasai-san Focus on reporting non-working devices (working ones are not interesting). Provide UART log output because it shows where the problem is. Your list is confusing because it shows Odroid-M1 in both working and not-tested. It shows Quartz64-A in both working and non-working.

NB: Rock3C, Rock4D, Rock5B are all working fine (tested by me).

The RK3588, RK3576, and RK356X images in my test share have been updated to u-boot 2025.10-rc4. The bump drops quite a few now-merged patches from the patchset, but no idea if it also fixes anything?

RK356X images in my share now have a working OSD in Kodi and what appears to be working HEVC support. RK3566/3568 appear to be a bit forgotten; the hardware is largely derivative of RK3588 so e.g. the same vdpu381 decoder can be added easily, but as these chips are not targetted by any funded Collabora development, they aren't being tested (by Collabora) with numerous in-flight patch series. Hopefully LE crowdtesting will fill some gaps. I'm also noticing that MPEG2 support (hantro) has issues with some of the test media that I have, but I haven't been able to spot patterns.

Quote from Yasai-san

I can't find yet which commit affects it because v2025.10-rc1 has 1025 commits from 2025.07.

RK3588 boards should be usable without the additional patches that LE is using (which are mostly for 3576 support) so clone u-boot sources and start a git bisect to track success/failure, but use the githashes (and no patches) in the LE buildsystem. No matter how large the number of commits difference between the start points is, bisect will find the breaking commit within 8-10 moves, and if the rest of the LE image is static this is probably no more than an hour of effort. NB: I normally edit scripts/uboot_helper so I don't waste time building images for hardware that I won't be testing with.