Posts by HiassofT

Addon builds for Generic just finished (ARM is still running) and the second version, with per-addon display configuration is now in the repo.

Please update, test and report back again.

so long,

Hias

Thanks for reporting back!

Default should use whatever is configured as default-sample-channels setting in PA's daemon.conf - default value is 2, so same as stereo.

I just added it for completeness before someone comes up with requesting it and I have to touch the code again

so long,

Hias

The first version (with multichannel support for moonlight) is now in the repo, would be nice if you could give that a try and report back if it works.

Addons with yesterday's PR (adding per-addon display configuration) still need to be built (our CI is quite busy, image and addon builds take quite a lot of time).

so long,

Hias

Quote from nissel

On a related note could the display configuration that's currently in the External Programs helper add-on be added to the moonlght add-on settings too? As I would like to be able to run VacuumTube at 4k60 but moonlight at 1440p120.

I found a good solution and opened a PR: https://github.com/LibreELEC/LibreELEC.tv/pull/11989

so long,

Hias

Quote from nissel

On a related note could the display configuration that's currently in the External Programs helper add-on be added to the moonlght add-on settings too? As I would like to be able to run VacuumTube at 4k60 but moonlight at 1440p120.

Ha, I knew this request would come up at some point

I'll need to think about how to best implement that without duplicating too much code - pretty much all flatpak addons might benefit from a separate display config, and I suspect some other flatpak addons could want the audio config as well.

so long,

Hias

Thanks for the hint that moonlight can support surround sound output, I've now implemented that and added a setting in the moonlight addon https://github.com/LibreELEC/LibreELEC.tv/pull/11985

I also noticed that stereo-upmixing should actually have been disabled by default in LE about 9 years ago, but the change was buggy and had no effect - and no one seems to have noticed that yet

I've also opened a PR for that https://github.com/LibreELEC/LibreELEC.tv/pull/11986

so long,

Hias

Quote from chewitt

I don't think this would cause problems. The patch caps the DRM connector at 10-bit output to prevent it ending up in 12-bit which results in bandwidth issues when HBR audio is present. For DV output we are tunnelling in 8-bit RGB and avoid the problem. I don't see DV issues with a Generic build based on current development running on an N150 box.

That patch is a hack though, so a candidate for improvement as userspace vs. kernel colour support evolves.

I'm not convinced it's a bandwidth issue, even 720p has enough bandwidth for HBR audio. More likely they got their N / CTS values wrong or have some other clocking issue (that's just an educated guess though, I'm not familiar with the intel driver).

ashlar could you give this build a try: https://www.horus.com/~hias/tmp/libr…-50716e4.img.gz - that's current LE master with the "10bit hack patch" dropped.

No idea if this actually helps (guess video output might then be at 12bit instead of 10) but it would be an interesting data point to know if this patch has some (negative) impact.

so long,

Hias

This sounds a lot like it might be triggered by this 10bit-hack-patch

chewitt I guess this patch should better be dropped and intel devs need to fix the issue properly

so long,

Hias

Quote from offbeat

Hope it's better now, can Kodi bind to every evdev code from linux/input-event-codes.h now, or it's still limited?

No, not every evdev code, but pretty much all codes commonly found on multimedia keyboards and remotes.

If something is missing you'll need to tell us about it (kodi debug log, which specific remote, which button and the evdev code).

so long,

Hias

Another quick tip which I forgot to mention:

While longpress support (eg the default longpress-enter or longpress-ok to bring up the context menu) is quite handy for remotes with few buttons it adds a small delay - kodi reacts on button-release (as it needs to check if a button was held down for more than half a second) instead of button-press.

If you don't need longpress support for some buttons you can simply override the longpress action with "noop", this removes the longpress mapping and kodi will react faster (as it can now react on button-press instead of release).

eg:

<keymap>
  <global>
    <keyboard>
      <ok mod="longpress">noop</ok>
      <enter mod="longpress">noop</enter>
      <browser_back mod="longpress">noop</browser_back>
    </keyboard>
  </global>
</keymap>

See /usr/share/kodi/system/keymaps/keyboard.xml for the default mapping, some buttons have additional longpress mappings for other windows, too (eg in FullscreenVideo).

so long,

Hias

There's now a kodi Piers PR to update taglib to 2.3.2 https://github.com/xbmc/xbmc/pull/29889 so 22.0-rc2 on Windows will likely include that as well.

so long,

Hias

LE13 has updated to taglib 2.3.2 about a month ago: https://github.com/LibreELEC/Libr…glib/package.mk

Kodi 22.0-rc1 on Windows likely uses the bundled 2.3.1 version https://github.com/xbmc/xbmc/blob…/TAGLIB-VERSION plus an additional patch https://github.com/xbmc/xbmc/blob…nt-lookup.patch

Edit: there's a kodi PR to update taglib in master to 2.3.2 https://github.com/xbmc/xbmc/pull/29839 - but it's not flagged as "Backport needed" so might not land in kodi 22 / Piers

so long,

Hias

A shot in the dark: you could try adding dtparam=eee=off to config.txt and see if this helps.

so long,

Hias

Quote from VLouis

Hi, thank you, that's good news, any information if that will be implemented on RPi3 too?

I tested on my RPi3B+ and it worked fine there, too - but you need to wait for a nightly build (the 20260919 RPi2 build doesn't include the fixes yet).

I haven't tested with the non-plus RPi3 but I suspect it won't work with it as it has a different wifi chip.

so long,

Hias

WPA3-SAE should now work fine on RPi5 and RPi4 with the latest LE13 nightly build
https://test.libreelec.tv/13.0/RPi/RPi5/LibreELEC-RPi5.aarch64-13.0-nightly-20260920-b68ee23.img.gz
https://test.libreelec.tv/13.0/RPi/RPi4/LibreELEC-RPi4.aarch64-13.0-nightly-20260919-b68ee23.img.gz

so long,

Hias

No, you can't install deb (or rpm, ...) packages on LibreELEC.

But you could run a docker container with a minimal Debian version (eg trixie-slim) and install the deb in there (eg in a Dockerfile)

so long,

Hias

Scroll up a bit and you'll notice it's inside a if SND_DRIVERS block

linux/sound/drivers/Kconfig at master · torvalds/linux

Linux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.

github.com

so long,

Hias

You also need CONFIG_SND_DRIVERS=y

so long,

Hias