Mailing List Archive

Save my WAF: HD-PVR IR blaster problems - mythbuntu 64bit - valid lirc_t numbers?
Hi. First off, I am a Linux Noob - sorry in advance.

I have never posted to a mailing list before, please let me know if I should
do this differently.

I have been working on this for about a month, and the WAF (Wife Acceptance
Factor) is at an all time low.

I started with setting up mythbuntu from a 32bit install CD on an old p4
2Ghz. Set-up went great. I followed the mythtv HDPVR wiki page(
http://www.mythtv.org/wiki/Hauppauge_HD-PVR), and got IR channel changing
working pretty quickly. Unfortunately, I eventually figured out that my old
hardware couldn't handle the HDPVR (old mobo reqd SATA and USB2.0 cards to
interface with the hard drive and HDPVR), and all my recordings had skips
in them.

So I decided to take the plunge and switch over my main machine (Q6600) to
Ubuntu from Vista "Ultimate"(snickers appropriate). I followed the same
steps, with the exception of using a 64bit install CD.
slick@mBAQ:~$ uname -a
Linux mBAQ 2.6.31-20-generic #58-Ubuntu SMP Fri Mar 12 04:38:19 UTC 2010
x86_64 GNU/Linux

On this install, I can not make lirc read the satellite codes in lircd.conf.
I have tried about 20 different approaches. Yesterday, I went back to the
beginning and slowly stepped through the process. Here is the good news:

[ 24.352787] lirc_dev: IR Remote Control driver registered, major 251
[ 24.354653] lirc_zilog: Zilog/Hauppauge IR driver initializing
[ 24.356753] lirc_zilog: chip found with RX and TX
[ 24.356848] lirc_dev: lirc_register_driver: sample_rate: 0
[ 24.356903] Zilog/Hauppauge i2c IR 1-0071: firmware: requesting
haup-ir-blaster.bin
[ 26.822145] lirc_zilog: Zilog/Hauppauge IR blaster firmware version 1.3.0
loaded
[ 26.826918] lirc_zilog: chip found with RX and TX
[ 26.827343] lirc_dev: lirc_register_driver: sample_rate: 0
[ 27.073189] lirc_zilog: Zilog/Hauppauge IR blaster firmware version 2.1.0
loaded
[ 27.073228] lirc_zilog: initialization complete

Here is the bad news:
slick@mBAQ:~$ cat /var/log/daemon.log | grep -i lircd
Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: error in configfile line 62:
Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: "2147549184": must be a valid
(lirc_t) number
Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: reading of file
'/etc/lirc//lircd.conf' failed
Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: reading of config file failed
Mar 26 04:51:33 mBAQ lircd-0.8.6[1311]: lircd(default) ready, using
/var/run/lirc/lircd

Remember this worked on my 32 bit install on ancient hardware. I think I was
using 2.6.31-14 on that box.

I have googled all week for this problem and found a couple of things:
1. people "fix" this problem by deleting all the satellite codes from their
lircd.conf. Unfortunately I have a DirecTv sat box using codeset 1_125, so
that wont work for me.
2. Some people seem to be using this in 64bit Linux, but they may all be
using Fedora? Is anyone out there using mythbuntu 64bit and HD-PVR IR
blasting to a Satellite box?
3. Some people were posting about a 64bit bug related to this?
4. Jarod Wilson - (to whom anyone wanting to use an HD-PVR owes their next
born child for all of his incredible work on this - THANK YOU!!!!!!!) has
made a number of patches, some include changing the variable types:
http://cvs.fedoraproject.org/viewvc/F-12/lirc/
I tried applying these patches, but I was not able to successfully do that.
I also noticed that he is running 64 bit and said these patches would help
32bit users - the opposite of my situation although I did notice he is
running Fedora.

Can anyone help me fix this, or would you recommend:
A. Fedora?
B. Different blaster device - which one?

Thanks for your help
Randy

ps. Loving Ubuntu
Save my WAF: HD-PVR IR blaster problems - mythbuntu 64bit - valid lirc_t numbers? [ In reply to ]
Hi. First off, I am a Linux Noob - sorry in advance.

I have never posted to a mailing list before, please let me know if I should
do this differently.

I have been working on this for about a month, and the WAF (Wife Acceptance
Factor) is at an all time low.

I started with setting up mythbuntu from a 32bit install CD on an old p4
2Ghz. Set-up went great. I followed the mythtv HDPVR wiki page(
http://www.mythtv.org/wiki/Hauppauge_HD-PVR), and got IR channel changing
working pretty quickly. Unfortunately, I eventually figured out that my old
hardware couldn't handle the HDPVR (old mobo reqd SATA and USB2.0 cards to
interface with the hard drive and HDPVR), and all my recordings had skips
in them.

So I decided to take the plunge and switch over my main machine (Q6600) to
Ubuntu from Vista "Ultimate"(snickers appropriate). I followed the same
steps, with the exception of using a 64bit install CD.
slick@mBAQ:~$ uname -a
Linux mBAQ 2.6.31-20-generic #58-Ubuntu SMP Fri Mar 12 04:38:19 UTC 2010
x86_64 GNU/Linux

On this install, I can not make lirc read the satellite codes in lircd.conf.
I have tried about 20 different approaches. Yesterday, I went back to the
beginning and slowly stepped through the process. Here is the good news:

[ 24.352787] lirc_dev: IR Remote Control driver registered, major 251
[ 24.354653] lirc_zilog: Zilog/Hauppauge IR driver initializing
[ 24.356753] lirc_zilog: chip found with RX and TX
[ 24.356848] lirc_dev: lirc_register_driver: sample_rate: 0
[ 24.356903] Zilog/Hauppauge i2c IR 1-0071: firmware: requesting
haup-ir-blaster.bin
[ 26.822145] lirc_zilog: Zilog/Hauppauge IR blaster firmware version 1.3.0
loaded
[ 26.826918] lirc_zilog: chip found with RX and TX
[ 26.827343] lirc_dev: lirc_register_driver: sample_rate: 0
[ 27.073189] lirc_zilog: Zilog/Hauppauge IR blaster firmware version 2.1.0
loaded
[ 27.073228] lirc_zilog: initialization complete

