Posts by kurai

To copy/paste Google AI search:-

"LibreELEC developers chose to prioritize a "mainline" Linux kernel, they intentionally discouraged or dropped deep development for Amlogic's proprietary hardware chips. The community created CoreELEC to keep the Amlogic platform alive and fully optimized.

Unlike other systems that try to support everything, CoreELEC only targets Amlogic system-on-chips (SoCs). This tight focus allows developers to use Amlogic's official vendor kernels and specific hardware patches."

In other words "LibreELEC didn't want to have to deal with and support Amlogic's weird proprietary shiznit"

I'm sure some LE people will jump in and correct me if I've substantially mis-represented the case

Umm... nice detailed report... but ...

You know CoreELEC and LibreELEC aren't the same thing ? ... Right ?

CoreELEC forked off from LibreELEC a good number of years ago (7-ish?) and had their own set of priorities they wanted to address.

As a consequence the underlying Linux base, and the hardware it specifically addresses and the way they do it have diverged quite a bit.

You might have more success addressing CoreELEC's community directly at https://discourse.coreelec.org/

That said - this is not a "Get out of here, your kind is not wanted!" post, but more a note that people here may not have the detailed knowledge of CoreELEC's quirks and issues that you may need.

My mind is refreshed on what the ancient problem was, now - for what it's worth

The Harmony mapping software (back when it was still an actively supported thing by Logitech) had issues with a different IR receiver I added after the old one died - the previous one was some Hauppage-alike thing that was fine as being talked to as "Generic PC IR" and JustWorked^[tm], but the new one had to be specifically defined as a Microsoft Media Center Extender (MCE) receiver.

The problem arose because Logitech's definition table of MCE controls didn't 100% match Microsoft's defintions, and the button fucntion remaps were only available as pre-defined options from a drop-down menu, rather than customisable.

So, as you say, I had to do an annoying chain of workarounds - in Harmony, map a broken definition to a working but unused one, that also had a matching linux input code, then shovel that into lircmap, then a final kodi remote.xml entry.

It was a bit of work to unpick all that old nonsense and translate it to the much saner new method, but worth it.

Should be much easier to change/maintain in future if I need to alter anything again.

Aaah, got it.

Thanks

Quote from HiassofT

Edit: kodi log shows it's tripping over the media and exit button/keycodes in your xmls.

Edit: Yeah - that's a long-standing thing likely stemming from some fiddling I did with Logitech Harmony mapping years ago.

I never did track down what the exact issue was between harmony/lirc/remote.xml - all I recall now is that is was non-obvious and would likely require some action from Logitech support, and considering they had shut down that product line ... never going to happen.

Long story short - it's a bit of log noise I have ignored for years because it doesn't affect anything I do.
Might as well give it another pass, since I am already re-doing the map - I can at least comment out the offending bits if I don't track down the issue once more

Hi Hias.

What's the new procedure for over-riding the /usr/share/kodi/ - special://xbmc/system/keymaps/*.xml  ?

In General Support/Nightly LE13: remote.xml not loaded, lomion asked :

Thread

Nightly LE13: remote.xml not loaded

After update to LE13 (LibreELEC-RPi4.aarch64-13.0-nightly-20260628-27a0c4c.img.gz) from LE12.2 keymaps/remote.xml (in masterprofile or profile) is not honored anymore.

The log shows "Loading special://masterprofile/keymaps/remote.xml" but the default keymap is used.

lomion

June 29, 2026 at 7:34 PM

The further conversation focused on sorting out his specific issue, but the initial question got left behind.

I have a number of entries such as :

<mute>RunScript(/storage/.config/BTconnect.py)</mute>
<record>ToggleWatched</record>

The Keymap Editor addon isn't useable for that, and a re-customised keyboard.xml or remote.xml files saved to special://profile/keymaps/ (/storage/.kodi/userdata) are still ignored.

https://paste.libreelec.tv/cottaged-sunni.log

Nightly Generic 2026-06-25 https://test.libreelec.tv/13.0/Generic/G…-b52cea4.img.gz seems to be truncated, and doesn't complete download.

(Size shown as 332.9M rather than the now usual ~513M)

The shell is an ash variant, provided by busybox.

Home dir is /storage so put your .profile in there.

Yup - saves me when I have intermittent problems with plugin.video.youtube

I can hop over to Flatpak'ed VacuumTube, then back to Kodi without having to mess around with the 'official' Youtube apps on Amazon Firestick (Oh... my ... god ... the UI's advert spam is so obnoxious) or the TV (Oh ... my ... god ... the UI is *painfully* slow. Oh - also obnoxious advert spam)

Quote from joe65

...

while at it

System Info

* Summary: it would be nice to see what kernel the box is runnning (delete the word "community" ?)

* Summary: running an NUC13 with 16T here. Displayed is only thread 0-11 !

It's a resolution/font size problem, with long text strings that don't wrap and therefore extend out of the viewport.

The data fields pulled for that window are an upstream Kodi thing, not something LibreELEC has customised.

