Posts by HiassofT

    First check if kodi picked up both event devices - be careful, the numbers (event4/event5) might change across reboots, so verify via evtest or /proc/bus/input/devices that the numbers are correct. Run the following command and post the output

    Code
    lsof | grep /dev/input

    The output should look similar to this:

    Code
    749     /usr/lib/kodi/kodi.bin  /dev/input/event0
    749     /usr/lib/kodi/kodi.bin  /dev/input/event1
    749     /usr/lib/kodi/kodi.bin  /dev/input/event2
    749     /usr/lib/kodi/kodi.bin  /dev/input/event3

    You should see /usr/lib/kodi/kodi.bin both in the event4 and event5 lines

    Then we need some more info about both input devices. Run the following commands and post the output as well. This will tell us if the devices were classified as keyboard, mouse, joystick etc

    Code
    udevadm info /dev/input/event4
    udevadm info /dev/input/event5

    If kodi had picked up the /dev/input/event5 device (where you got HOMEPAGE, VOLUME, PLAYPAUSE) enable debug logging in kodi, then reboot, then press the HOME and PLAY buttons, then ssh in and post the kodi log file. This will tell us if kodi received the input and if yes if and how it processed it

    Code
    paste .kodi/temp/kodi.log

    so long,

    Hias

    When testing things make sure you have stopped kodi and eventlircd so no process is grabbing (taking away the events) from you. evtest will warn you if you try to access an input device which is grabbed, so it should be pretty obvious if that happens.

    evtest should then show all events that come from the input devices.

    The IR thing is not quite clear to me, did you see an IR receiver device when running "ir-keytable"? It's a bit unlikely that the USB receiver would expose both HID plus IR devices but you never know.

    so long,

    Hias

    Thanks a lot for sharing your lirc file!

    One problem with manual recording (both raw and standard mode) is that the measured values will never be 100% correct. The remote, IR receiver, SOC and OS all play a role in which values you get.

    If everything were perfect you'd see about 2-5 different lengths, because that's what the remote should be transmitting.

    So there's always some risk that some values are a bit on the edge and thus a lircd.conf file won't work on some other hardware or with another remote.

    That's why lirc now recommends using the profile mode where you manually select the remote's protocol (in-kernel decoding uses basically the same approach). But this won't help with non-standard protocols like the Xbox, the best one could do is to try to find some specs what the lengths should be and then manually clean up the file according to that (eg replace everything between 200 and 300 with 250 if that's what the nominal length would be).

    But then, often it works good enough as is so it's not really necessary.

    As for the KEY_ names: looking at the remote="devinput" section of Kodi's Lircmap.xml is a good approach. If in doubt look at what the Microsoft MCE remote is using (see /usr/lib/udev/rc_keymaps/rc6_mce), these KEY names are pretty much the standard when it comes to Kodi and IR remotes..

    so long,

    Hias

    Thank you HiassofT for all the detailed instructions. I have a remote with usb dongle. I followed your guide. What if some buttons dont register under evtest? For example I hit the Home button and it shows nothing, no event in evtest.

    What kind of remote and receiver is this? If it's an IR remote and the receiver shows up in "ir-keytable" you have to follow the guide in the wiki Infrared Remotes [LibreELEC.wiki]

    The remotes discussed in this thread are of a different type, they can be IR but also RF, the important difference is that the receiver shows up as a normal HID device, like a USB keyboard.

    Some of these receivers show up as 2 input devices, often one for the "keyboard"/"buton" part and one for "mouse". If that's the case also try the other one with evtest.

    For example the rather popular Ortek/Gmyle/Hama/... VRC-1100 exposes the volume buttons via the "mouse" input device. No one knows why the manufacturer choose to do this, but it's the way it is.

    Manufacturers might also have chosen to make some buttons only available in special modes - eg there might be a "mouse mode" button or sth like this on the remote which if pressed automagically enable some buttons - and maybe disable some other ones.

    Yes, it's weird, but thats how some manufacturers want their remotes to operate. As this is happening inside the remote and/or inside the receiver there's not much you can do about it.

    so long,

    Hias

    I have noticed this thread but I'm not familiar at all with the old amlogic / remote.conf thingy - so I can't help here.

    With LE9.0 Amlogic will finally switch to the standard ("ir-keytable") configuration so we just have a single method on all platforms.

    so long,

    Hias

    Hmmm "HID device except mice, keyboards, and joysticks" doesn't look like we'd get standard input (KEY) events from it.

    You could try installing the system tools addon, then ssh in, stop kodi and eventlircd (just to be sure) and check if you get something from evtest (if your device is listed, select it, then press a button on the remote and see if you get some output).

    Code
    systemctl stop kodi
    systemctl stop eventlircd
    evtest

    If this doesn't work it's probably easiest to just by a mceusb receiver (like the eg HP MCE USB receivers you find on ebay etc) these are usually very well supported.

    LibreELEC doesn't ship with any build tools, you have to cross compile it - see the wiki for details Compile [LibreELEC.wiki]

    Then you could create an (addon) package for the irmplircd daemon.

    As a quick hack you could also compile a statically linked binary on your Linux PC, copy that over and use that.

    That being said, implircd doesn't fit too well into the way LibreELEC uses remotes - LE expects to get linux input events, not a lirc socket. Therefore lircd is also used together with lircd-uinput. You'd probably have to do the same (run a lircd-uinput instance translating the output of implircd to linux input events).

    so long,

    Hias

    Never heard of irmplircd, but it looks like it's doing similar things like eventlircd (translating linux input events to lirc events) which is included in LibreELEC.

    What's happens if you don't run irmplircd, can you eg navigate with the arrow buttons in kodi?

    You can also try to change the eventlircd configuration so that it's picking up your IR receiver.

    First copy the eventlircd udev file to /storage/config/udev.rules.d/

    Code
    cp /usr/lib/udev/rules.d/98-eventlircd.rules /storage/.config/udev.rules.d/

    Then add a block with the usb vendor and product IDs of your IR receiver in the USB section of that rule file. sth like this

    Code
    ENV{ID_VENDOR_ID}=="XXXX", ENV{ID_MODEL_ID}=="YYYY", \
    ENV{eventlircd_enable}="true"

    After a reboot eventlircd should pick up your IR receiver and kodi should receive them as Lirc events (enable debug logging in kodi and check the kodi log).

    so long,

    Hias

    The log lines you quoted are fine, this is when the audio device is opened for GUI sounds and you'll get the same messages for almost every device (float is rarely supported, usually only 16/24/32 bit).

    The relevant lines are a bit down in the log.

    These lines indicate DTS was detected and passthrough using 2-channel S16LE was properly activated:

    A bit further down, when you switched to the AC3 stream, it looks fine as well:

    It's rather puzzling, currently I have only 2 more ideas:

    Maybe your receiver got "confused" because you played a DTS track before? Have you tried playing a audio or video file with just an AC3 track?

    The allo digione driver doesn't handle the IEC/AES bits which, amongst other things, set the SPDIF channel status bits to indicate if it's a PCM audio or a compressed data stream. But then, IIRC, this channel status bit is mainly relevant to ancient DACs that only support PCM audio so they can mute the output if one (accidentally) tries to feed them AC3/DTS/... Modern stereo DACs and receivers that support AC3/... just look at the data stream as compressed data can be identified by unique headers in the stream. So it's puzzling why your receiver would detect a DTS stream flagged as audio in the status bits but not an AC3 stream.

    It could well be that I'm missing something, so maybe someone else can chime in with more things to check.

    so long,

    Hias

    Thanks for the status update and fingers crossed things work out with the TSOP34138. Please keep us posted about the progress, I'd be interested in knowing if you can get the old Xbox remote to work.

    Concerning lirc_xbox: it can still work be made to work with kernel 4.14 but in LibreELEC we ship (optional in LE9) newer DVB drivers which also update the code for IR remotes to very bleeding edge kernel level - and lirc_xbox does no longer work with that.

    Therefore we made the decision to drop lirc_xbox completely in LE9. It would have been rather confusing to users to have lirc_xbox support in the base installation but not when you enable one of the optional DVB drivers.

    so long,

    Hias

    The log looks OK to me.

    Which AVR receiver are you using? Does it have some buttons to select the mode or configuration you could change?

    It looks to me like the AC3 stream is sent correctly but for some reason your receiver doesn't detect it as AC3 and instead tries to output the compressed data as 2 channel PCM - which usually results in "terrible noise".

    so long,

    Hias

    I must activate debug logging, start the playing, stop it and upload the log, right?

    Yes, please enable debug logging, reboot, then play a file, then upload the log.

    It's important to have debug information of kodi startup as well, therefore the need to reboot.

    so long,

    Hias

    Which IR receiver (exact part number) are you using?

    There's nothing you can do in software to influence pulse/space detection, this is performed inside the IR receiver.

    Basically there are 2 key parameters for choosing an IR receiver, one is the carrier frequency of the IR signal (usually 36-40kHz), the other is the remote protocol a receiver has been optimized for and/or how well it can deal with external IR interference (eg sun shining directly on the receiver, nearby CCFL lamps etc).

    Usually using a 38kHz (which is used eg for NEC proto)l receiver will work fine, 36kHz (used eg for rc-5 and rc-6) and 40kHz (eg sony) are near enough to work fine.

    As for protocol optimization have a look at the last page of this document on the Vishay website: dataform.pdf - more detailled info are in the specific datasheets of the receivers.

    AGC1 is the most universal AGC implementation, AGC4 (which is optimized for eg NEC and RC5/6) doesn't work well with a bunch of protocols.

    So, my recommendation would be to try a TSOP34138 (1 is the AGC version, 38 the frequency). TSOP34438 (AGC4) could be problematic.

    Some IR protocols have a rather large pulse/space at the beginning (eg NEC starts with a ~9000 pulse and ~4500 space) and you'll also see a large space (or a timeout) between button repeats. But the other pulse/space values within an IR message are usually in the 400-2000 range.

    I searched a bit and the original Xbox remote indeed seems to use a non-standard protocol. So in-kernel decoding won't work, but you could be able to create a lircd.conf with irrecord (you might have to use irrecord raw mode if normal mode doesn't work) - but first you have to sort out the IR reception (pulse/space) issues.

    As for the old lirc_xbox driver: well, that never made it into the official Linux kernel, OpenELEC/LibreELEC included it as long as possible (it needed a bit of tweaking now and then, but not too dramatic), but it's time had ended and we had to drop it. All IR receiver drivers in the kernel got moved to a new code base (which allows IR decoding in the kernel) and the old code lirc_xbox was built around got dropped.

    so long,

    Hias

    The mode 2 output looks very odd - the space values are oddly large. So I'm not 100% sure if there might be some problem with IR reception - or maybe the batteries of the remote are flat and it's not working properly?

    I'm not familiar with the original xbox remote, but if ir-keytable configuration doesn't work you could try the lircd.conf files from here: lirc-remotes / Code / [395780] /remotes/microsoft

    This one looks like it could work: xbox.lircd.conf?format=raw

    Download the file and copy it to /storage/.config/lircd.conf, then reboot (LE9.0 preview builds will automatically pick the file up and run lirc, in LE 8.2 you have to enable Lirc in LE settings).

    But before doing that I'd check into the mode2 output, the pulse/space values should usually be about 400-2000.

    so long,

    Hias

    Please upload a kodi debug log. Without logs it's hard to tell what's happening - it could be anything (some addon, some custom configuration you made, a faulty SD card etc).

    Testing with a fresh installation on a known good SD card without any addons installed would be a good idea.

    Also: when the RPi locks up can you still ssh in?

    so long,

    Hias