#8 Roku remote configuration

[Joel Ebel]

Attached is the complete set of roku codes that I have found. I added comments about the incompatibilities between LIRC and the protocol used. I used namespace codes for the normal buttons, but I wasn't sure how I could map the direct channel buttons to anything in the namespace, so they are just names. I'm happy to see this included in the LIRC remote database if others would find it useful.

[Alec Leamas]

Just some feedback: not that I'm doing this myself, but rumour is that there are some patches under way. With some luck it should make to 0.9.2 I think we should wait for these patches before merging the config.

Thanks again for reporting!

[Christoph Bartelmus]

Current git version should fully support the protocol with the updated config file.

[Joel Ebel]

Awesome! I look forward to trying it out. It looks like there's an extra commented out line after KEY_BACK.

[Alec Leamas]

For the record: Fixed in [8692c9].

[Alec Leamas]

Quick remark: could you add some lines to the lircd.conf manpage to keep it in sync?

[Alec Leamas]

@joel: It would be really nice if this patch could make it into the release. Since branching is due, it would be great with some basic feedback if the patch "works" in a basic sense.

[Joel Ebel]

I can probably test this Wednesday evening, if that's not too late.

[Alec Leamas]

Wednesday is fine, this is worth delying the branching a day or two. Thanks for replying, makes things sooo much easier.

[Joel Ebel]

So after some issues* getting lirc up and running, I can confirm that this behaves as expected on transmit. The number of times it repeats is a little unexpected, but that may be a more general problem. If I run irsend without -#, with -# 0, or -# 1, I get a single code sent. If I use -# n, where n is >= 2, I get the code, and then n repeat codes with the repeat_mask applied. So there's no way to get a single code followed by a single repeat code.

I wasn't able to get irw reporting any received commands for any remotes, and mode2 just gave me a segfault, so I didn't get very far with the receive testing.

• I attempted to install first on an older slackware 13.1 box, and I couldn't get it to compile, getting 'irsend.c:36: error: redifinition of typedef '__u32' Presumably there's some missing dependency on the slackware box? It built 0.9.0, but now I tried 0.9.1a and it would configure due to lack of help2man. I guess this box is too old. I did use 0.9.0's mode2 to analyze what came out of the master branch.
• Under Ubuntu 14.04 running on an old thinkpad T43, It compiled and installed, but as mentioned, I got segfaults on running mode2, and irw never reported receiving anything. I tried playing with lirc-setup, and got an AttributeError: 'module' object has no attribute 'SelectSelector'. I tried lirc-config-tool, and it told me "Cannot find irrecord command", despite irrecord being installed.

I suspect most or all of this would be resolved by proper packaging that got everything in the right place. I just felt like I should report what I found.

[Alec Leamas]

hm...

• segfaults: runtime linker using the wrong libs? Did you look into
  CONTRIBUTE.md how to run things straight off the build tree?
• The 'redefinition of typedef' is actually a plain bug. I'll file a new issue on
  this. Good catch!
• Could you possibly send the stacktrace from the lirc-setup crash?

[Alec Leamas]

Filed a ticket about the redefinition problem in [tickets:#65], fixed.

Filed a ticket about lirc-config-tool start failure inn [tickets:#64], fixed

[Joel Ebel]

I hadn't read the CONTRIBUTE.md file, but I installed lirc into /usr/local for testing. I'll try running it straight out of the build dir as well.

Attached is the stack trace from lirc-setup.

[Alec Leamas]

What?! To me, this looks like python bombs when trying to import the subprocess module. Since this is a system module, this is weird.

Just to check my assumption, can you make the following session in a terminal:

$ python3
Python 3.3.2 (default, Jun 30 2014, 17:20:03) 
[GCC 4.8.3 20140624 (Red Hat 4.8.3-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>>

and show what it says?

[Joel Ebel]

Agreed that it's weird. I can import it fine, ran dir(subprocess) help(subprocess) and subprocess.call(["ls"]) all with expected output. I can even dir and help on subprocess.selectors.SelectSelector.

[Alec Leamas]

hm... the only thing I can think of is that something shadows subprocess (and/or _subprocess) causing this.

Note the shebang: "#! /usr/bin/env python3". Does this invoke a different python3 on your host? Can you reproduce the error using '/usr/bin/env python3'?

[Joel Ebel]

It still works as expected importing by hand invoked with env python3.

[Joel Ebel]

I see what's going on. There's a selectors.py inside /usr/local/lib/python3.4/site-packages/lirc. If I'm in that directory, or that directory is in the path, when I import subprocess, that selectors is being imported when the subprocess module imports "selectors". It's sadly not the selectors that subprocess is looking for.

[Alec Leamas]

OK, let's put that asides for now, being a problem in your python setup. Sadly, it stops you from running lirc-setup :(

You can probably work-around this using PYTHONPATH, though.

[Alec Leamas]

Additional patches in [8862d3] (manpage) and [43ac23] (dump_config, how the thing is printed.). With these, and Joel's initial feedback I'm closing this bug - if there are problems please file new bugs.

Oldest bug closed :)

[Alec Leamas]

@joel: I'd be happy to include the config file in the database, from 0.9.2 in https://sf.net/p/lirc-remotes. However, it needs an update according to the checklist in https://sourceforge.net/p/lirc-remotes/wiki/Checklist