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@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
