Posts by chewitt

Possibly https://github.com/xbmc/xbmc/issues/25305

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.

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.

I've seen another report of not being able to boot the LE12 installer (where LE11 worked). The issue was just in the installer though, so once LE11 has installed to the internal drive you should be able to update to LE12.

The Generic image should have the brcmfmac driver for the card included, but it might be missing the firmware, which can be easily solved: https://wiki.libreelec.tv/how-to/add-firmware

Some morons store their media inside .tar/.zip files to save space, so Kodi has the default capability to read the media inside archive files to create thumbnails and show fanart and other nice things in the GUI.

TL/DR; don't save/store large backup .tar/.zip files in directories that Kodi will scan for content.

It's probably an issue with the Tidal2 add-on.

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.

Quote from Cabal

Why would changing from Limited to Full RGB change this? Does the AV1 decoder have a dependency on Full RGB?

That's sending the conversation in the wrong direction - ignore.

popcornmix any ideas?

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.

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.

No debug log .. so nothing to investigate

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.

In the ideal world all our PR's compile without issues, all the dependant services have 100% uptime, and all the build servers have infinite disk space. Reality is often different.

The fix will be in official LE nightlies from tomorrow so that's expected. No need to check anything.

The fix is merged for next nightlies. If you need something sooner https://chewitt.libreelec.tv/testing/LibreE…h64-12.80.0.tar has the fix included.

Android boxes either power-on when you apply power or they have a power button on the case to turn on. If yours has no button, the box is powering on but failing to boot. This could either be a hardware failure (eMMC device gone bad) or a software problem (flashing the wrong ROM to eMMC and breaking boot) or a combination of both (eMMC is bad so the ROM flash fails). UART boot logs from the device are the only way to see what is happening during early boot to understand device state. If you cannot share UART logs there is nothing more we can do. NB: Even if you can, our help is going to be limited: this is a forum for supporting our distro so there is no magic ROM archive to help with reflashing Android and we have little interest in fixing broken boxes.

This is the fix: https://github.com/LibreELEC/eventlircd/pull/4

EDIT: It still needs some work, but we're aware of the issue and it will be resolved.

EDIT2: Now resolved, so next nightlies should contain the fix.