Here is the bad news:
slick@mBAQ:~$ cat /var/log/daemon.log | grep -i lircd
Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: error in configfile line 62:
Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: "2147549184": must be a valid
(lirc_t) number
Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: reading of file
'/etc/lirc//lircd.conf' failed
Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: reading of config file failed
Mar 26 04:51:33 mBAQ lircd-0.8.6[1311]: lircd(default) ready, using
/var/run/lirc/lircd

Remember this worked on my 32 bit install on ancient hardware. I think I was
using 2.6.31-14 on that box.

I have googled all week for this problem and found a couple of things:
1. people "fix" this problem by deleting all the satellite codes from their
lircd.conf. Unfortunately I have a DirecTv sat box using codeset 1_125, so
that wont work for me.
2. Some people seem to be using this in 64bit Linux, but they may all be
using Fedora? Is anyone out there using mythbuntu 64bit and HD-PVR IR
blasting to a Satellite box?
3. Some people were posting about a 64bit bug related to this?
4. Jarod Wilson - (to whom anyone wanting to use an HD-PVR owes their next
born child for all of his incredible work on this - THANK YOU!!!!!!!) has
made a number of patches, some include changing the variable types:
http://cvs.fedoraproject.org/viewvc/F-12/lirc/
I tried applying these patches, but I was not able to successfully do that.
I also noticed that he is running 64 bit and said these patches would help
32bit users - the opposite of my situation although I did notice he is
running Fedora.

Can anyone help me fix this, or would you recommend:
A. Fedora?
B. Different blaster device - which one?

Thanks for your help
Randy

ps. Loving Ubuntu
Re: Save my WAF: HD-PVR IR blaster problems - mythbuntu 64bit - valid lirc_t numbers? [ In reply to ]
On 03/26/2010 08:09 AM, Randy Thomae wrote:
> Hi. First off, I am a Linux Noob - sorry in advance.
>
> I have never posted to a mailing list before, please let me know if I
> should do this differently.
>
> I have been working on this for about a month, and the WAF (Wife
> Acceptance Factor) is at an all time low.
>
> I started with setting up mythbuntu from a 32bit install CD on an old p4
> 2Ghz. Set-up went great. I followed the mythtv HDPVR wiki
> page(http://www.mythtv.org/wiki/Hauppauge_HD-PVR), and got IR channel
> changing working pretty quickly. Unfortunately, I eventually figured out
> that my old hardware couldn't handle the HDPVR (old mobo reqd SATA and
> USB2.0 cards to interface with the hard drive and HDPVR), and all my
> recordings had skips in them.
>
> So I decided to take the plunge and switch over my main machine (Q6600)
> to Ubuntu from Vista "Ultimate"(snickers appropriate). I followed the
> same steps, with the exception of using a 64bit install CD.
> slick@mBAQ:~$ uname -a
> Linux mBAQ 2.6.31-20-generic #58-Ubuntu SMP Fri Mar 12 04:38:19 UTC 2010
> x86_64 GNU/Linux
>
> On this install, I can not make lirc read the satellite codes in
> lircd.conf. I have tried about 20 different approaches. Yesterday, I
> went back to the beginning and slowly stepped through the process. Here
> is the good news:
>
> [ 24.352787] lirc_dev: IR Remote Control driver registered, major 251
> [ 24.354653] lirc_zilog: Zilog/Hauppauge IR driver initializing
> [ 24.356753] lirc_zilog: chip found with RX and TX
> [ 24.356848] lirc_dev: lirc_register_driver: sample_rate: 0
> [ 24.356903] Zilog/Hauppauge i2c IR 1-0071: firmware: requesting
> haup-ir-blaster.bin
> [ 26.822145] lirc_zilog: Zilog/Hauppauge IR blaster firmware version
> 1.3.0 loaded
> [ 26.826918] lirc_zilog: chip found with RX and TX
> [ 26.827343] lirc_dev: lirc_register_driver: sample_rate: 0
> [ 27.073189] lirc_zilog: Zilog/Hauppauge IR blaster firmware version
> 2.1.0 loaded
> [ 27.073228] lirc_zilog: initialization complete
>
> Here is the bad news:
> slick@mBAQ:~$ cat /var/log/daemon.log | grep -i lircd
> Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: error in configfile line 62:
> Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: "2147549184": must be a valid
> (lirc_t) number
> Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: reading of file
> '/etc/lirc//lircd.conf' failed
> Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: reading of config file failed
> Mar 26 04:51:33 mBAQ lircd-0.8.6[1311]: lircd(default) ready, using
> /var/run/lirc/lircd
>
> Remember this worked on my 32 bit install on ancient hardware. I think I
> was using 2.6.31-14 on that box.
>
> I have googled all week for this problem and found a couple of things:
> 1. people "fix" this problem by deleting all the satellite codes from
> their lircd.conf. Unfortunately I have a DirecTv sat box using codeset
> 1_125, so that wont work for me.
> 2. Some people seem to be using this in 64bit Linux, but they may all be
> using Fedora? Is anyone out there using mythbuntu 64bit and HD-PVR IR
> blasting to a Satellite box?
> 3. Some people were posting about a 64bit bug related to this?
> 4. Jarod Wilson - (to whom anyone wanting to use an HD-PVR owes their
> next born child for all of his incredible work on this - THANK
> YOU!!!!!!!) has made a number of patches, some include changing the
> variable types: http://cvs.fedoraproject.org/viewvc/F-12/lirc/
> I tried applying these patches, but I was not able to successfully do
> that. I also noticed that he is running 64 bit and said these patches
> would help 32bit users - the opposite of my situation although I did
> notice he is running Fedora.

Have you looked VERY closely at lines 61 through 63 of your lircd.conf?
Recent versions of lirc seem to be more intolerant of minor errors in
the format and content of the lircd.conf and lircrc files.

A quick google pointed to this page:

http://www.blushingpenguin.com/mark/blog/?p=24&cp=5

which has some discussion about the raw codes and code sets, and points
to an lircd.conf file which you could try:

http://www.blushingpenguin.com/mark/lmilk/lircd.conf

Geoff


--
Please let me know if anything I say offends you.
I may wish to offend you again in the future.

Tux says: "Be regular. Eat cron flakes."
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Save my WAF: HD-PVR IR blaster problems - mythbuntu 64bit - valid lirc_t numbers? [ In reply to ]
Thanks for the response Geoff.

Have you looked VERY closely at lines 61 through 63 of your lircd.conf?
> Recent versions of lirc seem to be more intolerant of minor errors in the
> format and content of the lircd.conf and lircrc files.
>

