Posts by HiassofT

Quote from vpeter

And here it is

Sorry, I wasn't aware of this thread when I implemented flatpak support

so long,

Hias

Quote from chewitt

The "throttled" message would be a thermal issue not a PSU issue. You're thinking of "undervolt" perhaps.

The throttled bits report both undervoltage and temp limit throttling, see eg [How to] Interpret RPi vcgencmd get_throttled

When it comes to USB it gets a bit more complicated:

The USB ports on RPi4 have a total 1.2A current limit (all ports combined) and if that's exceeded there'll be a voltage drop on the USB ports - but that won't show up in the throttled bits as long as the power supply can deliver the 1.2A for USB plus the power needed by RPi.

If there's a voltage drop on the USB ports pretty much anything can happen. Depending on the USB device it might lock up, go into a (temporary) error state resulting in kernel log errors or silently corrupt data on the USB HDD/SSD.

As a rule of thumb don't connect more than a single bus-powered USB HDD/SSD/DVD to the RPi, use a powered USB hub in between - and if you see odd issues connect all USB devices to the powered USB hub.

so long,

Hias

The nightly with the fix is now available:
https://test.libreelec.tv/13.0/Generic/Generic/LibreELEC-Generic.x86_64-13.0-nightly-20260602-9c34052.img.gz

so long,

Hias

Quote from joe65

gputemp has vanished on pure Intel since ~2 weeks (System Info => Video)

This is fixed by the PR as well and will be included in the next nightly.

so long,

Hias

I've managed to identify the culprit, it's our custom gputemp script which gets called whenever you open the player process info overlay or the system info window.

I've created a PR with the fix:

Generic: gputemp: use nvidia-smi only if an Nvidia card is present by HiassofT · Pull Request #11414 · LibreELEC/LibreELEC.tv

Running nvidia-smi on a non-nvidia system causes a long delay as nvidia-smi will try to load the nvidia kernel driver if it's not present.

github.com

so long,

Hias

Can you please test with the 20260511 and 20260512 nightlies and report back if resolution switching works with those?

https://test.libreelec.tv/13.0/Generic/Generic/LibreELEC-Generic.x86_64-13.0-nightly-20260511-f6935c9.img.gz
https://test.libreelec.tv/13.0/Generic/Generic/LibreELEC-Generic.x86_64-13.0-nightly-20260512-e916680.img.gz

I have a gut feeling that the issue might be caused by the Intel hack-patch that was added in the 20260512 nightly.

If you get the garbled screen in both nightlies please test with earlier nightlies between 20260504 and 20260511 and post the first version where the issue occurs.

so long,

Hias

Use DEVICE=Generic, that's the official name and gbm

so long,

Hias

Quote from JohnWayne111

will HyperHdr v22 will be available if the beta status has gone?

Yes, I've already tested early betas here (and reported issues). Just waiting for v22 final to be released.

so long,

Hias

LibreELEC doesn't use wayland (and also not pipewire) so the link you mentioned is not relevant to LE.

Currently there's no reliable way to use it without an external grabber, there's an experimental drm-vc4-grabber but it has known issues (kodi crash after a few seconds) and a PR that's supposed to fix those is in limbo for quite a long time now:

GitHub - rudihorn/drm-vc4-grabber: A screen grabber using the DRM for the raspberry pi.

A screen grabber using the DRM for the raspberry pi. - GitHub - rudihorn/drm-vc4-grabber: A screen grabber using the DRM for the raspberry pi.

github.com

I haven't tested this software grabber yet, instead I use a HDMI splitter plus grabber (which cost me about 40 or 50 EUR total, can't remember) with HyperHDR on my RPi5.

so long,

Hias

Quote from Nofan Tasi

Now shall I install current official Team LibreELEC 12.80.7.0 or (and test again) or wait for a higher next version?

No, wait for the next version, it'll be 12.80.7.1 and Kodi should auto-update to it when it hits our repo.

It usually takes a day or two from PR merge until addons are uploaded to our repos.

so long,

Hias

Quote from Nofan Tasi

Just curious: LibreELEC-Generic.x86_64-13.0-nightly size jumped from 300 to 500 megabytes

We added support for Nvidia cards (which were previously only supported via the Generic-legacy builds).

Generic: add support for Nvidia by HiassofT · Pull Request #11306 · LibreELEC/LibreELEC.tv

Runtime tested on Generic with a RTX4060

github.com

And, yes, the driver is unfortunately HUGE.

so long,

Hias

If you want to play around with the remote:

Simply "systemctl mask eventlircd" and disable the eventlircd udev rule by creating an empty .config/udev.rules.d/98-eventlircd.rules file - then reboot.

If you configure the "OK" button to send "enter" (via ir-keytable) the up/down/left/right buttons will work like cursor keys and "OK" like the enter key on a keyboard.

so long,

Hias

Keyboard handling is actually quite simple, both kodi and wayland use libinput plus libxkb for that so we just need to pass the keyboard layout that's configured in kodi on to wayland (via an environment variable) and you get the same keyboard layout in flatpak addons as in kodi.

What's missing in the wayland environment though is software to listen on volume keys and adjust audio volume. Usually that's handled by the (pulseaudio) volume/mixer applets in desktop environments, but there's no such thing (yet) in LE.

Kodi handles the volume keys on it's own which is why it works in kodi.

Remotes are quite a mess though. Currently we need to run remotes through eventlircd (and explicitly configure libinput not to handle them, too) as libxkb and kodi still doesn't support quite a lot of buttons found on remotes (especially the quite important "OK" button).

There's a kodi PR to improve that https://github.com/xbmc/xbmc/pull/27932 but it hasn't been merged and also still doesn't support all common remote buttons.

Realistically we won't get proper remote button support before the kodi 22 / LE13 release so we won't be able to drop that eventlircd workaround until some time during the LE14 dev cycle.

Well, someone could write a separate program that translates LIRC events back to input events and injects those via uinput but that's quite meh (and would also be another - hopefully - short lived workaround).

so long,

Hias

Thanks a lot for reporting back, glad to hear it works now!

I'll PR the fixes so the should be in our addon repo in the next few days.

With the "confirm start" option you can disable the "Start Chromium" etc dialogs that pop up before starting the flatpak addons.

Concerning volume control: that's usually handled by special (background) services of desktop environments, but LE doesn't include a full desktop environment so the buttons on your keyboard/remote won't have any effect.

so long,

Hias

Nofan Tasi can you please test with the attached tools.externalhelper addon?

I've fixed audio device handling and also added a setting to manually specify the audio device (the latter shouldn't be needed in your case).

Please drop the pactl load-module workaround from your autostart when testing that.

It'd also be interesting to know if this works with librespot installed.

so long,

Hias

Thanks again for the logs and tests!

There's a bug in the current audio device selection code, it misses the :CARD=PCH which is important in your case.

I'll have a look at fixing that and report back when I have an updated addon to test.

so long,

Hias

Nofan Tasi thanks, I think I know now what's going wrong.

Could you please stop kodi and then run aplay -L and post the output?

With kodi stopped also please confirm if this works fine:

pactl load-module module-alsa-sink device=sysdefault:CARD=PCH

so long,

Hias

Please test with the librespot addon disabled, reboot, then configure the audio device in system settings so you get GUI sound and then run Chromium flatpak.

The librespot addon has a long history of creating a mess with audio output so I wouldn't be surprised if it works now.

so long,

Hias