Posts by chewitt

Quote from Da Flex

then it looks like an FFmpeg bug to me:

In logs "error" does not always equal a fatal problem. In fact most of the time it is nothing more than the application following some kind of if/then/else decision tree when processing data. Is the file mp3; no (so log error on that path, keep processing) is more likely to be the cause (or something of that nature). If you read the log further the file is clearly being played so it wasn't fatal.

BokitoNL You didn't share the output of pastekodi so we don't see the system log (only kodi log) but I'm not seeing anything in the kodi log to indicate an HDMI output problem. I would advise to check cables and ports and also ensure config.txt is in a clean or default state without any kind of helper overrrides being used.

I've moved this into its own thread as it has nothing to do with RK development.

As this is not an LE issue you should report the problem through the Kodi issue tracker (following the issue template else it will be auto-rejected and closed). NB: In recent years Team Kodi has been mulling a complete removal of profile support and then doing a ground-up reimplementation with a better overall design; the current one has too many problems. However it's a huge amount of work and so far nobody volunteered for the task, so it remains substandard.

Run "pastekodi" and share the log URL. Let's see if there's an obvious explanation.

Quote from mitzsch

Are there any fixes for the HBR audio dropout issue in that new build?

Nothing specificially targetting the unknown problem. Figuring that one out is beyond my skill level and using Claude needs a level of strong direction else (from experience) it will makes lots of insightful sounding but garbage triage while running in token-burning circles not achieving anything.

I've posted some fresh images for RK3566/3568/3576/3588 boards to my test share. The kernel bumps to Linux 7.0, but more interesting is the inclusion of work-in-progress Kodi changes that tonemap the OSD/GUI during HDR playback so that it renders with an SDR colourspace (while video remains in HDR) instead of searing your eyeballs. The greatest benefit is seen (literally) with subtitles. There's also some minor nip/tuck fixes for VP9 playback.

Enjoy

Quote from 25characterslong

Are all users that need to access wifi in the netdev group?

The netdev group exists in LE to appease a couple of binaries that insist there should be one, but it's empty (has no members) and it is not otherwise used. ConnMan runs as root, as does almost everything else in the OS.

Quote from wedok

Does anybody know what exactly i must do to get it working?

You need to self-build an LE image with their drivers or whatever hacks are required to make their cards work patched into the Linux kernel. We used to have driver add-ons that overlaid some of the so-called "popular" card vendor drivers; but those were a complete pain to maintain and over time nobody on staff wanted to continue/make the effort and they were dropped. We encourage users who want DVB cards that "just work" under LibreELEC or any other mainstream distro to vote with their wallets and purchase products from vendors who upstream their drivers/firmware and engage in mainline kernel support for their products. TBS make some nice hardware but do not fit that description. Caveat Emptor

It's probably an Allwinner H3 device, so moved to that subforum.

Quote from axel

When coming back to the device a few hours later, it had forgotten the wifi password as it was asking for it again. The device was no longer reachable on the network either. Is this a known issue? is there a place to track this bug?

It's not a general issue that we see with other WiFi drivers that we choose to include in LE images. Any issues with the aic8800 driver that we choose not to include in LE images are not something we're interested in taking bug-reports on. The Khadas driver repo would be a more appropriate place to log tickets.

NB: ConnMan stores WiFi credentials in a profile reference that contains the MAC address of the NIC interface so check the MAC address doesn't rotate/change after boot or on each boot. If it does, ConnMan will correctly see a 'new' connection and will reprompt for the passphrase again.

Some things to try (not in any specific sequence):

a) Remove the SD card and power on the RPi board. Check that the firmware screen shows up and HDMI and EDID are 'OK'

b) Check that you've updated to the lasted RPi-eeprom firmware? If not, update and try again

c) See if the image here https://chewitt.libreelec.tv/testing/LibreE…-12.90.1.img.gz behaves any different?

d) Using a spare SD card write the nightly image to the card (so clean install not update) .. booting?

I'm using an RPi5 with my own nightly image for aeons without issues so there's no general problem. I have a hunch it might be eeprom firmware related (b).

Quote from Da Flex

Try the latest LE 13 nightly. It has some fixes for the WiFi driver.

How do you imagine the WiFi driver is linked to this issue? (or did you reply to the wrong thread)

Ensure the wireless regulatory domain used by the RPi is aligned to the one used by the router; else the router may decide to use radio configurations that the RPi cannot handle (or vice versa).

Read the explanation given in [RPi5] H.265 TS Severe Artefacts when Skipping Backwards and continue there if needed.

You can delete the Addons DB file and it will be regenerated on next boot from the add-ons found in /storage/.kodi/addons though you might need to manually (re)enable some of the add-ons again. You can also delete the EPG database as this contains transient data and will be repopulated from Tvheadend.

The online repo the .tar.xz file is downloaded from has (for unknown reasons) regenerated the download and this has caused the hash of the downloaded file to change. We see the same on GitHub sometimes.

The correct fix is updating PKG_SHA256 in package.mk to use the 'got' hash value instead of the current 'wanted' hash. The alternate workaround is setting PKG_SHA256="" (null) which disables the hash check. The one-line command vpeter posted does this.

https://git.zx2c4.com/wireguard-tools/snapshot/wireguard-tools-v1.0.20250521.tar.xz

This URL ^ (correctly formatted, unlike the one you posted) works fine for me.

Or bump bump the wireguard-tools package to the current release, e.g. https://github.com/LibreELEC/Libr…ools/package.mk

Or download the .tar.xz file from somewhere else (and storing it with the correct filename) to sources/wireguard-tools/ and then manually generate the required .url and .sha256 files and content (look at existing files to crib the simple format).

Quote from Da Flex

Doesn't the kernel detect devices at boot time?

It should, but the user has provided zero evidence that it did, and they've also been fiddling with files they shouldn't. So the normal protocol is to ask for evidence (the LE13 pastekodi output, which will show the full EDID block, full log, and system log) so that blind guessing isn't involved.

cp /usr/lib/udev/rules.d/95-udevil-mount.rules /storage/.config/udev.rules.d

Clone the udev rules file ^

# check for blockdevices, /dev/sd*, /dev/sr*, /dev/mmc*, and /dev/nvme*
SUBSYSTEM!="block", KERNEL!="sd*|sr*|mmc*|nvme*", GOTO="exit"       <= edit this

# check for blockdevices, /dev/sd*, /dev/sr*, /dev/mmc*, and /dev/nvme*
SUBSYSTEM!="block", KERNEL!="sd*|sr*|nvme*", GOTO="exit"            <= to this, i.e. drop mmc*

Then edit the file using nano and change this block towards the top of the file ^ then save/reboot to effect the change.

The change means for any mmc* blockdevice it skips straight to exit and doesn't process partition mounting. NB: This will also prevent SD cards from ever mounting as those are also mmc* devices. I doubt you need that though.