Posts by chewitt
-
-
Your nVidia GPU card has Linux drivers that either require Kodi to run under Xorg which doesn't support HDR let-alone DV, or GBM/Wayland which supports HDR, but doesn't support DV, and LE doesn't support due to the lack of refresh-rate changing support for optimal playback. Our general advice for the last decade is to avoid purchases of nVidia hardware as future support in LE is not guaranteed. The exception is the nVidia shield which is still the Android reference implementation for Kodi. I understand that it supports DV, whatever that means. I hear the OSMC vero5 box is good too. I can't speak for what CE claims this week/month/ever.
-
N2/N2+ use DDR4 while N2L uses LPDDR4 so it probably needs a dedicated image. I've never added one as the omission of onboard Ethernet means few people are likely to use one. It's simple to build though. See if this boots?
https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.aarch64-12.90.1-odroid-n2l.img.gz
If it doesn't boot I'll need to see output from the debug UART to see where things go wrong.
-
Now how do I access my media files from LibreELEC? I have installed the Jellyfin addon in LibreELEC.
Have you configured the Jellyfin add-on with the Jellyfin server URL and user credentials?
NB: If you installed the LE 'Jellyfin' add-on, you installed another Jellyfin server on the RPi4 and this isn't going to help you connect to the existing server. ISTR that Jellyfin has it's own client add-on which is sourced from their own repo.
-
This is not possible in LE images as the HDMI connection is active and HDMI cannot be audio-only, so even if the DSI connector to the touchscreen is also active the output plane detection logic in Kodi finds and prefers the HDMI connection. If HDMI output is not active then Kodi finds the DSI connection and uses that instead. You cannot disable the video output part of the DRM connector without also disabling audio as they are interdependent.
The two routes to making it work that you can explore (depending on skill levels) are hacking Kodi source to change the DRM plane detection logic, or perhaps building a custom image that runs Kodi under GBM/Wayland instead of GBM-only (or using RPiOS that does this). Running Kodi under a windowing environment should give you the option to switch the display output device. LE does not run Kodi under Wayland as it has no ability to switch/adjust refresh rates on-the-fly to match the media refresh-rate, but you won't have that option with the touchscreen anyway so it's not the dealbreaker it is with HDMI connections. We have Wayland support in our buildsystem as this is used by the Lakka retro-gaming fork to run their GUI, so you should be able to build a custom image.
-
I'd experiment with the VIM1 and P281 images in my share with extlinux.conf edited to use the p271 dtb.
If you mod the 'box' image with the Amlogic u-boot bumerc shared you need to edit uEnv.ini instead of extlinux.conf - You will probably need to trigger recovery boot mode too. The recovery button appears to be down the bottom of the 3.5mm audio jack, hence it's often referred to as the 'toothpick' method. You need to hold the recovery button in as the board is powered on and then release it after 2-3 seconds (once u-boot loads) and this makes u-boot search for recovery files on SD/USB media; and it should find the autoscript files that load the LE kernel.
-
S905L is the same CPU (opps) as S905W but omits VP9 codec support in silicon and (the important bit) uses Mali 450-MP2 not the normal Mali 450-MP3 so the kernel will lock-up when trying to bring the GPU online if using S905X/S905W device-tree files. I added support for S905L boards last year so there is a device-tree file (p271) that can be used, but I'm not sure that's the issue because u-boot is reporting S905W when reading chip properties. That kind of thing is commonly faked in vendor u-boot with cheap boxes, but we're using upstream. It's harmless to experiment with the p271 dtb file though.
I think it's more likely the board just has low-bin (out of spec) RAM chips that need timings to be tweaked to work.
-
What is the cause and how to fix this?
This is a bug in the widevine.helper add-on which has been fixed upstream, but might not be publised in an add-on update? - You'd need to check their release notes. I've seen the same a week ago when prompted to update. It won't ever complete, but unpacking has already been done so either restart Kodi or reboot the box over SSH and all should be fine.
-
The version I am using is ^ and since I wasn't prompted to update when initiating playback, I assume this is the latest. I don't really pay much attention to widevine versions as I rarely see issues with it. Service add-ons (Netflix, Prime, etc.) are normally where issues arise, as those pretent to be a browser (but are not browsers) and are thus more fragile and prone to breakage.
-
I've no idea about Netflix (as I don't subscribe) but the current/latest widevine libs are working fine with e.g. ViwX (for ITV in the UK) on an RPi5 and RK3588 board; both are aarch64 devices.
-
The current H265 decoder has seen no real-world development since 2020 and will be dropped from the kernel in the mid-term future. It is not possible to use the vendor kernel decoders because Amlogic implemented them around their own proprietary DRM (rendering, not media encryption) framework which aside from being poor quality code, would be a total nightmare to port to the upstream kernel, and also requires amcodec support in Kodi which was intentionally dropped back in 2018. I'm aware of two other Amlogic media codec efforts; one is also stalled with no current plan to resume. The other is being actively worked on, but I'm still waiting to see initial H264 code (with HEVC, VP9, MPEG2, AV1, etc. to follow) so this is not anything that will bring results soon.
-
-
This image is built using the VIM1 u-boot (2025.07) defconfig but using the p281 FIP files from bumerc
https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.aarch64-12.90.1-p281.img.gz
-
That ^ will stop the harmless error message about display service.
The AMLGX image is not for everyone. The H265 decoder is not fully developed and 'is what it is' for now. The only real-world way to fix seeking is to re-rip or re-encode videos to H264 which works much better.
-
That ^ will allow the downgrade. It won't brick the box, but you need to remove all Kodi add-ons and the libwidevine cdm folder (if anything uses libwidevine) as they were updated to newer aarch64 versions too. Also note that the Library will revert to the state it was in before you updated, i.e. it will not show any content added since the bump (you will need to rescrape).
NB: As there is no real-world difference in the state of the Amlogic hardware decoders in LE11 and LE12/LE12.2 there's probably no benefit to the downgrade. As you wish though..
-
I'll add rtw88/rtw8821a_fw.bin to the default firmware(s) that we pick into the image.
-
I can see PCI and ACPI warnings/errors in the system log and an iwlwifi 'microcode' (firmware) error/dump, and then GPU segfault messages once Xorg starts. As the nvidia drivers have faulted there is probably no DRM (Direct Rendering Manager) connector and GPU device visible to the kernel so the kmsprint command in the pastecrash script fails and you see the 'no modesetting' error.
I associate ACPI warnings and unexplainable things like firmware errors with power issues, so I'm wondering if the PSU is able to sustain the current draw needed in early boot and the spikes seen when the WiFi card and GPU are brought online. The GPU model suggests this is 10-15 years old hardware, so age could be a factor.
-
Does mainline u-boot work with LE? I made a test build with acs.bin for p281.
LE official images use 2025.07 while the ones in my test share should be using 2025.10. If you fork the amlogic-boot-fip repo on GitHub and push a branch with a 'p281' fileset containing that acs.bin and share a link, I can build an image using it.