Posts by chewitt

  • N2 kernel issue

    There's a drip-feed of bindings changes and other unimportant things to DRM code; nothing of any real meaning was changed in aeons. I also have an N2+ running here for boot testing LE changes and I'd notice kernel splats (none seen).

  • N2 kernel issue

    I've moved the post into its own thread as the UART log shared shows the system boot from SD card without any errors (and thus whatever the issue is, it's not the same thing the C2 thread is about). Something goes wrong when it boots the kernel. The splat suggests something with the HDMI driver (so something in the display chain).

    Can you successfully boot from an eMMC module to prove it really is SD related (which it almost certainly isn't)?

    Can you successfully boot this image? https://chewitt.libreelec.tv/testing/LibreE…droid-n2.img.gz

  • HDMI Audio too fast before silence

    Please provide a full debug log.

    How to post a log (wiki)

    1. Enable debugging in Settings>System Settings>Logging
    2. Restart Kodi
    3. Replicate the problem
    4. Generate a log URL (do not post/upload logs to the forum)

    use "Settings > LibreELEC > System > Paste system logs" or run "pastekodi" over SSH, then post the URL link

  • NUC10 + LE13 + HEVC

    The error is reported by FFMpeg though since it's in codec code (and switching to software decode works around it) the problem could equally be in the underlying Intel drivers. If you are into self-building images and experimenting there are pull-requests for kernel bumps to Linux 6.9.5 and 6.10-rc3/4 open on our GitHub repo. Bumping FFMpeg to something newer is harder as Kodi has hard API dependencies; v7.x won't be possible but a later 6.x release might work. `At some point we'll move LE13 to Kodi 'P' which will bring a bump to FFMpeg v7.x too, but until then there's not much to do I think. I would be very surprised if it had anything to do with BIOS as that's low-level and codec things are some way above.

    NB: The whitelist suggestions here would help your overall config https://wiki.libreelec.tv/configuration/4k-hdr but will make no difference to the reported problem.

  • NAS Storage

    The format in /storage/.kodi/userdata/sources.xml and /storage/.kodi/userdata/passwords.xml is simple to crib so I never bother adding sources from the GUI these days; it's much faster to do it from the SSH console using nano.

  • Bricked MXQ Pro 4K

    Moving to a separate thread as your problem has nothing to do with the (entirely different) WeTek Hub issue.

    Amlogic boards always boot from eMMC if signed Amlogic boot code is present in the right sector on eMMC, and you have flashed a ROM image with incompatible (has the wrong RAM chip timing details) u-boot to eMMC so the board is stuck in a boot loop.

    The best option is (re)flashing the original Android ROM to eMMC using Amlogic Burning Tool to restore the correct u-boot. The less simple option is manually shorting pins on the eMMC flash chip to temporarily disable the chip so it is not seen and the board will then attempt to boot from SD/USB media. It's not difficult to short the pins, but the problem will be finding a signed u-boot version that supports the board (as they need to support the right RAM timing data) and supports booting from SD card (as the compatible u-boot in an Android ROM will be for eMMC boot and on GXBB/S905 that means the AML signature in the wrong location).

    I do not have a collection of old Android boot ROMs (aside from WeTek Play2/Hub) and the only GXBB boards LE provides bootable SD card images for are WeTek Play2 (and Hub, but that has issues), Odroid C2 (which will not boot on anything else due to internal hardware checks), and the NanoPi-K2. So our options are limited and I have low time/interest in changing that.

    Searching for old S905 MXQ Android ROMs is the right direction. Flash them and see if they at least boot to a kernel. If they do you can force recovery boot to run Linux again. If they don't, you didn't make anything worse than it already is.

  • [x86-64] HDR Playback

    Kodi supports upgrading. It does not (and never has) supported downgrading. In LE the OS packaging (everything in the read-only SYSTEM file) means the core OS and Kodi itself will downgrade fine, and newer Kodi DB versions created during upgrade will be ignored. However settings, add-ons, and add-on settings in the persistent /storage area were updated from LE10 to LE12 and those do not downgrade and will not be compatible with LE10. If you manually delete /strorage/.kodi/addons/* it will probably work again. If not, you might need to trash /storage/.kodi/userdata/guisettings.xml as well. And no guarantees on /storage/.kodi/userdata/add_data/* settings being compatible either. You may end up needing to clean reinstall.

  • LE 12.0 - Pi 4B 2GB - Unable to update library: Compressing DB 0%

    Code
    2024-06-16 13:46:58.137 T:936     error <general>: CCurlFile::Exists - <dav://USERNAME:[email protected]:5000/Films/> Failed: Weird server reply(8)
2024-06-16 13:46:58.137 T:936   warning <general>: Process directory 'dav://192.168.16.102:5000/Films/' does not exist - skipping scan.

    Do you see the same issue if you use SMB instead of WebDAV?

    I suggest this because "Yes, Kodi supports WebDAV" but I don't recall any of my Team Kodi colleagues ever admitting in public that they used WebDAV to access media, so it's almost never being tested among wider changes. SMB in comparison; is being used all over the place by everyone and will probably just work.

  • FFMPEG cannot stream and decode with MPEG-DASH.

    I guess it did't work because the tidal2 add-on depends upon inputstream.ffmpegdirect and not the native ffmpeg version used by Kodi that we patched in the image; so the patch is still effectively missing.

    mglae submitted changes to make changes to ffmpeg and ffmpegdirect earlier, which are now merged, so if you wait patiently for 24-48 hours those changes will have arrived in the latest LE13 nightly and updated add-ons in the LE13 add-on repo.