It's one of those ancient "core" things that's been around in more or less the same form since Xbox XBMC days with very minor changes. It calls a fixed label ID which has fixed elements that are mapped to fixed references from strings.po and localisations. (You can't even easily do things like add a simple [CR] to make a new line to 'wrap' the overflow text onto.)

There are so many builds/forks/skins built on top of that fossilised foundation that would break horribly if changes to that stuff were not managed exceedingly carefully (one reason that pull request you referenced will probably not get anywhere any time soon)

Given all that ... It would be far, *far*, FAR easier to modify your skin (or UI resolution) so that the long string doesn't go outside the bounds of the display window.

If you want to tinker with the skin method, play with values in:

SettingsSystemInfo.xml

_{^{(Exemplar values from default Estuary skin)}}

    <control type="label" id="x">
        <width>1400</width>
        <font>Mono26</font>

and

     <control type="label">
					<description>CPU Text</description>
					<width>auto</width>
					<height>40</height>
					<label>$LOCALIZE[13271] $INFO[System.CPUUsage]</label>
					<aligny>center</aligny>
					<font>font12</font>

Very nice and tidy.
I considered the NUC platform for my HTPC, with a nice case ... but leaned into Jank-mode instead

I fixed a bare Odroid H4 to the VESA mount on the rear of my TV. It has a 90mm Noctua fan zip-tied to the heatsink, but tbh it's barely needed - rarely even spins up and is inaudible even with my ear right next to it.

The main reason for going this route was the more modern codec h/w support of the Alder Lake based N300, specifically AV1.

LAN is the onboard 2.5gb ethernet, Bluetooth is a USB dongle, IR from an ancient USB MCE compatible thing. DDR5 memory & NVME storage.

If you ever find the NUC's, now very out of date, i7-8559U being a problem I heartily recommend the Odroid x86 boards - they are so tiny I'm sure you'd have no problem getting one to work in your nice case setup.

Nofan Tasi

As I went to test, it occured to me that this probably wouldn't work, for reasons that HiassofT went into earlier.

There isn't any real audio handler "plumbing" present in the bare Flatpak Wayland instance, unlike a full desktop environment. The system just dumps the raw audio output into whatever named device pre-existed in LibreELEC before it was closed and the Flatpak session spins up.

This proved correct - I could see the KEY_VOLUMEUP & KEY_VOLUMEDOWN events being received via ir-keytable -t but Flatpak/Wayland didn't have a mechanism to do anything with them.

Same for the Bluetooth thing.

Nofan Tasi

As mentioned earlier, I have my remote configured to have the volume up/down buttons sending to my A/V Receiver/Amplifier, which handles the audio of all my HDMI devices, instead of dealing with it directly in LibreELEC/Kodi.

However, it's easy enough to reconfigure and test with "native" Kodi audio controls. I'll try it tomorrow and let you know how it goes

I also have a Bluetooth mini-keyboard/trackpad thing with media control buttons. I'll see how that works too.

Quote from HiassofT

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.

Yeah...

The workarounds you mentioned (masking eventlircd and creating the udev rule entry) do indeed function, and with Logitech Harmony software I can leave standard "KEY_OK" on short-press of button and set "KEY_ENTER" on long-press, which works for the Wayland Flatpak applications as required.

But the reboot step is the killer - can't automate setting/unsetting the conditions with scripting without a lot more coding-fu than I possess.

Guess I'll just have to wait and see what happens during the LE14 cycle.

Well, as luck would have it, the volume thing is not an issue for me as I let the AV-receiver box handle that aspect of things

As far as the remote goes, I may also be in luck. I'm using the Logitech Harmony system (fingers crossed it stays alive) and I have the facility to have the remote send any arbitrary key-command(s) for a given button.

Thanks for the pointers of what to look at - I'll report back when I've had a chance to poke around in more detail.

Quote from HiassofT

...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.

Ah - that kinda-sorta has a bearing on a question I had.

Ideally I'd like to use the same IR-remote I use in main LibreELEC/Kodi via lirc & keymaps, but haven't had a chance yet to poke around seriously.

VaccuumTube's in-app settings dialogue says it uses up/down arrows to navigate, but it doesn't seem to recognise them on the bluetooth keyboard or IR-remote I'm using.

I was going to ask how keyboard/mouse/remote handling & configuration worked in the Flatpak environment, but if there isn't any plumbing for it, because of lack of a "proper" desktop environment ... ??

Most excellent - cheers

HiassofT, CvH

Hi Hias, CvH.

I see the newer Flatpak addons being merged into LibreELEC:master tree but they aren't yet available from the addon repo (current version 12.80.7).

Is it just a matter of me being patient till there's a repo update built & published ?

Quote from chewitt

... THERE IS NO SUCH THING AS KIOSK MODE. Feel free to prove me wrong with a screenshot from the Kodi GUI - anywhere it says Kiosk.

Some skins have their own notion of "kiosk mode" and have toggles for it in their particular settings menus.
(Transparency being one I can see, as I still have it installed)

That might be where the confusion comes from i.e. It's language in some 3rd party skins but *NOT* a core Kodi thing.