Posts by chewitt

    LE mounts the second partition on the SD card as /storage and uses this for persistent data, e.g. Kodi saves to /storage/.kodi - the rest of the filesystem is decompressed from the SYSTEM file on boot and is read-only so it's hard to mess things up.

    See https://wiki.libreelec.tv/configuration/…ration-advanced for instructions on creating and configuring a custom IR keymap. The remote will use the rc6 protocol so there might be existing keymaps that work, but it's normally quicker to transcribe one from scratch than test all the existing ones trying to find the one that exactly matches (there are lots of them).

    It's impossible to guess what might cause Kodi to get stuck on the logo without seeing log files. If there is an issue in the OS it might be visible from the UART output. If there's something in Kodi .. you can enable persistent logging via the LE settings add-on and then check the logs (or look for crash logs) on the next clean boot.

    CE and Armbian should be able to boot using the same u-boot, but their boot files are differently named, e.g. CE uses dtb.img and kernel.img so you might need to rename their files to match LE conventions. Updates would also not work, although GXL devices are no longer supported yb CE so there will be no updates. Armbian will be different again. I'm not sure what changes bumerc has hard-coded in u-boot, but as long as you can boot to the u-boot console via the UART cable changing the scripts stored in the u-boot environment will always be possible.

    Kodi does not support downgrades so place the .img.gz file in /storage/.update/ then stop Kodi and remove /storage/.kodi so that on reboot after update it starts with a clean Kodi config.

    I would stick with the LE13 image though, it won't be less reliable than LE12.2.

    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.

    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.

    Code
    debug <inputstream.adaptive>: [WV-CDM-Library] CDM version: 4.10.2662.3

    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.

    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.

    Code
    touch /storage/.update/.nocompat

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