<div class="gmail_quote">On Tue, Nov 24, 2009 at 5:16 PM, Johnny Walker <span dir="ltr"><<a href="mailto:johnnyjboss@gmail.com" target="_blank">johnnyjboss@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div></div><div>On Tue, Nov 24, 2009 at 4:13 PM, Jarod Wilson <<a href="mailto:jarod@wilsonet.com" target="_blank">jarod@wilsonet.com</a>> wrote:<br>
> On Nov 24, 2009, at 4:58 PM, Jerry Rubinow wrote:<br>
><br>
>> > There are reports of the unit essentially locking itself up during recording if the ir part is being polled by the lirc_zilog driver, yes. Not sure if that's an issue with the hdpvr driver or the lirc_zilog driver at this point. I don't actually use my hdpvr for much of anything at the moment, and haven't had time to dig into it.<br>
>> ><br>
>> > Hmmm. Does use of the HD-PVR receiver necessitate use of lirc_zilog?<br>
>><br>
>> Yes.<br>
>><br>
>> > Is lirc_zilog always polling the IR?<br>
>><br>
>> If loaded and bound to the hdpvr, yes.<br>
>><br>
>> > Is there any way to prevent polling,<br>
>><br>
>> Don't load lirc_zilog, or rewrite lirc_zilog to be interrupt-driven. (Not even sure if that's possible... It'd definitely be preferred if it was though).<br>
>><br>
>> > and what implications does that have?<br>
>><br>
>> Non-functional IR receiver. If you're not polling it, you're not going to see any incoming IR signals.<br>
>><br>
>> Sounds like it's unknown whether this lockup affects all HD-PVR+lirc users or what the frequency is, or when you'll have time to look into it.<br>
><br>
> Correct.<br>
><br>
>> Fair enough. It's not the answer I was hoping for, but better than no answer. I still think I'll go ahead and get the Revo, and if I experience the same thing and it isn't too hard, I'll try to help debug it.<br>
><br>
> Any and all help doing so would be much appreciated. However, at the moment, I'm not quite sure where to start, other than running both the hdpvr driver and lirc_zilog driver with full-blown module debugging options enabled.<br>
><br>
>> When you say "non-functional IR receiver", do you mean the driver isn't functioning or the hardware/firmware? Or unknown?<br>
><br>
> The driver has to poll the IR chip to see if a new signal has arrived. If it doesn't poll the IR chip, you'll never know that a button was pressed, rendering the receiver non-functional.<br>
<br>
</div></div>I have the HD-PVR and I don't use the lirc_zilog - opting instead to<br>
control my STB with Firewire.<br>
<br>
The lirc_zilog is only needed if you want to use the IR receiver<br>
portion of the HD-PVR.<br>
<br>
Since my HD-PVR is on a dedicated backend unit I don't need IR to work<br>
on that box.<br></blockquote><div><br></div><div>But my question was about the receiver, not the blaster. Like you, I've been using firewire for STB control for years. Hey wait a second, the Revo doesn't have firewire! ....now see there's the problem with planning hardware upgrades in your head. I just realized that the Revo will not be in the same room as the STB, so it doesn't matter that it doesn't have firewire. The STB will be near the HD-PVR, which will be attached to the backend in the basement. What was I thinking? I have no use for the Revo's IR receiver, and can use the backend's firewire to change the STB channel, so no use for blaster either. </div>
<div><br></div><div>I guess I won't have the problem I thought I would.</div><div><br></div><div>Thanks, Johnny.</div><div><br></div><div>-Jerry</div>
</div>