cx5000 default auto sleep mode

cx5000 default auto sleep mode

[Timothy D. Lenz]

Thanks to Andy Walls, found out why I kept loosing 1 tuner on a 
FusionHD7 Dual express. Didn't know linux supported an auto sleep mode 
on the tuner chips and that it defaulted to on. Seems like it would be 
better to default to off. If someone wants an auto power down/sleep mode 
and their software supports it, then let the program activate it. Seems 
people are more likely to want the tuners to stay on then keep shutting 
down.

Spent over a year trying to figure out why vdr would loose control of 1 
of the dual tuners when the atscepg pluging was used thinking it was a 
problem with the plugin.

Re: cx5000 default auto sleep mode

[Devin Heitmueller]

On Wed, Apr 14, 2010 at 1:29 PM, Timothy D. Lenz <tlenz@vorgon.com> wrote:
> Thanks to Andy Walls, found out why I kept loosing 1 tuner on a FusionHD7
> Dual express. Didn't know linux supported an auto sleep mode on the tuner
> chips and that it defaulted to on. Seems like it would be better to default
> to off. If someone wants an auto power down/sleep mode and their software
> supports it, then let the program activate it. Seems people are more likely
> to want the tuners to stay on then keep shutting down.
>
> Spent over a year trying to figure out why vdr would loose control of 1 of
> the dual tuners when the atscepg pluging was used thinking it was a problem
> with the plugin.

The xc5000 power management changes I made were actually pretty
thoroughly tested with that card (between myself and Michael Krufky,
we tested it with just about every card that uses the tuner).  In
fact, we uncovered several power management bugs in other drivers as a
result of that effort.  It was a grueling effort that I spent almost
three months working on.

Generally I agree with the premise that functionality like this should
only be enabled for boards it was tested with.  However, in this case
it actually was pretty extensively tested with all the cards in
question (including this one), and thus it was deemed safe to enable
by default.  We've had cases in the past where developers exercised
poor judgement and blindly turned on power management to make it work
with one card, disregarding the possible breakage that could occur
with other cards that use the same driver -- this was *not* one of
those cases.

If there is a bug, it should be pretty straightforward to fix provided
it can be reproduced.

Regarding the general assertion that the power management should be
disabled by default, I disagree.  The power savings is considerable,
the time to bring the tuner out of sleep is negligible, and it's
generally good policy.

Andy, do you have any actual details regarding the nature of the problem?

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: cx5000 default auto sleep mode

[Andy Walls]

On Wed, 2010-04-14 at 13:40 -0400, Devin Heitmueller wrote:
> On Wed, Apr 14, 2010 at 1:29 PM, Timothy D. Lenz <tlenz@vorgon.com> wrote:
> > Thanks to Andy Walls, found out why I kept loosing 1 tuner on a FusionHD7
> > Dual express. Didn't know linux supported an auto sleep mode on the tuner
> > chips and that it defaulted to on. Seems like it would be better to default
> > to off. 
> 
> Regarding the general assertion that the power management should be
> disabled by default, I disagree.  The power savings is considerable,
> the time to bring the tuner out of sleep is negligible, and it's
> generally good policy.
> 
> Andy, do you have any actual details regarding the nature of the problem?

Not really.  DViCo Fusion dual digital tv card.  One side of the card
would yield "black video screen" when starting a digital capture
sometime after (?) the VDR ATSC EPG plugin tried to suck off data.  I'm
not sure there was a causal relationship.

I hypothesized that one side of the dual-tuner was going stupid or one
of the two channels used in the cx23885 was getting confused.  I was
looking at how to narrow the problem down to cx23885 chip or xc5000
tuner, or s5h14xx demod when I noted the power managment module option
for the xc5000.  I suggested Tim try it. 

It was dumb luck that my guess actually made his symptoms go away.

That's all I know.

Regards,
Andy

Re: cx5000 default auto sleep mode

[Devin Heitmueller]