I am using the exact lircd.conf you linked to, without modification. That is
the one recommended on the wiki page for the HD-PVR.


>

A quick google pointed to this page:
>
> http://www.blushingpenguin.com/mark/blog/?p=24&cp=5
>
> And that is where I saw the discusssion of an "AMD64 bug"(my point #3). But
that was in 2006. Surely, this is not still a bug?

-Randy
Re: Save my WAF: HD-PVR IR blaster problems - mythbuntu 64bit - valid lirc_t numbers? [ In reply to ]
On Fri, Mar 26, 2010 at 7:57 AM, Randy Thomae <slick@alum.mit.edu> wrote:
...
> On this install, I can not make lirc read the satellite codes in lircd.conf.
> I have tried about 20 different approaches. Yesterday, I went back to the
> beginning and slowly stepped through the process. Here is the good news:
> [   24.352787] lirc_dev: IR Remote Control driver registered, major 251
> [   24.354653] lirc_zilog: Zilog/Hauppauge IR driver initializing
> [   24.356753] lirc_zilog: chip found with RX and TX
> [   24.356848] lirc_dev: lirc_register_driver: sample_rate: 0
> [   24.356903] Zilog/Hauppauge i2c IR 1-0071: firmware: requesting
> haup-ir-blaster.bin
> [   26.822145] lirc_zilog: Zilog/Hauppauge IR blaster firmware version 1.3.0
> loaded
> [   26.826918] lirc_zilog: chip found with RX and TX
> [   26.827343] lirc_dev: lirc_register_driver: sample_rate: 0
> [   27.073189] lirc_zilog: Zilog/Hauppauge IR blaster firmware version 2.1.0
> loaded
> [   27.073228] lirc_zilog: initialization complete
> Here is the bad news:
> slick@mBAQ:~$ cat /var/log/daemon.log | grep -i lircd
> Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: error in configfile line 62:
> Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: "2147549184": must be a valid
> (lirc_t) number

iirc, lirc_t is an int, so its got an upper limit of 2147483648. Try
commenting out the offending line. I should talk to Christoph about
replacing lirc_t with uint64_t or uint32_t...

> Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: reading of file
> '/etc/lirc//lircd.conf' failed
> Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: reading of config file failed
> Mar 26 04:51:33 mBAQ lircd-0.8.6[1311]: lircd(default) ready, using
> /var/run/lirc/lircd
> Remember this worked on my 32 bit install on ancient hardware. I think I was
> using 2.6.31-14 on that box.

I wonder if an older lircd simply ignored the range error and continued...

> I have googled  all week for this problem and found a couple of things:
> 1. people "fix" this problem by deleting all the satellite codes from their
> lircd.conf. Unfortunately I have a DirecTv sat box using codeset 1_125, so
> that wont work for me.

Yeah, this probably requires some fixage to lircd.

> 2. Some people seem to be using this in 64bit Linux, but they may all be
> using Fedora? Is anyone out there using mythbuntu 64bit and HD-PVR IR
> blasting to a Satellite box?

Shouldn't really matter what Linux distro you're using, I push all my
fixes upstream too, though other distros might not track the fixes as
closely as Fedora, since I'm the one who commits the fixes for Fedora
too...

> 3. Some people were posting about a 64bit bug related to this?

I'm not sure exactly what that might be.

> 4. Jarod Wilson - (to whom anyone wanting to use an HD-PVR owes their next
> born child for all of his incredible work on this - THANK YOU!!!!!!!)

No, Janne Grunau deserves far more credit, he did the bulk of the
hdpvr driver work, I just did a few little things here and there for
the IR part, which isn't even fully stabilized for most people yet. :)

> has
> made a number of patches, some include changing the variable
> types: http://cvs.fedoraproject.org/viewvc/F-12/lirc/
> I tried applying these patches, but I was not able to successfully do that.
> I also noticed that he is running 64 bit and said these patches would help
> 32bit users - the opposite of my situation although I did notice he is
> running Fedora.

They're irrelevant here, they're for the ioctl interface types. I
patched the ioctl interface in the Fedora kernel and forgot to make
the corresponding change to the Fedora userspace. As long as the two
match, you're fine on that front.

> Can anyone help me fix this, or would you recommend:
> A. Fedora?

Nah, Linux is Linux.

> B. Different blaster device - which one?

An mceusb transceiver. Even if you get things sorted w/the hdpvr
blaster, its not stable for a lot of people -- the hdpvr locks up
during recording if the IR part is enabled.

--
Jarod Wilson
jarod@wilsonet.com
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Save my WAF: HD-PVR IR blaster problems - mythbuntu 64bit - valid lirc_t numbers? [ In reply to ]
Jarod, Thanks for looking at this. comments below.


> > Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: "2147549184": must be a valid
> > (lirc_t) number
>
> iirc, lirc_t is an int, so its got an upper limit of 2147483648. Try
> commenting out the offending line. I should talk to Christoph about
> replacing lirc_t with uint64_t or uint32_t...
>
> Okay, I will try to figure that out. I found a relevant post on what to
change on blushingpenguin here
http://www.blushingpenguin.com/mark/blog/?p=24&cp=5:
311

lircd: error in configfile line 291:
lircd: “2150039562″: must be a valid (lirc_t) number
lircd: reading of config file failed

I added this to daemons/config_file.c : lirc_t s_strtolirc_t(char *val)

logprintf(LOG_ERR,”DBG s_strtolirc_t: %d: %s => n %lx => %x ==
%lx”,line,val,n,h,((unsigned long) h));

lircd: DBG s_strtolirc_t: 291: 2150039562 => n 8027000a => 8027000a ==
ffffffff8027000a

The problem is that when a signed int is cast to a larger unit, the sign bit
is extended.

(Note, each line should start with a space, and the indentation should be
one or two tabs instead of spaces… I copied right off my console and tabs
probably won’t post correctly here anyway.)
— daemons/config_file.c.old 2007-08-31 21:43:48.120382951 -0700
+++ daemons/config_file.c 2007-08-31 21:59:38.503700384 -0700
@@ -200,7 +200,7 @@ lirc_t s_strtolirc_t(char *val)

n=strtoul(val,&endptr,0);
h=(lirc_t) n;
- if(!*val || *endptr || n!=((unsigned long) h))
+ if(!*val || *endptr)
{
logprintf(LOG_ERR,”error in configfile line %d:”,line);
logprintf(LOG_ERR,”\”%s\”: must be a valid (lirc_t) “

I am going to look at this now.

> Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: reading of file

> > '/etc/lirc//lircd.conf' failed
> > Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: reading of config file failed
> > Mar 26 04:51:33 mBAQ lircd-0.8.6[1311]: lircd(default) ready, using
> > /var/run/lirc/lircd
> > Remember this worked on my 32 bit install on ancient hardware. I think I
> was
> > using 2.6.31-14 on that box.
>
> I wonder if an older lircd simply ignored the range error and continued...
>
> I built it within the last month, so...

Does it work for anyone? If anyone adds a dummy key to their lircd.conf file
with the value 2147549184, I am dying to know if it will work. It worked for
me 2 weeks ago on my 32 bit box. I hypothesize it won't work for people
running 64bit (and I want to be wrong).


> > I have googled all week for this problem and found a couple of things:
> > 1. people "fix" this problem by deleting all the satellite codes from
> their
> > lircd.conf. Unfortunately I have a DirecTv sat box using codeset 1_125,
> so
> > that wont work for me.
>
> Yeah, this probably requires some fixage to lircd.
>
> Should I report this somehow?


> > 2. Some people seem to be using this in 64bit Linux, but they may all be
> > using Fedora? Is anyone out there using mythbuntu 64bit and HD-PVR IR
> > blasting to a Satellite box?
>
> Shouldn't really matter what Linux distro you're using, I push all my
> fixes upstream too, though other distros might not track the fixes as
> closely as Fedora, since I'm the one who commits the fixes for Fedora
> too...
>
>
> 3. Some people were posting about a 64bit bug related to this?
>
> I'm not sure exactly what that might be.
>
>
It seemed that all the posts in the comments on blushingpenguin here
http://www.blushingpenguin.com/mark/blog/?p=24&cp=5 that referenced this
problem were using 64 bit.


> > 4. Jarod Wilson - (to whom anyone wanting to use an HD-PVR owes their
> next
> > born child for all of his incredible work on this - THANK YOU!!!!!!!)
>
> No, Janne Grunau deserves far more credit, he did the bulk of the
> hdpvr driver work, I just did a few little things here and there for
> the IR part, which isn't even fully stabilized for most people yet. :)
>
I'll keep my kids, but still, I came across your name countless times in
posts to people working on LIRC and HD-PVR, and I was really hoping to hear
from you on this - THANK YOU. I will be eagerly awaiting stability.


> > has
> > made a number of patches, some include changing the variable
> > types: http://cvs.fedoraproject.org/viewvc/F-12/lirc/
> > I tried applying these patches, but I was not able to successfully do
> that.
> > I also noticed that he is running 64 bit and said these patches would
> help
> > 32bit users - the opposite of my situation although I did notice he is
> > running Fedora.
>
> They're irrelevant here, they're for the ioctl interface types. I
> patched the ioctl interface in the Fedora kernel and forgot to make
> the corresponding change to the Fedora userspace. As long as the two
> match, you're fine on that front.
>
> Thats good news, because I got way over my head trying to apply your
patches on one of my attempts at fixing this.


> > Can anyone help me fix this, or would you recommend:
> > A. Fedora?
>
> Nah, Linux is Linux.
>
> Also good news, as I am just starting to learn my way around a few things.


> > B. Different blaster device - which one?
>
> An mceusb transceiver. Even if you get things sorted w/the hdpvr
> blaster, its not stable for a lot of people -- the hdpvr locks up
> during recording if the IR part is enabled.
>
> When you say "locks up" - would that create the skips and stuttering I saw?
It worked flawlessly (changing channels and recording)for a week on my old
hardware before I realized that I couldn't fix the stutters in playback.

DOH! Don't tell me that. However bad it is, it can't approach SageTV. The
point of this whole exercise is to leave SageTV. Have you tried any of the
USB to serial solutions? My Directv box has a serial USB port.

Thanks!
Randy
Re: Save my WAF: HD-PVR IR blaster problems - mythbuntu 64bit - valid lirc_t numbers? [ In reply to ]
Help! I can't find the source file to change. What is the name of the file
where this error message is generated? The below post mentions
daemons/config_file.c. Using "locate" I can't find daemons or config_file.c.
None of my lirc files downloaded as per the myth HDPVR wiki even contain
"lirc_t".

Also, I thought of a different approach. Could I record the codes from my
STB remote, and get them in a form my LIRC likes?

Or, can I convert the numbers into a different format? the lircd.conf says
RAW_CODES. Is there another format that I could use?

Thanks for your help.
Randy

On Sat, Mar 27, 2010 at 4:59 AM, Randy Thomae <slick@alum.mit.edu> wrote:

> Jarod, Thanks for looking at this. comments below.
>
>
>> > Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: "2147549184": must be a valid
>> > (lirc_t) number
>>
>> iirc, lirc_t is an int, so its got an upper limit of 2147483648. Try
>> commenting out the offending line. I should talk to Christoph about
>> replacing lirc_t with uint64_t or uint32_t...
>>
>> Okay, I will try to figure that out. I found a relevant post on what to
> change on blushingpenguin here
> http://www.blushingpenguin.com/mark/blog/?p=24&cp=5:
> 311
>
> lircd: error in configfile line 291:
> lircd: “2150039562″: must be a valid (lirc_t) number
> lircd: reading of config file failed
>
> I added this to daemons/config_file.c : lirc_t s_strtolirc_t(char *val)
>
> logprintf(LOG_ERR,”DBG s_strtolirc_t: %d: %s => n %lx => %x ==
> %lx”,line,val,n,h,((unsigned long) h));
>
> lircd: DBG s_strtolirc_t: 291: 2150039562 => n 8027000a => 8027000a ==
> ffffffff8027000a
>
> The problem is that when a signed int is cast to a larger unit, the sign
> bit is extended.
>
> (Note, each line should start with a space, and the indentation should be
> one or two tabs instead of spaces… I copied right off my console and tabs
> probably won’t post correctly here anyway.)
> — daemons/config_file.c.old 2007-08-31 21:43:48.120382951 -0700
> +++ daemons/config_file.c 2007-08-31 21:59:38.503700384 -0700
> @@ -200,7 +200,7 @@ lirc_t s_strtolirc_t(char *val)
>
> n=strtoul(val,&endptr,0);
> h=(lirc_t) n;
> - if(!*val || *endptr || n!=((unsigned long) h))
> + if(!*val || *endptr)
> {
> logprintf(LOG_ERR,”error in configfile line %d:”,line);
> logprintf(LOG_ERR,”\”%s\”: must be a valid (lirc_t) “
>
> I am going to look at this now.
>
> > Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: reading of file
>
>> > '/etc/lirc//lircd.conf' failed
>> > Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: reading of config file failed
>> > Mar 26 04:51:33 mBAQ lircd-0.8.6[1311]: lircd(default) ready, using
>> > /var/run/lirc/lircd
>> > Remember this worked on my 32 bit install on ancient hardware. I think I
>> was
>> > using 2.6.31-14 on that box.
>>
>> I wonder if an older lircd simply ignored the range error and continued...
>>
>> I built it within the last month, so...
>
> Does it work for anyone? If anyone adds a dummy key to their lircd.conf
> file with the value 2147549184, I am dying to know if it will work. It
> worked for me 2 weeks ago on my 32 bit box. I hypothesize it won't work for
> people running 64bit (and I want to be wrong).
>
>
>> > I have googled all week for this problem and found a couple of things:
>> > 1. people "fix" this problem by deleting all the satellite codes from
>> their
>> > lircd.conf. Unfortunately I have a DirecTv sat box using codeset 1_125,
>> so
>> > that wont work for me.
>>
>> Yeah, this probably requires some fixage to lircd.
>>
>> Should I report this somehow?
>
>
>> > 2. Some people seem to be using this in 64bit Linux, but they may all be
>> > using Fedora? Is anyone out there using mythbuntu 64bit and HD-PVR IR
>> > blasting to a Satellite box?
>>
>> Shouldn't really matter what Linux distro you're using, I push all my
>> fixes upstream too, though other distros might not track the fixes as
>> closely as Fedora, since I'm the one who commits the fixes for Fedora
>> too...
>>
>>
> > 3. Some people were posting about a 64bit bug related to this?
>>
>> I'm not sure exactly what that might be.
>>
>>
> It seemed that all the posts in the comments on blushingpenguin here
> http://www.blushingpenguin.com/mark/blog/?p=24&cp=5 that referenced this
> problem were using 64 bit.
>
>
>> > 4. Jarod Wilson - (to whom anyone wanting to use an HD-PVR owes their
>> next
>> > born child for all of his incredible work on this - THANK YOU!!!!!!!)
>>
>> No, Janne Grunau deserves far more credit, he did the bulk of the
>> hdpvr driver work, I just did a few little things here and there for
>> the IR part, which isn't even fully stabilized for most people yet. :)
>>
> I'll keep my kids, but still, I came across your name countless times in
> posts to people working on LIRC and HD-PVR, and I was really hoping to hear
> from you on this - THANK YOU. I will be eagerly awaiting stability.
>
>
>> > has
>> > made a number of patches, some include changing the variable
>> > types: http://cvs.fedoraproject.org/viewvc/F-12/lirc/
>> > I tried applying these patches, but I was not able to successfully do
>> that.
>> > I also noticed that he is running 64 bit and said these patches would
>> help
>> > 32bit users - the opposite of my situation although I did notice he is
>> > running Fedora.
>>
>> They're irrelevant here, they're for the ioctl interface types. I
>> patched the ioctl interface in the Fedora kernel and forgot to make
>> the corresponding change to the Fedora userspace. As long as the two
>> match, you're fine on that front.
>>
>> Thats good news, because I got way over my head trying to apply your
> patches on one of my attempts at fixing this.
>
>
>> > Can anyone help me fix this, or would you recommend:
>> > A. Fedora?
>>
>> Nah, Linux is Linux.
>>
>> Also good news, as I am just starting to learn my way around a few things.
>
>
>> > B. Different blaster device - which one?
>>
>> An mceusb transceiver. Even if you get things sorted w/the hdpvr
>> blaster, its not stable for a lot of people -- the hdpvr locks up
>> during recording if the IR part is enabled.
>>
>> When you say "locks up" - would that create the skips and stuttering I
> saw? It worked flawlessly (changing channels and recording)for a week on my
> old hardware before I realized that I couldn't fix the stutters in playback.
>
> DOH! Don't tell me that. However bad it is, it can't approach SageTV. The
> point of this whole exercise is to leave SageTV. Have you tried any of the
> USB to serial solutions? My Directv box has a serial USB port.
>
> Thanks!
> Randy
>
Re: Save my WAF: HD-PVR IR blaster problems - mythbuntu 64bit - valid lirc_t numbers? [ In reply to ]
Hi Randy,

I'm having the same issue with the 64-bit LIRC stuff and the "must be a
valid (lirc_t) number " message.

If you're using ubuntu.mythbuntu, you will be able to find the file by
downloading the lirc source code. You can do so by typing the following:
"apt-get source lirc". The file you're looking for is under the
lirc-0.8.6/daemon directory.

Good luck, I'm trying to find an solution on my side...

Yannick.

On Sat, Mar 27, 2010 at 8:09 AM, Randy Thomae <slick@alum.mit.edu> wrote:

> Help! I can't find the source file to change. What is the name of the file
> where this error message is generated? The below post mentions
> daemons/config_file.c. Using "locate" I can't find daemons or config_file.c.
> None of my lirc files downloaded as per the myth HDPVR wiki even contain
> "lirc_t".
>
> Also, I thought of a different approach. Could I record the codes from my
> STB remote, and get them in a form my LIRC likes?
>
> Or, can I convert the numbers into a different format? the lircd.conf says
> RAW_CODES. Is there another format that I could use?
>
> Thanks for your help.
> Randy
>
>
> On Sat, Mar 27, 2010 at 4:59 AM, Randy Thomae <slick@alum.mit.edu> wrote:
>
>> Jarod, Thanks for looking at this. comments below.
>>
>>
>>> > Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: "2147549184": must be a valid
>>> > (lirc_t) number
>>>
>>> iirc, lirc_t is an int, so its got an upper limit of 2147483648. Try
>>> commenting out the offending line. I should talk to Christoph about
>>> replacing lirc_t with uint64_t or uint32_t...
>>>
>>> Okay, I will try to figure that out. I found a relevant post on what to
>> change on blushingpenguin here
>> http://www.blushingpenguin.com/mark/blog/?p=24&cp=5:
>> 311
>>
>> lircd: error in configfile line 291:
>> lircd: “2150039562″: must be a valid (lirc_t) number
>> lircd: reading of config file failed
>>
>> I added this to daemons/config_file.c : lirc_t s_strtolirc_t(char *val)
>>
>> logprintf(LOG_ERR,”DBG s_strtolirc_t: %d: %s => n %lx => %x ==
>> %lx”,line,val,n,h,((unsigned long) h));
>>
>> lircd: DBG s_strtolirc_t: 291: 2150039562 => n 8027000a => 8027000a ==
>> ffffffff8027000a
>>
>> The problem is that when a signed int is cast to a larger unit, the sign
>> bit is extended.
>>
>> (Note, each line should start with a space, and the indentation should be
>> one or two tabs instead of spaces… I copied right off my console and tabs
>> probably won’t post correctly here anyway.)
>> — daemons/config_file.c.old 2007-08-31 21:43:48.120382951 -0700
>> +++ daemons/config_file.c 2007-08-31 21:59:38.503700384 -0700
>> @@ -200,7 +200,7 @@ lirc_t s_strtolirc_t(char *val)
>>
>> n=strtoul(val,&endptr,0);
>> h=(lirc_t) n;
>> - if(!*val || *endptr || n!=((unsigned long) h))
>> + if(!*val || *endptr)
>> {
>> logprintf(LOG_ERR,”error in configfile line %d:”,line);
>> logprintf(LOG_ERR,”\”%s\”: must be a valid (lirc_t) “
>>
>> I am going to look at this now.
>>
>> > Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: reading of file
>>
>>> > '/etc/lirc//lircd.conf' failed
>>> > Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: reading of config file failed
>>> > Mar 26 04:51:33 mBAQ lircd-0.8.6[1311]: lircd(default) ready, using
>>> > /var/run/lirc/lircd
>>> > Remember this worked on my 32 bit install on ancient hardware. I think
>>> I was
>>> > using 2.6.31-14 on that box.
>>>
>>> I wonder if an older lircd simply ignored the range error and
>>> continued...
>>>
>>> I built it within the last month, so...
>>
>> Does it work for anyone? If anyone adds a dummy key to their lircd.conf
>> file with the value 2147549184, I am dying to know if it will work. It
>> worked for me 2 weeks ago on my 32 bit box. I hypothesize it won't work for
>> people running 64bit (and I want to be wrong).
>>
>>
>>> > I have googled all week for this problem and found a couple of things:
>>> > 1. people "fix" this problem by deleting all the satellite codes from
>>> their
>>> > lircd.conf. Unfortunately I have a DirecTv sat box using codeset 1_125,
>>> so
>>> > that wont work for me.
>>>
>>> Yeah, this probably requires some fixage to lircd.
>>>
>>> Should I report this somehow?
>>
>>
>>> > 2. Some people seem to be using this in 64bit Linux, but they may all
>>> be
>>> > using Fedora? Is anyone out there using mythbuntu 64bit and HD-PVR IR
>>> > blasting to a Satellite box?
>>>
>>> Shouldn't really matter what Linux distro you're using, I push all my
>>> fixes upstream too, though other distros might not track the fixes as
>>> closely as Fedora, since I'm the one who commits the fixes for Fedora
>>> too...
>>>
>>>
>> > 3. Some people were posting about a 64bit bug related to this?
>>>
>>> I'm not sure exactly what that might be.
>>>
>>>
>> It seemed that all the posts in the comments on blushingpenguin here
>> http://www.blushingpenguin.com/mark/blog/?p=24&cp=5 that referenced this
>> problem were using 64 bit.
>>
>>
>>> > 4. Jarod Wilson - (to whom anyone wanting to use an HD-PVR owes their
>>> next
>>> > born child for all of his incredible work on this - THANK YOU!!!!!!!)
>>>
>>> No, Janne Grunau deserves far more credit, he did the bulk of the
>>> hdpvr driver work, I just did a few little things here and there for
>>> the IR part, which isn't even fully stabilized for most people yet. :)
>>>
>> I'll keep my kids, but still, I came across your name countless times in
>> posts to people working on LIRC and HD-PVR, and I was really hoping to hear
>> from you on this - THANK YOU. I will be eagerly awaiting stability.
>>
>>
>>> > has
>>> > made a number of patches, some include changing the variable
>>> > types: http://cvs.fedoraproject.org/viewvc/F-12/lirc/
>>> > I tried applying these patches, but I was not able to successfully do
>>> that.
>>> > I also noticed that he is running 64 bit and said these patches would
>>> help
>>> > 32bit users - the opposite of my situation although I did notice he is
>>> > running Fedora.
>>>
>>> They're irrelevant here, they're for the ioctl interface types. I
>>> patched the ioctl interface in the Fedora kernel and forgot to make
>>> the corresponding change to the Fedora userspace. As long as the two
>>> match, you're fine on that front.
>>>
>>> Thats good news, because I got way over my head trying to apply your
>> patches on one of my attempts at fixing this.
>>
>>
>>> > Can anyone help me fix this, or would you recommend:
>>> > A. Fedora?
>>>
>>> Nah, Linux is Linux.
>>>
>>> Also good news, as I am just starting to learn my way around a few
>> things.
>>
>>
>>> > B. Different blaster device - which one?
>>>
>>> An mceusb transceiver. Even if you get things sorted w/the hdpvr
>>> blaster, its not stable for a lot of people -- the hdpvr locks up
>>> during recording if the IR part is enabled.
>>>
>>> When you say "locks up" - would that create the skips and stuttering I
>> saw? It worked flawlessly (changing channels and recording)for a week on my
>> old hardware before I realized that I couldn't fix the stutters in playback.
>>
>> DOH! Don't tell me that. However bad it is, it can't approach SageTV. The
>> point of this whole exercise is to leave SageTV. Have you tried any of the
>> USB to serial solutions? My Directv box has a serial USB port.
>>
>> Thanks!
>> Randy
>>
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
>
Re: Save my WAF: HD-PVR IR blaster problems - mythbuntu 64bit - valid lirc_t numbers? [ In reply to ]
Hello Jarod,

first off, thanks for all your efforts with lirc (along with a slew of other
people as well)!

Were you able to talk with Christoph for the conversion of the lirc_t
variable to something 64-bit-compatible?

Thanks!

Yannick.

On Fri, Mar 26, 2010 at 11:09 PM, Jarod Wilson <jarod@wilsonet.com> wrote:

> On Fri, Mar 26, 2010 at 7:57 AM, Randy Thomae <slick@alum.mit.edu> wrote:
> ...
> > On this install, I can not make lirc read the satellite codes in
> lircd.conf.
> > I have tried about 20 different approaches. Yesterday, I went back to the
> > beginning and slowly stepped through the process. Here is the good news:
> > [ 24.352787] lirc_dev: IR Remote Control driver registered, major 251
> > [ 24.354653] lirc_zilog: Zilog/Hauppauge IR driver initializing
> > [ 24.356753] lirc_zilog: chip found with RX and TX
> > [ 24.356848] lirc_dev: lirc_register_driver: sample_rate: 0
> > [ 24.356903] Zilog/Hauppauge i2c IR 1-0071: firmware: requesting
> > haup-ir-blaster.bin
> > [ 26.822145] lirc_zilog: Zilog/Hauppauge IR blaster firmware version
> 1.3.0
> > loaded
> > [ 26.826918] lirc_zilog: chip found with RX and TX
> > [ 26.827343] lirc_dev: lirc_register_driver: sample_rate: 0
> > [ 27.073189] lirc_zilog: Zilog/Hauppauge IR blaster firmware version
> 2.1.0
> > loaded
> > [ 27.073228] lirc_zilog: initialization complete
> > Here is the bad news:
> > slick@mBAQ:~$ cat /var/log/daemon.log | grep -i lircd
> > Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: error in configfile line 62:
> > Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: "2147549184": must be a valid
> > (lirc_t) number
>
> iirc, lirc_t is an int, so its got an upper limit of 2147483648. Try
> commenting out the offending line. I should talk to Christoph about
> replacing lirc_t with uint64_t or uint32_t...
>
> > Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: reading of file
> > '/etc/lirc//lircd.conf' failed
> > Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: reading of config file failed
> > Mar 26 04:51:33 mBAQ lircd-0.8.6[1311]: lircd(default) ready, using
> > /var/run/lirc/lircd
> > Remember this worked on my 32 bit install on ancient hardware. I think I
> was
> > using 2.6.31-14 on that box.
>
> I wonder if an older lircd simply ignored the range error and continued...
>
> > I have googled all week for this problem and found a couple of things:
> > 1. people "fix" this problem by deleting all the satellite codes from
> their
> > lircd.conf. Unfortunately I have a DirecTv sat box using codeset 1_125,
> so
> > that wont work for me.
>
> Yeah, this probably requires some fixage to lircd.
>
> > 2. Some people seem to be using this in 64bit Linux, but they may all be
> > using Fedora? Is anyone out there using mythbuntu 64bit and HD-PVR IR
> > blasting to a Satellite box?
>
> Shouldn't really matter what Linux distro you're using, I push all my
> fixes upstream too, though other distros might not track the fixes as
> closely as Fedora, since I'm the one who commits the fixes for Fedora
> too...
>
> > 3. Some people were posting about a 64bit bug related to this?
>
> I'm not sure exactly what that might be.
>
> > 4. Jarod Wilson - (to whom anyone wanting to use an HD-PVR owes their
> next
> > born child for all of his incredible work on this - THANK YOU!!!!!!!)
>
> No, Janne Grunau deserves far more credit, he did the bulk of the
> hdpvr driver work, I just did a few little things here and there for
> the IR part, which isn't even fully stabilized for most people yet. :)
>
> > has
> > made a number of patches, some include changing the variable
> > types: http://cvs.fedoraproject.org/viewvc/F-12/lirc/
> > I tried applying these patches, but I was not able to successfully do
> that.
> > I also noticed that he is running 64 bit and said these patches would
> help
> > 32bit users - the opposite of my situation although I did notice he is
> > running Fedora.
>
> They're irrelevant here, they're for the ioctl interface types. I
> patched the ioctl interface in the Fedora kernel and forgot to make
> the corresponding change to the Fedora userspace. As long as the two
> match, you're fine on that front.
>
> > Can anyone help me fix this, or would you recommend:
> > A. Fedora?
>
> Nah, Linux is Linux.
>
> > B. Different blaster device - which one?
>
> An mceusb transceiver. Even if you get things sorted w/the hdpvr
> blaster, its not stable for a lot of people -- the hdpvr locks up
> during recording if the IR part is enabled.
>
> --
> Jarod Wilson
> jarod@wilsonet.com
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
Re: Save my WAF: HD-PVR IR blaster problems - mythbuntu 64bit - valid lirc_t numbers? [ In reply to ]
On Sun, Jun 6, 2010 at 7:12 PM, Yannick Moussette <
yannick.moussette@gmail.com> wrote:

> Hello Jarod,
>
> first off, thanks for all your efforts with lirc (along with a slew of
> other people as well)!
>
> Were you able to talk with Christoph for the conversion of the lirc_t
> variable to something 64-bit-compatible?
>
> Thanks!
>
> Yannick.
>
>
I had this PRECISE problem myself. And here's how I fixed it... You will
need to recompile lirc (which is never fun)...

in the source code for lirc: change the definition of lirc_t (in
lirc-0.8.6/drivers/lirc.h) to be:
typedef unsigned int lirc_t;
(rather than typedef int lirc_t;)

This forces it to a uint32_t type, essentially. Then recompile. Works for
me.

This is something that really needs to be sent to the lirc devs... Jarod,
you up to it? :)
Re: Save my WAF: HD-PVR IR blaster problems - mythbuntu 64bit - valid lirc_t numbers? [ In reply to ]
On Thu, Jul 1, 2010 at 1:34 AM, Gavin Hurlbut <gjhurlbu@gmail.com> wrote:
> On Sun, Jun 6, 2010 at 7:12 PM, Yannick Moussette
> <yannick.moussette@gmail.com> wrote:
>>
>> Hello Jarod,
>> first off, thanks for all your efforts with lirc (along with a slew of
>> other people as well)!
>> Were you able to talk with Christoph for the conversion of the lirc_t
>> variable to something 64-bit-compatible?
>> Thanks!
>> Yannick.
>
> I had this PRECISE problem myself.  And here's how I fixed it...  You will
> need to recompile lirc (which is never fun)...
> in the source code for lirc:  change the definition of lirc_t (in
> lirc-0.8.6/drivers/lirc.h) to be:
> typedef unsigned int lirc_t;
> (rather than typedef int lirc_t;)
> This forces it to a uint32_t type, essentially.  Then recompile.  Works for
> me.
> This is something that really needs to be sent to the lirc devs...  Jarod,
> you up to it? :)

I keep meaning to fix this, and keep forgetting. I'm pretty sure there
are places where lirc_t actually does need to be signed though, so I
don't know that this particular fix would work.


--
Jarod Wilson
jarod@wilsonet.com
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Save my WAF: HD-PVR IR blaster problems - mythbuntu 64bit - valid lirc_t numbers? [ In reply to ]
On Thu, Jul 1, 2010 at 6:59 AM, Jarod Wilson <jarod@wilsonet.com> wrote:

> I keep meaning to fix this, and keep forgetting. I'm pretty sure there
> are places where lirc_t actually does need to be signed though, so I
> don't know that this particular fix would work.


Well, that's likely true. I certainly don't have a very exhaustive testing
environment. It does seem to be operational now. So, buyer beware and all,
but that simple hack does take it from being totally useless to seemingly
working. Granted, I might find it wedged tomorrow or something due to other
uses of the type. There may be a better permanent fix.
Re: Save my WAF: HD-PVR IR blaster problems - mythbuntu 64bit - valid lirc_t numbers? [ In reply to ]
On Thu, Jul 1, 2010 at 1:27 PM, Gavin Hurlbut <gjhurlbu@gmail.com> wrote:
> On Thu, Jul 1, 2010 at 6:59 AM, Jarod Wilson <jarod@wilsonet.com> wrote:
>>
>> I keep meaning to fix this, and keep forgetting. I'm pretty sure there
>> are places where lirc_t actually does need to be signed though, so I
>> don't know that this particular fix would work.
>
> Well, that's likely true.  I certainly don't have a very exhaustive testing
> environment.  It does seem to be operational now.  So, buyer beware and all,
> but that simple hack does take it from being totally useless to seemingly
> working.  Granted, I might find it wedged tomorrow or something due to other
> uses of the type.  There may be a better permanent fix.

I do hope to get back to the hdpvr and lirc_zilog (and this issue)
RSN, as I'm nearing completion of the mceusb port and ir-core lirc
bridge plugin. Once those are put to bed, it'll be on to the next lirc
driver to port, and lirc_zilog seems a good candidate for multiple
reasons.

--
Jarod Wilson
jarod@wilsonet.com
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Re: Save my WAF: HD-PVR IR blaster problems - mythbuntu 64bit - valid lirc_t numbers? [ In reply to ]
On Thu, Jul 1, 2010 at 2:57 PM, Jarod Wilson <jarod@wilsonet.com> wrote:

> On Thu, Jul 1, 2010 at 1:27 PM, Gavin Hurlbut <gjhurlbu@gmail.com> wrote:
> > On Thu, Jul 1, 2010 at 6:59 AM, Jarod Wilson <jarod@wilsonet.com> wrote:
> >>
> >> I keep meaning to fix this, and keep forgetting. I'm pretty sure there
> >> are places where lirc_t actually does need to be signed though, so I
> >> don't know that this particular fix would work.
> >
> > Well, that's likely true. I certainly don't have a very exhaustive
> testing
> > environment. It does seem to be operational now. So, buyer beware and
> all,
> > but that simple hack does take it from being totally useless to seemingly
> > working. Granted, I might find it wedged tomorrow or something due to
> other
> > uses of the type. There may be a better permanent fix.
>
> I do hope to get back to the hdpvr and lirc_zilog (and this issue)
> RSN, as I'm nearing completion of the mceusb port and ir-core lirc
> bridge plugin. Once those are put to bed, it'll be on to the next lirc
> driver to port, and lirc_zilog seems a good candidate for multiple
> reasons.


Sweet. Should you need a test user for this particular issue, let me know.
I have the HD-PVR and IR transmitting requiring the long 32-bit raw codes
with MSB set. This seems to be the magic combination of mess... oh, and a
64-bit platform. (sorry, ubuntu, not FC this time around).
Re: Save my WAF: HD-PVR IR blaster problems - mythbuntu 64bit - valid lirc_t numbers? [ In reply to ]
On Thu, Jul 1, 2010 at 6:33 PM, Gavin Hurlbut <gjhurlbu@gmail.com> wrote:
> On Thu, Jul 1, 2010 at 2:57 PM, Jarod Wilson <jarod@wilsonet.com> wrote:
>>
>> On Thu, Jul 1, 2010 at 1:27 PM, Gavin Hurlbut <gjhurlbu@gmail.com> wrote:
>> > On Thu, Jul 1, 2010 at 6:59 AM, Jarod Wilson <jarod@wilsonet.com> wrote:
>> >>
>> >> I keep meaning to fix this, and keep forgetting. I'm pretty sure there
>> >> are places where lirc_t actually does need to be signed though, so I
>> >> don't know that this particular fix would work.
>> >
>> > Well, that's likely true.  I certainly don't have a very exhaustive
>> > testing
>> > environment.  It does seem to be operational now.  So, buyer beware and
>> > all,
>> > but that simple hack does take it from being totally useless to
>> > seemingly
>> > working.  Granted, I might find it wedged tomorrow or something due to
>> > other
>> > uses of the type.  There may be a better permanent fix.
>>
>> I do hope to get back to the hdpvr and lirc_zilog (and this issue)
>> RSN, as I'm nearing completion of the mceusb port and ir-core lirc
>> bridge plugin. Once those are put to bed, it'll be on to the next lirc
>> driver to port, and lirc_zilog seems a good candidate for multiple
>> reasons.
>
> Sweet.  Should you need a test user for this particular issue, let me know.
>  I have the HD-PVR and IR transmitting requiring the long 32-bit raw codes
> with MSB set.  This seems to be the magic combination of mess... oh, and a
> 64-bit platform.  (sorry, ubuntu, not FC this time around).

I just committed something to lirc cvs that I *think* will take care
of this, without disrupting anything else... Hoping I can get an lirc
0.8.7pre2 snapshot out tonight or tomorrow.

--
Jarod Wilson
jarod@wilsonet.com
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users