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".<div>
<br></div><div>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?</div><div><br></div><div>Or, can I convert the numbers into a different format? the lircd.conf says RAW_CODES. Is there another format that I could use?</div>
<div><br></div><div>Thanks for your help.</div><div>Randy<br><br><div class="gmail_quote">On Sat, Mar 27, 2010 at 4:59 AM, Randy Thomae <span dir="ltr"><<a href="mailto:slick@alum.mit.edu">slick@alum.mit.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div>Jarod, Thanks for looking at this. comments below.</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>> Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: "2147549184": must be a valid<br>
> (lirc_t) number<br>
<br>
</div>iirc, lirc_t is an int, so its got an upper limit of 2147483648. Try<br>
commenting out the offending line. I should talk to Christoph about<br>
replacing lirc_t with uint64_t or uint32_t...<br>
<div><br></div></blockquote></div><div>Okay, I will try to figure that out. I found a relevant post on what to change on blushingpenguin here <span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse"><a href="http://www.blushingpenguin.com/mark/blog/?p=24&cp=5" style="color:rgb(0, 101, 204)" target="_blank">http://www.blushingpenguin.com/mark/blog/?p=24&cp=5</a>:</span></div>
<div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse"><span style="border-collapse:separate;font-family:'Lucida Grande', 'Lucida Sans Unicode', Verdana, sans-serif;font-size:14px;letter-spacing:-1px;line-height:24px"><div>
311</div><p style="letter-spacing:-1px">lircd: error in configfile line 291:<br>lircd: “2150039562″: must be a valid (lirc_t) number<br>
lircd: reading of config file failed</p><p style="letter-spacing:-1px">I added this to daemons/config_file.c : lirc_t s_strtolirc_t(char *val)</p>
<p style="letter-spacing:-1px">logprintf(LOG_ERR,”DBG s_strtolirc_t: %d: %s => n %lx => %x == %lx”,line,val,n,h,((unsigned long) h));</p>
<p style="letter-spacing:-1px">lircd: DBG s_strtolirc_t: 291: 2150039562 => n 8027000a => 8027000a == ffffffff8027000a</p>
<p style="letter-spacing:-1px">The problem is that when a signed int is cast to a larger unit, the sign bit is extended.</p>
<p style="letter-spacing:-1px">(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.)<br>
— daemons/config_file.c.old 2007-08-31 21:43:48.120382951 -0700<br>+++ daemons/config_file.c 2007-08-31 21:59:38.503700384 -0700<br>@@ -200,7 +200,7 @@ lirc_t s_strtolirc_t(char *val)</p><p style="letter-spacing:-1px">
n=strtoul(val,&endptr,0);<br>h=(lirc_t) n;<br>- if(!*val || *endptr || n!=((unsigned long) h))<br>+ if(!*val || *endptr)<br>{<br>logprintf(LOG_ERR,”error in configfile line %d:”,line);<br>logprintf(LOG_ERR,”\”%s\”: must be a valid (lirc_t) “</p>
</span></span></div><div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse"><br></span></div><div><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse">I am going to look at this now.</span></div>
<div class="im">
<div> </div><div> > Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: reading of file</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
> '/etc/lirc//lircd.conf' failed<br>
> Mar 26 04:51:33 mBAQ lircd-0.8.6[1280]: reading of config file failed<br>
> Mar 26 04:51:33 mBAQ lircd-0.8.6[1311]: lircd(default) ready, using<br>
> /var/run/lirc/lircd<br>
> Remember this worked on my 32 bit install on ancient hardware. I think I was<br>
> using 2.6.31-14 on that box.<br>
<br>
</div>I wonder if an older lircd simply ignored the range error and continued...<br>
<div><br></div></blockquote></div><div>I built it within the last month, so...</div><div><br></div><div><div>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).</div>
<div> </div></div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
> I have googled all week for this problem and found a couple of things:<br>
> 1. people "fix" this problem by deleting all the satellite codes from their<br>
> lircd.conf. Unfortunately I have a DirecTv sat box using codeset 1_125, so<br>
> that wont work for me.<br>
<br>
</div>Yeah, this probably requires some fixage to lircd.<br>
<div><br></div></blockquote></div><div>Should I report this somehow?</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
> 2. Some people seem to be using this in 64bit Linux, but they may all be<br>
> using Fedora? Is anyone out there using mythbuntu 64bit and HD-PVR IR<br>
> blasting to a Satellite box?<br>
<br>
</div>Shouldn't really matter what Linux distro you're using, I push all my<br>
fixes upstream too, though other distros might not track the fixes as<br>
closely as Fedora, since I'm the one who commits the fixes for Fedora<br>
too...<br>
<div><br></div></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
> 3. Some people were posting about a 64bit bug related to this?<br>
<br>
</div>I'm not sure exactly what that might be.<br>
<div><br></div></blockquote><div><br></div></div><div>It seemed that all the posts in the comments on blushingpenguin here <span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse"><a href="http://www.blushingpenguin.com/mark/blog/?p=24&cp=5" style="color:rgb(0, 101, 204)" target="_blank">http://www.blushingpenguin.com/mark/blog/?p=24&cp=5</a> that referenced this problem were using 64 bit.</span></div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
> 4. Jarod Wilson - (to whom anyone wanting to use an HD-PVR owes their next<br>
> born child for all of his incredible work on this - THANK YOU!!!!!!!)<br>
<br>
</div>No, Janne Grunau deserves far more credit, he did the bulk of the<br>
hdpvr driver work, I just did a few little things here and there for<br>
the IR part, which isn't even fully stabilized for most people yet. :)<br></blockquote></div><div>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.</div>
<div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> has<br>
> made a number of patches, some include changing the variable<br>
> types: <a href="http://cvs.fedoraproject.org/viewvc/F-12/lirc/" target="_blank">http://cvs.fedoraproject.org/viewvc/F-12/lirc/</a><br>
> I tried applying these patches, but I was not able to successfully do that.<br>
> I also noticed that he is running 64 bit and said these patches would help<br>
> 32bit users - the opposite of my situation although I did notice he is<br>
> running Fedora.<br>
<br>
</div>They're irrelevant here, they're for the ioctl interface types. I<br>
patched the ioctl interface in the Fedora kernel and forgot to make<br>
the corresponding change to the Fedora userspace. As long as the two<br>
match, you're fine on that front.<br>
<div><br></div></blockquote></div><div>Thats good news, because I got way over my head trying to apply your patches on one of my attempts at fixing this.</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
> Can anyone help me fix this, or would you recommend:<br>
> A. Fedora?<br>
<br>
</div>Nah, Linux is Linux.<br>
<div><br></div></blockquote></div><div>Also good news, as I am just starting to learn my way around a few things.</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
> B. Different blaster device - which one?<br>
<br>
</div>An mceusb transceiver. Even if you get things sorted w/the hdpvr<br>
blaster, its not stable for a lot of people -- the hdpvr locks up<br>
during recording if the IR part is enabled.<br>
<font color="#888888"><br></font></blockquote></div><div>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.</div>
<div><br></div><div>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.</div>
<div></div></div><br><div>Thanks!</div><div>Randy</div>
</blockquote></div><br></div>