On Wed, Apr 14, 2010 at 11:44 PM, Andy Walls <awalls@md.metrocast.net> wrote:
> On Wed, 2010-04-14 at 13:40 -0400, Devin Heitmueller wrote:
>> On Wed, Apr 14, 2010 at 1:29 PM, Timothy D. Lenz <tlenz@vorgon.com> wrote:
>> > Thanks to Andy Walls, found out why I kept loosing 1 tuner on a FusionHD7
>> > Dual express. Didn't know linux supported an auto sleep mode on the tuner
>> > chips and that it defaulted to on. Seems like it would be better to default
>> > to off.
>>
>> Regarding the general assertion that the power management should be
>> disabled by default, I disagree.  The power savings is considerable,
>> the time to bring the tuner out of sleep is negligible, and it's
>> generally good policy.
>>
>> Andy, do you have any actual details regarding the nature of the problem?
>
> Not really.  DViCo Fusion dual digital tv card.  One side of the card
> would yield "black video screen" when starting a digital capture
> sometime after (?) the VDR ATSC EPG plugin tried to suck off data.  I'm
> not sure there was a causal relationship.
>
> I hypothesized that one side of the dual-tuner was going stupid or one
> of the two channels used in the cx23885 was getting confused.  I was
> looking at how to narrow the problem down to cx23885 chip or xc5000
> tuner, or s5h14xx demod when I noted the power managment module option
> for the xc5000.  I suggested Tim try it.
>
> It was dumb luck that my guess actually made his symptoms go away.
>
> That's all I know.

We did have a similar issue with the PCTV 800i.  Basically, the GPIO
definition was improperly defined for the xc5000 reset callback.  As a
result, it was strobing the reset on both the xc5000 *and* the
s5h1411, which would then cause the s5h1411's hardware state to not
match the driver state.

After multiple round trips with the hardware engineer at PCTV, I
finally concluded that there actually wasn't a way to strobe the reset
without screwing up the demodulator, which prompted me to disable the
xc5000 reset callback (see cx88-cards:2944).

My guess is that the reset GPIO definition for that board is wrong (a
problem exposed by this change), or that it's resetting the s5h1411 as
well.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: cx5000 default auto sleep mode

[Timothy D. Lenz]

On 4/14/2010 8:44 PM, Andy Walls wrote:
> On Wed, 2010-04-14 at 13:40 -0400, Devin Heitmueller wrote:
>> On Wed, Apr 14, 2010 at 1:29 PM, Timothy D. Lenz<tlenz@vorgon.com>  wrote:
>>> Thanks to Andy Walls, found out why I kept loosing 1 tuner on a FusionHD7
>>> Dual express. Didn't know linux supported an auto sleep mode on the tuner
>>> chips and that it defaulted to on. Seems like it would be better to default
>>> to off.
>>
>> Regarding the general assertion that the power management should be
>> disabled by default, I disagree.  The power savings is considerable,
>> the time to bring the tuner out of sleep is negligible, and it's
>> generally good policy.
>>
>> Andy, do you have any actual details regarding the nature of the problem?
>
> Not really.  DViCo Fusion dual digital tv card.  One side of the card
> would yield "black video screen" when starting a digital capture
> sometime after (?) the VDR ATSC EPG plugin tried to suck off data.  I'm
> not sure there was a causal relationship.
>
> I hypothesized that one side of the dual-tuner was going stupid or one
> of the two channels used in the cx23885 was getting confused.  I was
> looking at how to narrow the problem down to cx23885 chip or xc5000
> tuner, or s5h14xx demod when I noted the power managment module option
> for the xc5000.  I suggested Tim try it.
>
> It was dumb luck that my guess actually made his symptoms go away.
>
> That's all I know.
>
> Regards,
> Andy
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


Guess it only reduced the problem. Today I looked at the guide and abc 
had no data. Checked with femon and the second tuner on the dual would 
not tune.

