Posts by HiassofT

Short update:

Kernel 5.10.1 update and a first version to fix seeking with H264 (and MPEG2/4 on RPi2/3) hardware decoding were merged into master yesterday and are now in nightly builds.

CEC on RPi2/3 should work again and H264 hardware decoding is now enabled by default on RPi4.

H264 seeking isn't perfect yet, sometimes it jumps to the beginning of the file (this is being investigated). You may also notice a bunch of ERROR lines in kodi log when seeking, these were (temporarily) added to make debugging seek issues easier - just ignore these if seeking works fine for you.

Video occasionally cutting out on RPi2/3 is still an issue, this is also being looked into.

so long,

Hias

The easiest thing would be to connect the tuner via an externally powered USB hub.

I can't comment on your specific tuner, would guess though that when using the official power supply it should work fine, if it's the only thing you connected to the USB ports (RPis have limit on overall power draw on USB ports).

From my personal experience with a Xbox USB tuner I can say it works fine, but if I also connect a bus-powered HDD it fails miserably - total USB power consumption is too large and that makes the tuner completely drop off the USB bus (USB disconnect messages in dmesg).

so long,

Hias

Quote from harry_fine

At this point I'm ready to buy another tuner that's known to work on the PI4 with Libreelec. Are there any tuners out there, single is fine if need be, that absolutely work out of the box with the current version on the Pi4?

If single tuner DVB-T/T2 is fine then have a look at the RPi TV Hat Buy a Raspberry Pi TV HAT – Raspberry Pi

so long,

Hias

See Post #3 in this thread. This feature is included in our latest nightly builds here Index of /, , please use these instead.

so long,

Hias

The changes will be added to master branch (and in nightly builds) when they are ready.

so long,

Hias

On LG TVs the setting to disable overscan is called "Just Scan", it has to be set to "on". On my 55C8 it's in Settings->Picture->Aspect Ratio Settings.

so long,

Hias

I had described the IR and kodi remote processing in the wiki, but it seems this has now been removed with the switch to the new wiki...

Here's the archive of the old wiki page Infrared Remotes [LibreELEC.wiki] , the introduction should contain the info you need - also read through the linked kodi wiki pages for more detais.

so long,

Hias

No, although the device has "LIRC" in it's name it has nothing to do with lirc or the other infrared remotes - it presents itself to the system as a keyboard.

Enable debug logging in kodi, push the button and then post the kodi debug log - this will show which key kodi received and give more hints.

so long,

Hias

I don't have a Harmony remote but AFAIK the selected remote profile is what defines the scancodes to be sent - so dig into that.

My guess is the remote profile sends two different scancodes on left/right to support two (slightly) different DVD players - which might work with the original players but is highly non-standard with anything else.

Check if there are other similar remote profiles if you want to stick to the Pioneer DVD profile or just configure the Harmony to use the Microsoft Media Center remote (not the MCE keyboard!), this will work out-of-the box in LE.

If you plan to use both your original pioneer remote and the Harmony to control LibreELEC you can still do this when the Harmony is configured as MCE: Enable both nec and rc-6 protocols in the keymap and add the key/scancode definitions from rc6_mce to your keymap (we do a similar thing in the default libreelec_multi keymap to support Xbox remotes in addition to MCE).

so long,

Hias

The output of "play" looks fine (as expected when the Harmony repeats the command 3 times): It sends the scancode 0xab22 three times, which then results in a single key_down event.

The "left" test is odd though, the Harmony transmits two different scancodes, first 0xab2c and then 0xaf63, and repeats that three times. This doesn't end well, when a different scancode is received it's interpreted as a release ("up") of the previous scancode.

That's something you need to fix in the Harmony configuration - make sure a button sends a single scancode.

so long,

Hias

Copying dt-blob.bin from LE9.2 to the FAT partition might be enough to get an RPi2 image booting. Recently a user used that to successfully boot RpiOS (ex Raspbian) on a Slice with CM3

Trying (and failing) to resurrect my Five Ninjas Slice with CM3 - Kernel Panic - Raspberry Pi Forums

As I don't have a Slice I haven't tested that myself so can't be 100% sure if that'll also work with current or future LE 10 images, but I'm quite confident and you should have a starting point.

so long,

Hias

Can you post the output of "ir-keytable -t" when you do a short button press on the remote?

Usually remotes send the scancodes every (approx) 100ms while the button is pressed, this is interpreted as a "held down" button by the input subsystem - you'll see an initial "key down" event and then get further key down events after the specified repeat delay.

If the scancodes are too far apart linux will detect them as separate button presses (i.e. key down followed by key up some 150ms afterwards).

If the scancodes are only a bit too far apart then tweaking the receive timeout (ir-ctl -t VALUE_IN_MICROSECONDS, eg ir-ctl -t 125000) can help to detect these as a held down button - ideally the Harmony remote should behave like standard remotes though and follow the protocol specs though.

so long,

Hias

You could try increasing the delay before repeat kicks in - use eg ir-keytable -D 750 to increase it from 500 to 750ms.

This will work while kodi/eventlircd are running so you can experiment with the values.

so long,

Hias

It's your Harmony remote sending those repeats, simply disable the command repeat feature in the Harmony config software and you'll be fine

Fixing Repeats

so long,

Hias

Seeking with H264 HW decoding is currently being worked on, yesterday we had a first working test version (but it's not finished/final).

I can't give an ETA when we'll do a first alpha release - RPi4 builds are already looking quite good but there are also other things that need to be fixed/ironed out before we start wider testing.

so long,

Hias

Not really. There is/was a kodi PR to add longpress support for remotes WIP - [remote] Allow longpress mod for remote keymaps by phunkyfish · Pull Request #16740 · xbmc/xbmc · GitHub but it's in a rather dormant state.

So the only way to get this is disabling eventlircd and remapping buttons via hwdb/ir-keytable so X11/kodi can deal with them.

so long,

Hias

More likely X11 doesn't cope with most button/keycodes, so you'd have to remap quite a lot of buttons/keys via hwdb or ir-keytable. Maybe some tweaking of x11 keymaps might also work (haven't tried that yet).

I don't have LE on x86 here but I just checked on my Debian x86 PC and the numeric buttons on the MCE remote don't work OOTB either (they send KEY_NUMERIC_0... instead of the typical KEY_0).

so long,

Hias

This is tricky. The only way to get proper MCE keyboard handling or longpress support for remotes is to disable eventlircd processing (for MCE keyboard you also have to enable the mce_kbd protocol via ir-keytable/rc_keymaps).

You can do that by creating an empty udev rule file (remove it to restore normal behaviour)

: > /storage/.config/udev.rules.d/98-eventlircd.rules

The drawback is that then several buttons, most importantly the OK button, no longer work - kodi doesn't support OK etc keys on a keyboard. You can fix that by doing key remapping via a hwdb.d file, search the forum for examples if you're feeling brave.

so long,

Hias