Posts by HiassofT

  • Remote control - what Addons or drivers do i need to get it working?

    The Flirc dongle acts like a keyboard, so there's nothing you need to configure on the LibreELEC side - leave Lirc disabled and ignore all the ir-keytable stuff on the LibreELEC infrared remote wiki page.

    If you added configurations, changes to autostart, disabled daemons etc please revert all of them or start fresh from scratch. Changes there are most likely to just break things.

    Configure the Flirc with the Kodi profile for your remote, using the Flirc configuration tool, and you should be done.

    so long,

    Hias

  • Custom remote config

    The Xbox 360 remote should work out of the box. If it doesn't work for you please be more specific about what's not working, following the troubleshooting steps in the wiki Infrared Remotes [LibreELEC.wiki]

    Do you get keycodes from ir-keytable -t? If not post the ir-keytable output of the non-working buttons.

    Do the keycodes show up in kodi's debug log and if yes which actions are executed? Post the log lines with the info about non-working or unmapped buttons.

    so long,

    Hias

  • Lightning Bolt icon in top right corner

    The CPU is quite busy during startup, kodi runs a bunch of housekeeping tasts like checking for new addons so it means it'll draw more power than when kodi is idle or playing a h264 movie. If you have a self-powered USB HDD connected it'll draw quite a bit of power during startup as well.

    Get a proper power supply and the lightning bolt will disappear.

    The lightning bolt is a warning sign, depending on how low the voltage drops the system may lock up and / or the sdcard may get corrupted.

    As I wrote before for the RPi2/3 the official 5.1V/2.5A supply is recommended.

    so long,

    Hias

  • IR receiver gets signals but they aren't passed any further

    If ir-keytable -p all -t didn't output anything then either eventlircd or kodi were running in the background or the remote uses an odd protocol that's not supported by in-kernel decoding.

    I haven't looked in detail at your lircd.conf file but it looks like it might indeed by the Panasonic protocol, which isn't supported (yet).

    So, just use your lircd.conf file, you only have to change the KEY_ names to match the official key names input-event-codes.h\linux\uapi\include - kernel/git/torvalds/linux.git - Linux kernel source tree

    In LibreELEC 8.2 you have to enable Lirc in LibreELEC Settings, in LE 9 and the current alpha versions lirc will be started automatically when a /storage/.config/lircd.conf file is present.

    Also read the info in the wiki Infrared Remotes [LibreELEC.wiki]

    so long,

    Hias

  • IR receiver gets signals but they aren't passed any further

    ir-ctl -r will show you the raw signals and you can use it as a simple check if something is received. If you have bad batteries, bad reception or interference you could still get "something", but that doesn't neccessarily mean it's a valid signal that can be decoded.

    By looking at the exact pulse/space durations it's possible though to see if it's garbage, a valid remote signal or some unsupported protocol.

    In case of MCE remotes the most likely cause is bad batteries, bad reception or interference - that protocol is well supported and also your IR receiver is know to work well.

    so long,

    Hias

  • Yatse - remote control Libreelec from different network

    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

  • Yatse - remote control Libreelec from different network

    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

  • Configuring IR Remote that is supplied with tt-4600 tuner

    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

  • Configuring IR Remote that is supplied with tt-4600 tuner

    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)

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

  • Configuring IR Remote that is supplied with tt-4600 tuner

    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

    Code
    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