Re: cx5000 default auto sleep mode

[Timothy D. Lenz]

On 4/14/2010 10:40 AM, Devin Heitmueller wrote:
> On Wed, Apr 14, 2010 at 1:29 PM, Timothy D. Lenz<tlenz@vorgon.com>  wrote:
>> Thanks to Andy Walls, found out why I kept loosing 1 tuner on a FusionHD7
>> Dual express. Didn't know linux supported an auto sleep mode on the tuner
>> chips and that it defaulted to on. Seems like it would be better to default
>> to off. If someone wants an auto power down/sleep mode and their software
>> supports it, then let the program activate it. Seems people are more likely
>> to want the tuners to stay on then keep shutting down.
>>
>> Spent over a year trying to figure out why vdr would loose control of 1 of
>> the dual tuners when the atscepg pluging was used thinking it was a problem
>> with the plugin.
>
> The xc5000 power management changes I made were actually pretty
> thoroughly tested with that card (between myself and Michael Krufky,
> we tested it with just about every card that uses the tuner).  In
> fact, we uncovered several power management bugs in other drivers as a
> result of that effort.  It was a grueling effort that I spent almost
> three months working on.
>
> Generally I agree with the premise that functionality like this should
> only be enabled for boards it was tested with.  However, in this case
> it actually was pretty extensively tested with all the cards in
> question (including this one), and thus it was deemed safe to enable
> by default.  We've had cases in the past where developers exercised
> poor judgement and blindly turned on power management to make it work
> with one card, disregarding the possible breakage that could occur
> with other cards that use the same driver -- this was *not* one of
> those cases.
>
> If there is a bug, it should be pretty straightforward to fix provided
> it can be reproduced.
>
> Regarding the general assertion that the power management should be
> disabled by default, I disagree.  The power savings is considerable,
> the time to bring the tuner out of sleep is negligible, and it's
> generally good policy.
>
> Andy, do you have any actual details regarding the nature of the problem?
>
> Devin
>

I turned debug back on yesterday and it's been running since. No tuners 
have gone down yet, but here are some logs:
http://24.255.17.209:2400/vdr/logs/

When/if a tuner goes down again I'll put fresh logs up

Re: cx5000 default auto sleep mode

[Timothy D. Lenz]

On 4/14/2010 10:40 AM, Devin Heitmueller wrote:
> On Wed, Apr 14, 2010 at 1:29 PM, Timothy D. Lenz<tlenz@vorgon.com>  wrote:
>> Thanks to Andy Walls, found out why I kept loosing 1 tuner on a FusionHD7
>> Dual express. Didn't know linux supported an auto sleep mode on the tuner
>> chips and that it defaulted to on. Seems like it would be better to default
>> to off. If someone wants an auto power down/sleep mode and their software
>> supports it, then let the program activate it. Seems people are more likely
>> to want the tuners to stay on then keep shutting down.
>>
>> Spent over a year trying to figure out why vdr would loose control of 1 of
>> the dual tuners when the atscepg pluging was used thinking it was a problem
>> with the plugin.
>
> The xc5000 power management changes I made were actually pretty
> thoroughly tested with that card (between myself and Michael Krufky,
> we tested it with just about every card that uses the tuner).  In
> fact, we uncovered several power management bugs in other drivers as a
> result of that effort.  It was a grueling effort that I spent almost
> three months working on.
>
> Generally I agree with the premise that functionality like this should
> only be enabled for boards it was tested with.  However, in this case
> it actually was pretty extensively tested with all the cards in
> question (including this one), and thus it was deemed safe to enable
> by default.  We've had cases in the past where developers exercised
> poor judgement and blindly turned on power management to make it work
> with one card, disregarding the possible breakage that could occur
> with other cards that use the same driver -- this was *not* one of
> those cases.
>
> If there is a bug, it should be pretty straightforward to fix provided
> it can be reproduced.
>
> Regarding the general assertion that the power management should be
> disabled by default, I disagree.  The power savings is considerable,
> the time to bring the tuner out of sleep is negligible, and it's
> generally good policy.
>
> Andy, do you have any actual details regarding the nature of the problem?
>
> Devin
>

