[mythtv-users] Multiple LIRC Devices Causing Problems with HD-PVR Blaster on F14

[John Welch]

On Mon, Feb 14, 2011 at 5:26 PM, John Welch <jrw3319 at gmail.com> wrote:
> On Mon, Feb 14, 2011 at 11:15 AM, Jarod Wilson <jarod at wilsonet.com> wrote:
>> On Feb 14, 2011, at 9:51 AM, John Welch wrote:
>>
>>> On Sun, Feb 13, 2011 at 11:56 PM, Jarod Wilson <jarod at wilsonet.com> wrote:
>>>> On Feb 13, 2011, at 2:42 PM, John Welch wrote:
>>>>
>>>>> Hello all,
>>>>>
>>>>> I have been having ongoing issues with the IR Blaster on my HD-PVR
>>>>> being used for channel changing on my Fedora 14 MythTV back-end
>>>>> system.  I finally had a chance to do some troubleshooting today and
>>>>> discovered that somewhere along the way my system switched things
>>>>> around and is now assigning the first lirc device (/dev/lirc0) to my
>>>>> pcHD3000 (module ir_lirc_codec) and the second lirc device
>>>>> (/dev/lirc1) to the HD-PVR (module lirc_zilog).  Previously this had
>>>>> consistently been the other way around, and I never had to do anything
>>>>> to force the order.
>>>>
>>>> I'm a bit confused here. lirc_zilog has to be manually loaded, so I'm not
>>>> sure how it would have been loading before the pcHDTV HD-3000's driver.
>>>> Actually, I'm not sure *what* the HD-3000's driver is... Can you pastebin
>>>> full dmesg output after a fresh boot for me to peek at?
>>>>
>>>>
>>>>> I thought it might be as easy as updating my lirc
>>>>> start-up configuration file (/etc/sysconfig/lirc) to point to
>>>>> /dev/lirc1 instead of /dev/lirc0.  However, as of yet at least I have
>>>>> not been able to make this work.
>>>>
>>>> That *should* work.
>>>>
>>>>
>>>>> Right now the only way I can get the HD-PVR blaster to work is to stop
>>>>> lirc, remove all the lirc modules, add the lirc_zilog back in
>>>>> (modprobe lirc_zilog) and then restart lirc.  I guess I can script
>>>>> this, but there seems like the *should* be a better way.  As I am not
>>>>> using anything with lirc and the pcHD3000 I don't really care if this
>>>>> module loads or what device it gets assigned.  All I want is for the
>>>>> HD-PVR blaster to always be /dev/lirc0.  I think there should be a way
>>>>> to force the order of the lirc devices or prevent the ir_lirc_codec
>>>>> from loading, but I can't seem to figure it out.
>>>>
>>>> There are ways. But they're easier to explain if I know what it is that
>>>> is loading up on the HD-3000. And if you let me know how you're loading
>>>> up lirc_zilog right now.
>>>>
>>>>
>>>
>>> Thanks for the reply Jarod.  I guess what I should have said as far as
>>> it previously working is that the HD-PVR blaster was always
>>> /dev/lirc0.  I don't know what device was being assigned to the
>>> HD-3000, or if it was even loading.  As I said, I'm not using anything
>>> with LIRC and the HD-3000 so would never have even bothered to look.
>>
>> Okay, my guess is that there was nothing loading for the HD-3000
>> previously. It might actually be lirc_zilog that is binding to it now,
>> if I'm thinking clearly...
>>
>>> The lirc_zilog module has to be manually loaded?
>>
>> Yes. There's zero auto-load support, so you have to have a script
>> somewhere that's running on startup to load it.
>>
>>> It has been quite a
>>> while since I set this up, but I don't recall putting anything in
>>> rc.local or setting up any other start-up scripts to do this.  I just
>>> boot my system and it is there.  Will have to look through some config
>>> / startup files to see if I can find anything.
>>
>> The recommended place has been /etc/sysconfig/modules/lirc.modules,
>> which gets run from rc.sysinit.
>>
>>> As far as having it work as /dev/lirc1, I was only looking in
>>> /etc/sysconfig/lirc.  Maybe there is another file / setting that needs
>>> to be changed as well?
>>
>> Nope, that should be all there is to it.
>>
>>> I will post complete 'dmesg' output later today when I have access to my system.
>>
>> Thanks, I suspect that'll help paint a much clearer picture for me.
>>
>> --
>> Jarod Wilson
>> jarod at wilsonet.com
>>
>>
>>
>
> I found that I do have a 'modprobe' line in my rc.local file for the
> lirc_zilog module.  Can change it to
> /etc/sysconfig/modules/lirc.modules if that helps the probl
em.
>
> Complete 'dmesg' output from my system after a reboot can be found
> here: http://pastebin.com/32f6F9vB
>
> Thanks again,
> John
>

Just to throw something else into the mix here.  I've been dealing
with this HD-PVR blaster issue for quite some time now (since last
fall) because: a) I didn't do enough in-depth troubleshooting; and b)
I mistakenly thought that there were fixes for the issue in the
testing pipeline.  Well, in all the time that the blaster wasn't
working I continued to use my HD-PVR the best I could.  When I wanted
to schedule a recording for the HD-PVR I had to make sure to set my
STB to the proper channel.  (I know there are other channel changing
options, but I have not had the time or the inclination to explore
them.)  During this time I never had a bad recording from the HD-PVR.

Now that I've figured out the cause of the blaster issues, and have a
less than ideal, but working solution I figured things were pretty
much back to normal as far as the HD-PVR.  Last night was my first
recording since getting the blaster "fixed", and unfortunately I ended
up with a bad / incomplete recording.  The recording quit after less
than a minute, the red "recording" light on my HD-PVR was stuck on,
and when I tried stopping LIRC on my back-end the whole system locked
up.

I used to have similar issues back before when my blaster was working,
but I guess I thought that the fact that I was getting good recordings
despite the broken blaster was a sign that the driver for the HD-PVR
had been fixed / improved.  Now I'm starting to think that the working
blaster is actually a cause of the bad recordings.  Maybe this is a
known issue, but I was rather surprised and disappointed when I ended
up with the incomplete recording last night.  As things stand now I
think I would rather deal with the limitations of not have the blaster
work properly rather than risking not getting a recording at all.

Thanks,
John