[mythtv-users] Need Help: HD-PVR IR Blaster [SOLVED....SORT OF]

[Jarod Wilson]

On Jan 4, 2011, at 10:53 PM, Martin Lynch wrote:

> 
>>>> >  However if I replace:
>>>> >
>>>> >    name 0_26_KEY_0
>>>> >      1703936
>>>> >
>>>> >  with
>>>> >
>>>> >    name 0_26_KEY_0
>>>> >      2149187584
>>>> >
>>>> >  it fails ("2149187584" is the code corresponding to "name
>>>> 1_26_KEY_0"):
>>> Perhaps it is worth noting that 2149187584 is 0x801A0000 in hex, which
>>> if stored as a signed number is -1703936 or so.  Perhaps something in
>>> the code doesn't like negative numbers.
>> Well, that's fascinating! If that's the case, would it have different
>> implications on a 64 bit machine vs a 32 bit (ie is the decision made
>> in the programming to make it either a 32 bit signed integer or a 64
>> bit signed integer? Or is that automatically accounted for?)?
>> 
>> Jarod: can you possibly shed some light on this? ie what happens to
>> these numbers/are they converted/etc?
> In case anyone is following this thread (and so it ends up on the record), here's how this played out:
> 
> Try as I might, I was unable to get the HD-PVR's IR Blaster to work. Michael Lynch very kindly sent me all his configuration files which were known to work, however upon inserting Michael's lircd.conf file to /etc/lirc, once again my system refused to recognize any lircd.conf which contained blaster codes with 10 digits - as soon as a single 10 digit code was included anywhere, $irsend LIST "" "" would report nothing.
> 
> I began to suspect it was either a kernel issue or a 64 bit vs 32 bit issue, so I tested both: I went through the compile/copy files/etc procedure on 2.6.31-11-rt and also 2.6.32-27-generic; neither worked once the 10 digit codes were introduced. I also went through the procedure on a 32 bit laptop: likewise everything went swimmingly until a 10 digit code was introduced, then nothing.
> 
> I sent a private email to Jarod and posted my question above and signed up to the LIRC mailing list, none of which elicited any response, so having wasted a good 3 weeks on this, I gave up.

Sorry, I was on vacation. Or at least, I'm told that's what it was. Now I'm
busy catching up at work after returning from adventures in babysitting. A
reply is/was on my TODO list, but its a long list, and I'm not exactly paid
to work on it, so work and family come first.

My thought was that this problem had been hacked around in lirc 0.9.0, but
it was actually a change in 0.8.7-pre2 or pre3 I was thinking of:

http://lirc.git.sourceforge.net/git/gitweb.cgi?p=lirc/lirc;a=commitdiff;h=46cbaaf3586c4465db8e81b37637b322d5832b5e

I only just now had a chance to look that up though, and you may have been
hitting something entirely different, I dunno right now.

-- 
Jarod Wilson
jarod at wilsonet.com