This morning a tuner was down. So the long runs it made, maybe where a 
fluke. I still have options xc5000 no_poweroff=1 debug=1. I posted new 
logs, to http://24.255.17.209:2400/vdr/logs/. The files with ".new" ext 
are the new ones with lognig when the tuner went down.

Re: cx5000 default auto sleep mode

[Timothy D. Lenz]

On 4/14/2010 10:40 AM, Devin Heitmueller wrote:
> On Wed, Apr 14, 2010 at 1:29 PM, Timothy D. Lenz<tlenz@vorgon.com>  wrote:
>> Thanks to Andy Walls, found out why I kept loosing 1 tuner on a FusionHD7
>> Dual express. Didn't know linux supported an auto sleep mode on the tuner
>> chips and that it defaulted to on. Seems like it would be better to default
>> to off. If someone wants an auto power down/sleep mode and their software
>> supports it, then let the program activate it. Seems people are more likely
>> to want the tuners to stay on then keep shutting down.
>>
>> Spent over a year trying to figure out why vdr would loose control of 1 of
>> the dual tuners when the atscepg pluging was used thinking it was a problem
>> with the plugin.
>
> The xc5000 power management changes I made were actually pretty
> thoroughly tested with that card (between myself and Michael Krufky,
> we tested it with just about every card that uses the tuner).  In
> fact, we uncovered several power management bugs in other drivers as a
> result of that effort.  It was a grueling effort that I spent almost
> three months working on.
>
> Generally I agree with the premise that functionality like this should
> only be enabled for boards it was tested with.  However, in this case
> it actually was pretty extensively tested with all the cards in
> question (including this one), and thus it was deemed safe to enable
> by default.  We've had cases in the past where developers exercised
> poor judgement and blindly turned on power management to make it work
> with one card, disregarding the possible breakage that could occur
> with other cards that use the same driver -- this was *not* one of
> those cases.
>
> If there is a bug, it should be pretty straightforward to fix provided
> it can be reproduced.
>
> Regarding the general assertion that the power management should be
> disabled by default, I disagree.  The power savings is considerable,
> the time to bring the tuner out of sleep is negligible, and it's
> generally good policy.
>
> Andy, do you have any actual details regarding the nature of the problem?
>
> Devin
>

Went down a second time today, so copied the logs over again. If what is 
needed to fix this isn't in those, will have to look else where.

Re: cx5000 default auto sleep mode

[Timothy D. Lenz]

On 4/14/2010 9:39 PM, Devin Heitmueller wrote:
> On Wed, Apr 14, 2010 at 11:44 PM, Andy Walls<awalls@md.metrocast.net>  wrote:
>> On Wed, 2010-04-14 at 13:40 -0400, Devin Heitmueller wrote:
>>> On Wed, Apr 14, 2010 at 1:29 PM, Timothy D. Lenz<tlenz@vorgon.com>  wrote:
>>>> Thanks to Andy Walls, found out why I kept loosing 1 tuner on a FusionHD7
>>>> Dual express. Didn't know linux supported an auto sleep mode on the tuner
>>>> chips and that it defaulted to on. Seems like it would be better to default
>>>> to off.
>>>
>>> Regarding the general assertion that the power management should be
>>> disabled by default, I disagree.  The power savings is considerable,
>>> the time to bring the tuner out of sleep is negligible, and it's
>>> generally good policy.
>>>
>>> Andy, do you have any actual details regarding the nature of the problem?
>>
>> Not really.  DViCo Fusion dual digital tv card.  One side of the card
>> would yield "black video screen" when starting a digital capture
>> sometime after (?) the VDR ATSC EPG plugin tried to suck off data.  I'm
>> not sure there was a causal relationship.
>>
>> I hypothesized that one side of the dual-tuner was going stupid or one
>> of the two channels used in the cx23885 was getting confused.  I was
>> looking at how to narrow the problem down to cx23885 chip or xc5000
>> tuner, or s5h14xx demod when I noted the power managment module option
>> for the xc5000.  I suggested Tim try it.
>>
>> It was dumb luck that my guess actually made his symptoms go away.
>>
>> That's all I know.
>
> We did have a similar issue with the PCTV 800i.  Basically, the GPIO
> definition was improperly defined for the xc5000 reset callback.  As a
> result, it was strobing the reset on both the xc5000 *and* the
> s5h1411, which would then cause the s5h1411's hardware state to not
> match the driver state.
>
> After multiple round trips with the hardware engineer at PCTV, I
> finally concluded that there actually wasn't a way to strobe the reset
> without screwing up the demodulator, which prompted me to disable the
> xc5000 reset callback (see cx88-cards:2944).
>
> My guess is that the reset GPIO definition for that board is wrong (a
> problem exposed by this change), or that it's resetting the s5h1411 as
> well.
>
> Devin
>

