Stupid question: have you tried new batteries in your remote?
If that doesn't help please post your journal journalctl -a | paste and the full output of ir-ctl -r from a short button press.
so long,
Hias
Stupid question: have you tried new batteries in your remote?
If that doesn't help please post your journal journalctl -a | paste and the full output of ir-ctl -r from a short button press.
so long,
Hias
Another big plus of the TV uHAT is that it works with the stock Linux kernels out of the box - no need to mess around with the out-of-tree DVB drivers.
so long,
Hias
Can you please check it this also happens on the latest alpha release (currently 8.90.006)?
I've been testing quite a lot with the HP branded MCE USB receiver (also USB VID/PID 1934:5168) plus 2 HP branded MCE remotes and they worked out of the box.
so long,
Hias
I'd strongly advise against opening anything to the internet - this'll end in a security nightmare.
If you really want to access Kodi/LibreELEC from the internet then install a VPN on your cable/LAN router and connect to that via your mobile devices when you want to access Kodi/LE.
Or just add a wireless access point to your LAN so you can connect your mobile devices via that - then you don't have to worry about random port scanners and script kiddies taking over your kodi installation.
so long,
Hias
Yes, this works fine if you add the necessary port forwards. Be careful though, I wouldn't open them to the internet, otherwise you could have some "fun".
I have 4 separate local networks here, RPi with LibreELEC got it's own net as all the phones / tablets (I moved them into the separated guest WLAN).
I enabled port forwards for tcp 8080, tcp 9090 and udp 9777 and both Yatse (on android) and Kore (on android and ipad) work fine with that.
so long,
Hias
Sorry for using too technical terms, the simple version is: the remote is queried only 4 times a second on your DVB dongle and that results in it being sluggish (there's probably not much we can do about that) and the repeat issues (that's a problem with all current kernels and I'll look into finding a solution - could be a bit tricky and may take some time).
As for remotes: I'd recommend using an official (or fully compatible like the HP branded ones) MCE remote together with the HP branded USB MCE IR receiver from ebay for about 15-20 EUR shipped. Official MCE remotes are the ones best supported in Linux and LibreELEC and the HP USB IR receiver works very well too and can be used with all kinds of other remotes as well - I have these here and regularly test with them.
Be careful when searching for MCE remotes on ebay or other shopping sites, there are a lot remotes advertised as "MCE" that don't follow the rc-6 MCE protocol. Same thing applies for "MCE USB IR receivers", some of them, like the cheap TopSeed receivers that are often advertised on ebay, have nasty bugs - better stay away from them and go for the known-good HP branded one.
Another cheap and very versatile option on RPi is to connect a TSOP 34138 IR receiver to the GPIO pins. For about 1-2 EUR/USD you'll have a full-fledged IR receiver that's very well supported in Linux/LibreELEC. This is what I'm using on my main RPi. The only gotcha is that some USB DVB dongles seem to interfere with it (low-level timing issues caused by the RPi's USB driver) - I haven't experienced such issues myself and also don't know if you'd be affected by that or not.
so long,
Hias
Thanks a lot for testing!
I added this kernel patch to set the timeout to the poll interval - basically the same thing that ir-ctl -t would have done (sorry, forgot that the timeout can't be configured on all devices)
--- a/drivers/media/usb/dvb-usb/dvb-usb-remote.c
+++ b/drivers/media/usb/dvb-usb/dvb-usb-remote.c
@@ -285,6 +285,7 @@ static int rc_core_dvb_usb_remote_init(struct dvb_usb_device *d)
dev->dev.parent = &d->udev->dev;
dev->priv = d;
dev->scancode_mask = d->props.rc.core.scancode_mask;
+ dev->timeout = MS_TO_NS(d->props.rc.core.rc_interval);
err = rc_register_device(dev);
if (err < 0) {
Here's the LibreELEC tree I built from: GitHub - HiassofT/LibreELEC.tv at le9-dvb-usb-ir-repeat
This patch was just a quick test to see if it helps on your receiver, in it's current state it will break IR remotes on dvb-usb remotes with long query interval (there are some that query every 400ms or even only once per second).
I'll have a look at that and should hopefully come up with a proper patch that I can also send upstream. BTW: the sluggishness comes from the 250ms query interval, you'll get a lot better performance from a standard MCE USB receiver or a GPIO receiver on an RPi. Quite a lot of dvb-usb dongles seem to use a 50ms remote query interval, with these the remote should be quite snappy and not suffer from the repeat issues you had, even on stock kernels.
I can't comment on the tuner crashes, this isn't my area, maybe CvH can help there.
so long,
Hias
Thanks for the info!
Can you check if this build fixes the IR repeat issues?
libreelec-rpi2.arm-9.0-devel-20181020140428-bd467bb.tar
so long,
Hias
Can you please post a link to your full dmesg dmesg | paste and the output of ir-keytable? If you are using the crazycat drivers can you please also test if you get the same issue with crazycat disabled and the standard kernel drivers?
so long,
Hias
Hmmm, the remote doesn't seem to follow the rc5 protocol too well - or there's some bug in the IR receiver driver of your card that then causes rc-5 decoding in the kernel to fail.
On quickly repeated button presses you should see the toggle bit flipping instead of getting different scancodes for the same button. eg
799.923295: lirc protocol(rc5): scancode = 0x1015 toggle=1
800.183294: lirc protocol(rc5): scancode = 0x1015
But that's no big deal, you can work around it with 2 scancodes for the same button in your keytable - like you already did.
The more problematic thing is that the signals seem to arrive at about 250ms interval instead of 110ms which is the standard for the rc-5 protocol. Therefore the kernel will interpret the scancode as distinct button presses and the normal repeat handling won't work.
You should be able to work around this by increasing the IR receive timeout with eg ir-ctl -t 200000 - you can play a bit with the value, 150000 should probably work as well and give a bit better response or you can go up a bit, eg to 250000. Just test what works best for you.
so long,
Hias
Can you post the ir-keytable -t output of a ~1second button press?
so long,
Hias
Thanks for the logs!
It's quite certainly a race between kodi and eventlircd and we are already working on it - see also this thread: Remote control troubleshooting
so long,
Hias
Thanks a lot for the info!
This seems to be a race between kodi and eventlircd grabbing the input device and if you're unlucky (and kodi "wins the race") the OK button won't work. So far this hasn't shown up during testing.
We'll have a look how we can best solve this issue and hope we have a fix soon.
so long,
Hias
Thanks for the info! Can you please post the output of lsof | grep /dev/input? dmesg would be helpful as well and we'll need to know which system (RPi, x86, ...) you are using.
Please test if restarting kodi and eventlircd, using the commands shown in this post LibreELEC 8.90.006 RPi Sony PS3 BT Remote limmited functionality. helps you get a working OK button.
so long,
Hias
What kind of IR receiver are you using, did your remote come with it's own USB dongle?
Please post the output of dmesg | paste
so long,
Hias
Could you please tell us which systems your are running LibreELEC on and post kodi debug logs where you pressed buttons that aren't working?
Please don't restart kodi / eventlircd, just enable debug logging in Kodi, reboot LibreELEC, then press buttons and if they aren't working grab the logfile and upload it
Provide Log File [LibreELEC.wiki]
so long,
Hias
Can you post the output of tvservice -m DMT and tvservice -m CEA?
Maybe your projector has a broken EDID, those commands should give some hints about that.
so long,
Hias