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

Mon Jun 7 02:08:25 UTC 2010

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 at 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 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
>>
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-users/attachments/20100606/c3581f1f/attachment-0001.htm>