[mythtv-users] Save my WAF: HD-PVR IR blaster problems - mythbuntu 64bit - valid lirc_t numbers?

Sat Mar 27 12:09:16 UTC 2010

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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-users/attachments/20100327/b867a616/attachment.htm>