Are any of the logs usefull?

Re: cx5000 default auto sleep mode

[Timothy D. Lenz]

On 4/14/2010 9:39 PM, Devin Heitmueller wrote:
> On Wed, Apr 14, 2010 at 11:44 PM, Andy Walls<awalls@md.metrocast.net>  wrote:
>> On Wed, 2010-04-14 at 13:40 -0400, Devin Heitmueller wrote:
>>> On Wed, Apr 14, 2010 at 1:29 PM, Timothy D. Lenz<tlenz@vorgon.com>  wrote:
>>>> Thanks to Andy Walls, found out why I kept loosing 1 tuner on a FusionHD7
>>>> Dual express. Didn't know linux supported an auto sleep mode on the tuner
>>>> chips and that it defaulted to on. Seems like it would be better to default
>>>> to off.
>>>
>>> Regarding the general assertion that the power management should be
>>> disabled by default, I disagree.  The power savings is considerable,
>>> the time to bring the tuner out of sleep is negligible, and it's
>>> generally good policy.
>>>
>>> Andy, do you have any actual details regarding the nature of the problem?
>>
>> Not really.  DViCo Fusion dual digital tv card.  One side of the card
>> would yield "black video screen" when starting a digital capture
>> sometime after (?) the VDR ATSC EPG plugin tried to suck off data.  I'm
>> not sure there was a causal relationship.
>>
>> I hypothesized that one side of the dual-tuner was going stupid or one
>> of the two channels used in the cx23885 was getting confused.  I was
>> looking at how to narrow the problem down to cx23885 chip or xc5000
>> tuner, or s5h14xx demod when I noted the power managment module option
>> for the xc5000.  I suggested Tim try it.
>>
>> It was dumb luck that my guess actually made his symptoms go away.
>>
>> That's all I know.
>
> We did have a similar issue with the PCTV 800i.  Basically, the GPIO
> definition was improperly defined for the xc5000 reset callback.  As a
> result, it was strobing the reset on both the xc5000 *and* the
> s5h1411, which would then cause the s5h1411's hardware state to not
> match the driver state.
>
> After multiple round trips with the hardware engineer at PCTV, I
> finally concluded that there actually wasn't a way to strobe the reset
> without screwing up the demodulator, which prompted me to disable the
> xc5000 reset callback (see cx88-cards:2944).
>
> My guess is that the reset GPIO definition for that board is wrong (a
> problem exposed by this change), or that it's resetting the s5h1411 as
> well.
>
> Devin
>


