[debutanker]

Fixed my problem with MCE RC6 IR-Receiver - many thanks. 

@debutanker thanks a lot for your feedback!

If you have a few minutes it would be great if you could run a few more tests on build #0416 (with the non-functioning remote). The goal of the mceusb patch was to make remotes more snappy, maybe it optimized things too much, maybe that optimization doesn't work with your IR receiver, maybe there's something we missed - would be good to find that out.

On build #0416, with kodi running, run the following command and check if your remote starts working again:

Code:

ir-ctl -t 100000

Also test with "ir-ctl -t 125000"

If one of these settings brought remote functionality back it would be good to know if lower values also work. Test with 75000, 50000, 40000, 30000, 25000. You can try other values in between if you like, but if some of these settings work it would already be good to know about it.

so long,

Hias

As you guys always have more than only a few minutes for us, i will find of course some minutes for you!
Tested with several values and first value which works for me is "64000".

Edit: would be nice, if my mce receiver shows the same "snappy" behavior as my NUC receiver now does.

[HiassofT]

As you guys always have more than only a few minutes for us, i will find of course some minutes for you!
Tested with several values and first value which works for me is "64000".

Awesome, thanks a lot for the tests! So, if I understand you correctly, 64000 and higher values work, but values below 64000 break the remote?

It would be great if you could do two (hopefully last for now) tests on #0416: post the "ir-ctl -r" outputs of a buttonpress, once when using the working (64000) ir-ctl -t value, and once when using a non-working value (63000, 60000, whatever you noticed didn't work).

Edit: would be nice, if my mce receiver shows the same "snappy" behavior as my NUC receiver now does. 

Interesting. Which receiver are you using on the NUC (post the ir-keytable output)? The typically used ite-cir should give about the same performance as mceusb receivers - at least they both default to a 100ms timeout which is one of the factors regarding "snappiness". Are you also using the Harmony / RC6 remote there?

so long,

Hias

[atoulmin]

I’ve been running these builds for a while and they’ve been great.

However the asteroids screensaver has stopped working a while back. I’ve tried the builds provided here by millhouse and the generic librelelec. All I get is a black screen.

I’ll do a debug log however is it possible for a rebuild?

Thanks in advance

New build uploaded.

Thanks I’ll give it a go

[HiassofT]

@debutanker no need to run more tests, just got an email from Sean (the Linux kernel IR maintainer), he could reproduce the issue and posted a fix. I'll have a look at it and check if we can include the fix in the next build.

so long,

Hias

[Milhouse]

Edit: would be nice, if my mce receiver shows the same "snappy" behavior as my NUC receiver now does. 

Interesting. Which receiver are you using on the NUC (post the ir-keytable output)? The typically used ite-cir should give about the same performance as mceusb receivers - at least they both default to a 100ms timeout which is one of the factors regarding "snappiness". Are you also using the Harmony / RC6 remote there?

so long,

Hias

I created the following as /storage/.config/udev.rules.d/70-input-repeat.rules which reduces the repeat period to 50ms and makes my RC6/Harmony One with Skylake NUC much snappier, now almost as snappy as the very snappy Ortek VRC-1100 USB IR that I use on other devices:

text:
ACTION=="add", SUBSYSTEM=="input", KERNEL=="event[0-9]*", GOTO="start"

GOTO="end"

LABEL="start"



# don't change eventlircd device settings

ATTRS{name}=="eventlircd", GOTO="end"



# don't change settings of rc remotes

#SUBSYSTEMS=="rc", GOTO="end"



# set default repeat delay to 500ms like rc remotes

RUN+="/usr/bin/ir-keytable --delay=500 --period=50 --device=$devnode"



# make lircd-uinput use same repeat period like keyboards in kodi

ATTRS{name}=="lircd-uinput", \

  RUN+="/usr/bin/ir-keytable --period=80 --device=$devnode"



LABEL="end"

You can tune the settings interactively with ir-keytable --delay=500 --period=50 until you find the values you like, then set them in the udev.rule so that they are applied when the system starts.

[debutanker]

Here we go:
https://pastebin.com/ymiEskzy

Regarding my NUC, its only the integrated receiver controlled also by Harmony Hub.
Compared to my external MCE receiver, controlling is much more faster.

edit:

@debutanker no need to run more tests, just got an email from Sean (the Linux kernel IR maintainer), he could reproduce the issue and posted a fix. I'll have a look at it and check if we can include the fix in the next build.

so long,

Hias

Too late...

[atoulmin]

I’ve been running these builds for a while and they’ve been great.

However the asteroids screensaver has stopped working a while back. I’ve tried the builds provided here by millhouse and the generic librelelec. All I get is a black screen.