I replaced the single tuner with the other FusionHD7 Dual Express I had 
so there was two of the same cards. Within a few hours Both tuners where 
down on the original card and even restarting drivers wouldn't bring it 
back. So I moved the new card to it's slot and put the single back in in 
case the old card was defective. I removed the no power off switch and 
went out for awhile. When I came back vdr had crashed which often 
happens when it tried to tune and there is no signal as in when a tuner 
goes down. For some reason vdr/xine/xorg/vdpau combo is very unstable 
when signal is poor or missing. I wish we could dump xine as it seems to 
be the cause. I never had a problem with vdr crashing when it rained 
knocking out signal when the nexus card was providing video.

Re: cx5000 default auto sleep mode

[Timothy D. Lenz]

Update, that card has now died. We bought 2 of those cards at the same 
time and the other has been working for a about 3 weeks with sleep mode 
disabled. I tried it with sleep mode enabled and ether vdr or xine 
crashed with in a few hours. But the version of xine I am still running 
on that computer is touchy about corrupt video streams and will crash 
when video starts pixeling or drops out totally for extended time. When 
I get a chance to update xine, I'll try turning auto sleep mode back on.

I have sent a message to Dvico, but I don't expect much since I've now 
had the card for more then a year. I should have just tried the other 
card way back then, but I thought sure it was a software/driver problem 
since making changes did at times effect how long it worked.

On 4/14/2010 9:39 PM, Devin Heitmueller wrote:
> On Wed, Apr 14, 2010 at 11:44 PM, Andy Walls<awalls@md.metrocast.net>  wrote:
>> On Wed, 2010-04-14 at 13:40 -0400, Devin Heitmueller wrote:
>>> On Wed, Apr 14, 2010 at 1:29 PM, Timothy D. Lenz<tlenz@vorgon.com>  wrote:
>>>> Thanks to Andy Walls, found out why I kept loosing 1 tuner on a FusionHD7
>>>> Dual express. Didn't know linux supported an auto sleep mode on the tuner
>>>> chips and that it defaulted to on. Seems like it would be better to default
>>>> to off.
>>>
>>> Regarding the general assertion that the power management should be
>>> disabled by default, I disagree.  The power savings is considerable,
>>> the time to bring the tuner out of sleep is negligible, and it's
>>> generally good policy.
>>>
>>> Andy, do you have any actual details regarding the nature of the problem?
>>
>> Not really.  DViCo Fusion dual digital tv card.  One side of the card
>> would yield "black video screen" when starting a digital capture
>> sometime after (?) the VDR ATSC EPG plugin tried to suck off data.  I'm
>> not sure there was a causal relationship.
>>
>> I hypothesized that one side of the dual-tuner was going stupid or one
>> of the two channels used in the cx23885 was getting confused.  I was
>> looking at how to narrow the problem down to cx23885 chip or xc5000
>> tuner, or s5h14xx demod when I noted the power managment module option
>> for the xc5000.  I suggested Tim try it.
>>
>> It was dumb luck that my guess actually made his symptoms go away.
>>
>> That's all I know.
>
> We did have a similar issue with the PCTV 800i.  Basically, the GPIO
> definition was improperly defined for the xc5000 reset callback.  As a
> result, it was strobing the reset on both the xc5000 *and* the
> s5h1411, which would then cause the s5h1411's hardware state to not
> match the driver state.
>
> After multiple round trips with the hardware engineer at PCTV, I
> finally concluded that there actually wasn't a way to strobe the reset
> without screwing up the demodulator, which prompted me to disable the
> xc5000 reset callback (see cx88-cards:2944).
>
> My guess is that the reset GPIO definition for that board is wrong (a
> problem exposed by this change), or that it's resetting the s5h1411 as
> well.
>
> Devin
>

Re: cx5000 default auto sleep mode

[Timothy D. Lenz]

I am seeing a problem again. driver I'm using is v4l-20100625. Don't 
know if the tuner card is dieing again or what. I had the sleep mode 
turned on and have been using the fusion dual along with a 1800. THe 
1800 shows as the 3rd device. Friday I had recordings setup on 2 
channels at the same time and one started recording the wrong channel 
with a lot of pixiling. When I used femon to try switching through 
tuners one tuner disapeared and then the other tuner switched to the 
channel the other was incorectly trying to record. Ended up restarting 
vdr and the drivers. Today I found that epg data was missing for several 
channels. When I used femon to switch tuners, the second tuner was no 
signal. I have turned the power save back off and restarted. Hopefully 
all 3 tuners will work tonight. This would be the second fusion HDTV7 to 
go bad and it is in a different computer running x63 instead of x32. So 
ether there is a bug in the drivers or theses are really crappy tuners.

On 5/10/2010 6:45 PM, Timothy D. Lenz wrote:
>
>
> On 4/14/2010 9:39 PM, Devin Heitmueller wrote:
>> On Wed, Apr 14, 2010 at 11:44 PM, Andy Walls<awalls@md.metrocast.net>
>> wrote:
>>> On Wed, 2010-04-14 at 13:40 -0400, Devin Heitmueller wrote:
>>>> On Wed, Apr 14, 2010 at 1:29 PM, Timothy D. Lenz<tlenz@vorgon.com>
>>>> wrote:
>>>>> Thanks to Andy Walls, found out why I kept loosing 1 tuner on a
>>>>> FusionHD7
>>>>> Dual express. Didn't know linux supported an auto sleep mode on the
>>>>> tuner
>>>>> chips and that it defaulted to on. Seems like it would be better to
>>>>> default
>>>>> to off.
>>>>
>>>> Regarding the general assertion that the power management should be
>>>> disabled by default, I disagree. The power savings is considerable,
>>>> the time to bring the tuner out of sleep is negligible, and it's
>>>> generally good policy.
>>>>
>>>> Andy, do you have any actual details regarding the nature of the
>>>> problem?
>>>
>>> Not really. DViCo Fusion dual digital tv card. One side of the card
>>> would yield "black video screen" when starting a digital capture
>>> sometime after (?) the VDR ATSC EPG plugin tried to suck off data. I'm
>>> not sure there was a causal relationship.
>>>
>>> I hypothesized that one side of the dual-tuner was going stupid or one
>>> of the two channels used in the cx23885 was getting confused. I was
>>> looking at how to narrow the problem down to cx23885 chip or xc5000
>>> tuner, or s5h14xx demod when I noted the power managment module option
>>> for the xc5000. I suggested Tim try it.
>>>
>>> It was dumb luck that my guess actually made his symptoms go away.
>>>
>>> That's all I know.
>>
>> We did have a similar issue with the PCTV 800i. Basically, the GPIO
>> definition was improperly defined for the xc5000 reset callback. As a
>> result, it was strobing the reset on both the xc5000 *and* the
>> s5h1411, which would then cause the s5h1411's hardware state to not
>> match the driver state.
>>
>> After multiple round trips with the hardware engineer at PCTV, I
>> finally concluded that there actually wasn't a way to strobe the reset
>> without screwing up the demodulator, which prompted me to disable the
>> xc5000 reset callback (see cx88-cards:2944).
>>
>> My guess is that the reset GPIO definition for that board is wrong (a
>> problem exposed by this change), or that it's resetting the s5h1411 as
>> well.
>>
>> Devin
>>
>
>
> I replaced the single tuner with the other FusionHD7 Dual Express I had
> so there was two of the same cards. Within a few hours Both tuners where
> down on the original card and even restarting drivers wouldn't bring it
> back. So I moved the new card to it's slot and put the single back in in
> case the old card was defective. I removed the no power off switch and
> went out for awhile. When I came back vdr had crashed which often
> happens when it tried to tune and there is no signal as in when a tuner
> goes down. For some reason vdr/xine/xorg/vdpau combo is very unstable
> when signal is poor or missing. I wish we could dump xine as it seems to
> be the cause. I never had a problem with vdr crashing when it rained
> knocking out signal when the nexus card was providing video.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>