I’ll do a debug log however is it possible for a rebuild?

Thanks in advance

New build uploaded.

Didn’t work.

I will try a fresh install of libreelec.

[jeinnor]

Hi

I find when using profiles it is slow to log into one of the profiles, once the profile has loaded things run okay! Logging out of one profile and signing into another is quicker. Is there a reason for this?

[HiassofT]

Here we go:
Regarding my NUC, its only the integrated receiver controlled also by Harmony Hub.
Compared to my external MCE receiver, controlling is much more faster.

What do you mean with "faster"? Quicker response to button presses, quicker button repeat?

The goal of the IR latency patches we are currently testing is to reduce the time until the system "sees" that a button has been pressed or released.

The effect of that is most visible if you disable command repeat on your Harmony remote (so it sends out only a single IR message on a short press).

It takes about 50ms to transmit a rc-6 message plus the configured timeout from the IR receiver - about 25ms if the mceusb optimization works, about 100ms with the ite-cir receiver on the NUC (that's the minimum timeout this receiver supports) until the button press is recognized. So, roughly 75ms on receivers that support the optimization and about 150ms on the NUC.

If you configure the Harmony to use command repeats the system will "see" the button press after either the timeout or when the second IR message is received - whichever comes earlier. rc-6 sends repeats every ~110ms, so on optimized receivers nothing changes (button will be recognized after ~75ms), but on the NUC the button will now be seen about 110ms after the button press.

Without the optimization ite-cir used a default timeout of 200ms, meaning without command repeat it took about 250ms until the system "saw" the button, but with command repeat it was less than half the time.

So changing the command repeat feature of the harmony or pressing a button very quickly vs a tad longer of a normal "dumb" remote can have a rather large impact.

The ir-keytable settings milhouse mentioned take effect after the system detected a button press. They influence how long you have hold a button before repeat kicks in and once repeat started how fast the repeated button presses are sent out.

The overall speed of the system (CPU, storage) also is an important factor. A NUC with a Core i CPU and a SSD should have no problems reacting quickly to input (and keeping up with fast button repeats), but a low-end Atom or an RPi will quite certainly struggle as loading backdrops from disk (or a slow SD card) and getting them on screen etc are quite complex operations.

BTW: tonight's build will contain the mceusb fix, it would be great if you could test the build and report back if it works.

so long,

Hias

[kszabo]

My unprofessional bug report (generic x64, Intel KabyLake i3-7100):
- automatic adjust refresh rate does not work on v0407
I went back to a version from 03/2018 (0301) and it works again at once

[busta.rhymes]

I need help bad 

Hi guys, im trying to install libreelec on my new gemini lake NUC all day.
It just doesnt work. The installer wont Load and it always gets stuck at Waiting for Installer to Load.

The New Gemini Lake NUC does not support Legacy Boot and only supports UEFI Boot. It only has the UEFI Boot option default checked and it is greyd out and intel say no legacy is supported.
I hope that this is not causing the problem.

I asumed that the error might be the install stick but my other pc installs it just fine with it. And i also tried the standard libreelec version 8,25 and it also gets stuck in the Waiting for Intstaller to Load.
Any idea what it could be? I just cant get into the installer with the gemini lake nuc.

I just removed the ssd with no luck. Built it back in. I have no idea why i cant get further then the black screen.

Here is someone with the same problem with this nuc on the libre elec forum:
https://forum.libreelec.tv/thread/12018-...usb-or-sd/

[gromgsxr]

Are the intel hd audio patches still included? i just tried the 0417 version on my nuc6cayh and it only passes DD and DTS, even DD+ Eac3 was sketchy and only worked sporadically. and anything like TrueHD all i got was silence, and after trying to play those it killed the 2 channel pcm from the menu and i had no sound until i rebooted.

[Milhouse]

Are the intel hd audio patches still included? i just tried the 0417 version on my nuc6cayh and it only passes DD and DTS, even DD+ Eac3 was sketchy and only worked sporadically. and anything like TrueHD all i got was silence, and after trying to play those it killed the 2 channel pcm from the menu and i had no sound until i rebooted.

Yep

[Milhouse]

My unprofessional bug report (generic x64, Intel KabyLake i3-7100):
- automatic adjust refresh rate does not work on v0407
I went back to a version from 03/2018 (0301) and it works again at once

Did you read this post?

[Milhouse]

Hi

I find when using profiles it is slow to log into one of the profiles, once the profile has loaded things run okay! Logging out of one profile and signing into another is quicker. Is there a reason for this?

Maybe an add-on is causing the delay. Try uploading a debug log (wiki) after you have reproduced the issue (enable debug logging, reboot, reproduce problem, upload log). Maybe someone will have some ideas after seeing your log.