Re: PVR x50 corrupts ATSC 115 streams

Re: PVR x50 corrupts ATSC 115 streams

[Andreas]

Am Dienstag, 17. Februar 2009 21:19:45 schrieben Sie:
[...]
> So what does all of this indicate?  My original hunch was that it's a
> problem with the x50 hardware or driver (at least in combination with
> my motherboard).  I think I'm back to that conclusion.
>
> BTW, in my testing last night, I tried changing the PCI latency timer
> on the x50 cards.  I thought maybe it was holding off access to the
> 115 cards.  Changing that had no effect.

Just to let you know that you're not alone:
I had a simiilar problem with the combination of an AverMedia A180 and 
two Asus Falcon (they use the ivtv drivers and firmware). Whenever one 
of the Falcons was recording, I got blips and dropouts on the 
AverMedia. I chalked it off to a flaky mainboard and seperated the 
Falcons and the Avermedia in two different computers. A while later I 
got a new mainboard and additional ATSC tuner cards. As long as I had 
two of the ATSC tuner cards installed, the recordings were ok, except 
for an occasional dropout. But when I put a third ATSC tuner in, the 
recordings were barely watchable. After I put two ATSC tuners (2x 
Avermedia A180) in a different computer, they *all* are recording 
almost perfectly. Even a HVR-1600 card that I had dismissed as broken, 
delivers very good recordings in the other computer.

-- 
Gruß
Andreas

Re: PVR x50 corrupts ATSC 115 streams

[David Engel]

On Wed, Feb 18, 2009 at 04:41:40AM -0800, Andreas wrote:
> Am Dienstag, 17. Februar 2009 21:19:45 schrieben Sie:
> [...]
> > So what does all of this indicate?  My original hunch was that it's a
> > problem with the x50 hardware or driver (at least in combination with
> > my motherboard).  I think I'm back to that conclusion.
> >
> > BTW, in my testing last night, I tried changing the PCI latency timer
> > on the x50 cards.  I thought maybe it was holding off access to the
> > 115 cards.  Changing that had no effect.
> 
> Just to let you know that you're not alone:
> I had a simiilar problem with the combination of an AverMedia A180 and 
> two Asus Falcon (they use the ivtv drivers and firmware). Whenever one 
> of the Falcons was recording, I got blips and dropouts on the 
> AverMedia. I chalked it off to a flaky mainboard and seperated the 
> Falcons and the Avermedia in two different computers. A while later I 

That does sound like the same problem.

> got a new mainboard and additional ATSC tuner cards. As long as I had 
> two of the ATSC tuner cards installed, the recordings were ok, except 
> for an occasional dropout. But when I put a third ATSC tuner in, the 
> recordings were barely watchable. After I put two ATSC tuners (2x 

That sounds troubling since my current plan is to eventually remove
the PVR x50 cards altogether and use 3 ATCS 115s in the one system.

David
-- 
David Engel
david@istwok.net

Re: PVR x50 corrupts ATSC 115 streams

[CityK]

Andreas wrote:
> Just to let you know that you're not alone:
> I had a simiilar problem with the combination of an AverMedia A180 and 
> two Asus Falcon (they use the ivtv drivers and firmware). Whenever one 
> of the Falcons was recording, I got blips and dropouts on the 
> AverMedia. I chalked it off to a flaky mainboard and seperated the 
> Falcons and the Avermedia in two different computers. A while later I 
> got a new mainboard and additional ATSC tuner cards. As long as I had 
> two of the ATSC tuner cards installed, the recordings were ok, except 
> for an occasional dropout. But when I put a third ATSC tuner in, the 
> recordings were barely watchable. After I put two ATSC tuners (2x 
> Avermedia A180) in a different computer, they *all* are recording 
> almost perfectly. Even a HVR-1600 card that I had dismissed as broken, 
> delivers very good recordings in the other computer.

It should be noted that a common element here in the two cases is the
Nxt2004 (demod for both the A180 and 11x cards).

Re: PVR x50 corrupts ATSC 115 streams

[Andreas]

Am Mittwoch, 18. Februar 2009 19:37:23 schrieb CityK:
>
> It should be noted that a common element here in the two cases is the
> Nxt2004 (demod for both the A180 and 11x cards).

Yes, that's right. After testing different configurations, I believe 
that the problem with corrupted QAM recordings has more than one 
source:
* A driver problem (ivtv, maybe also nxt2004)
* Mainboards which are "dma-challenged" (one of mine definitely has 
probs in that department) 
* RF interference / general reception problems.

At the end of the day, it comes down to lots of testing and a bit of 
luck to find a combination of cards & mainboards which work nicely 
together.

-- 
Gruß
Andreas

PVR x50 corrupts ATSC 115 streams

[David Engel]

Hi,

My old, MythTV, master backend finally gave up the ghost this past
weekend.  The power supply or motherboard got bad enough there wa no
stability.  No big deal.  I was planning to replace that system soon
and had all of the parts ready anyway.

I moved the disks and tuner cards (2 Kworld ATSC 115s, 1 Hauppauge PVR
250 and 1 Hauppauge PVR 350) to the new system (AMD X2 3600 CPU and
Biostar TForce 550 motherboard).  Things went fairly smoothly and I
seemed to have full stability again for the first time in several
weeks.

Then, I started noticing frequent corruption in some of my claar QAM
recordings from the ATSC 115 cards.  When the corruption is present,
it occurs every few seconds -- a splotch of garbage in the picture
here, a stutter and a skipped frame there.  Sure enough, MythTV and
mplayer both report CRC, damage, splice and other errors when playing
the streams.

I finally determined the stream corruption happens if and only if one
of the PVR x50 cards is being used at the same time.  If only the ATSC
115s are used, there is no corruption.  As soon as either of the PVr
X50 is used with an ATSC 115, there is corruption.  I tested with the
stock drivers from the 2.6.27.17 kernel and from current Hg.  The
corruption happens with both sets of drivers.  FWIW, I haven't noticed
any corruption with the analog recordings from the PVR x50s.

Does anyone know what might be going on?  These very same tuner cards
worked fine in the old system (Intel P4 3.0GHz CPU and Abit IC7
motherboard) for close to two years.

David
-- 
David Engel
david@istwok.net

Re: PVR x50 corrupts ATSC 115 streams

[Steven Toth]

> Does anyone know what might be going on?  These very same tuner cards
> worked fine in the old system (Intel P4 3.0GHz CPU and Abit IC7
> motherboard) for close to two years.

Determine whether this is an RF issue, or a DMA corruption issue:

1. Check the RF SNR of the digital cards using femon, anything odd going on when 
the PVR250 is running? Does it fall out of lock or SNR dip dangerously low, 
bursts of BER's?

2. Move the two cards as far apart as possible in the slots in the system and 
repeat the test above, any better?

What happens?

- Steve

Re: PVR x50 corrupts ATSC 115 streams

[David Engel]

On Tue, Feb 17, 2009 at 11:05:40AM -0500, Steven Toth wrote:
>> Does anyone know what might be going on?  These very same tuner cards
>> worked fine in the old system (Intel P4 3.0GHz CPU and Abit IC7
>> motherboard) for close to two years.
>
> Determine whether this is an RF issue, or a DMA corruption issue:

Ahh, I didn't even think of RF.  I didn't have any RF problems in the
old system (that I know of) so that didn't even cross my mind.  I
actually was, and still am, more afraid of DMA issues, though.

> 1. Check the RF SNR of the digital cards using femon, anything odd going 
> on when the PVR250 is running? Does it fall out of lock or SNR dip 
> dangerously low, bursts of BER's?

Here are some 10 second captures from femon.  Card1 and Card2 are ATSC
115s.  Card4 and Card5 are PVR x50s.

Card1 recording by itself:

status SCVYL | signal fe90 | snr e4dc | ber 000000b8 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fea0 | snr e682 | ber 00000038 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe60 | snr e682 | ber 00000078 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe80 | snr e624 | ber 000000a0 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fea0 | snr e682 | ber 000000d8 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe70 | snr e598 | ber 00000140 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe90 | snr e654 | ber 00000078 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fea0 | snr e6b2 | ber 00000090 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe70 | snr e654 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe60 | snr e654 | ber 000000d8 | unc 00000000 | FE_HAS_LOCK

Card1 and Card4 recording:

status SCVYL | signal fe80 | snr e5c6 | ber 000000b8 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe90 | snr e682 | ber 00000100 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fea0 | snr e53a | ber 000000c8 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fea0 | snr e568 | ber 00000130 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fea0 | snr e624 | ber 000000b8 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe80 | snr e654 | ber 000000c0 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe20 | snr e6b2 | ber 000000c0 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fea0 | snr e682 | ber 00000028 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe60 | snr e654 | ber 000000d8 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe90 | snr e624 | ber 000000c8 | unc 00000000 | FE_HAS_LOCK

Card1 and Card5 recording:

status SCVYL | signal fe40 | snr e624 | ber 00000120 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe80 | snr e654 | ber 000000d0 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fea0 | snr e598 | ber 00000238 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe90 | snr e682 | ber 000000c8 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal feb0 | snr e654 | ber 00000068 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe90 | snr e654 | ber 00000118 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal feb0 | snr e6e0 | ber 00000038 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe50 | snr e4dc | ber 00000060 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe50 | snr e44e | ber 00000058 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fea0 | snr e5c6 | ber 000000d0 | unc 00000000 | FE_HAS_LOCK

Card2 recording by itself:

status SCVYL | signal fe20 | snr e53a | ber 00000130 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe20 | snr e53a | ber 000000b0 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe30 | snr e3c0 | ber 00000128 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe20 | snr e3c0 | ber 000000a8 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe40 | snr e568 | ber 00000060 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe00 | snr e4dc | ber 00000058 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe10 | snr e53a | ber 00000098 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fde0 | snr e4dc | ber 00000118 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe10 | snr e568 | ber 00000168 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fdf0 | snr e53a | ber 000001a0 | unc 00000000 | FE_HAS_LOCK

Card2 and Card4 recording:

status SCVYL | signal fe40 | snr e4ac | ber 000000d8 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe50 | snr e624 | ber 000001b8 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe70 | snr e598 | ber 000000a8 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe40 | snr e5c6 | ber 000000b0 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe40 | snr e53a | ber 000000d8 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe50 | snr e50a | ber 00000098 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe10 | snr e50a | ber 000000a0 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe10 | snr e598 | ber 000000b0 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe30 | snr e5f6 | ber 000000c0 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe60 | snr e568 | ber 00000180 | unc 00000000 | FE_HAS_LOCK

Card2 and Card5 recording

status SCVYL | signal fe70 | snr e4ac | ber 000000b8 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe50 | snr e598 | ber 00000190 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe40 | snr e598 | ber 00000118 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe80 | snr e5c6 | ber 00000008 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe50 | snr e568 | ber 000000c0 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe70 | snr e5c6 | ber 00000178 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe40 | snr e53a | ber 00000120 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe70 | snr e50a | ber 00000168 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe60 | snr e598 | ber 000000b0 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe40 | snr e5c6 | ber 000000f8 | unc 00000000 | FE_HAS_LOCK

I don't see anything significant there.

> 2. Move the two cards as far apart as possible in the slots in the system 
> and repeat the test above, any better?
>
> What happens?

This will require rmoving cards.  The old system had 5 PCI slots and I
had a small ethernet NIC between the pair of 115s and x50s.  The new
system only has 4 PCI slots so both pairs are in adjacent slots.  I'll
try pulling the x50s one at a time this evening when I get home.

David
-- 
David Engel
david@istwok.net

Re: PVR x50 corrupts ATSC 115 streams

[Steven Toth]

David Engel wrote:
> On Tue, Feb 17, 2009 at 11:05:40AM -0500, Steven Toth wrote:
>>> Does anyone know what might be going on?  These very same tuner cards
>>> worked fine in the old system (Intel P4 3.0GHz CPU and Abit IC7
>>> motherboard) for close to two years.
>> Determine whether this is an RF issue, or a DMA corruption issue:
> 
> Ahh, I didn't even think of RF.  I didn't have any RF problems in the
> old system (that I know of) so that didn't even cross my mind.  I
> actually was, and still am, more afraid of DMA issues, though.
> 
>> 1. Check the RF SNR of the digital cards using femon, anything odd going 
>> on when the PVR250 is running? Does it fall out of lock or SNR dip 
>> dangerously low, bursts of BER's?
> 
> Here are some 10 second captures from femon.  Card1 and Card2 are ATSC
> 115s.  Card4 and Card5 are PVR x50s.
> 
> Card1 recording by itself:
> 
> status SCVYL | signal fe90 | snr e4dc | ber 000000b8 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fea0 | snr e682 | ber 00000038 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe60 | snr e682 | ber 00000078 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe80 | snr e624 | ber 000000a0 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fea0 | snr e682 | ber 000000d8 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe70 | snr e598 | ber 00000140 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe90 | snr e654 | ber 00000078 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fea0 | snr e6b2 | ber 00000090 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe70 | snr e654 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe60 | snr e654 | ber 000000d8 | unc 00000000 | FE_HAS_LOCK
> 
> Card1 and Card4 recording:
> 
> status SCVYL | signal fe80 | snr e5c6 | ber 000000b8 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe90 | snr e682 | ber 00000100 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fea0 | snr e53a | ber 000000c8 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fea0 | snr e568 | ber 00000130 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fea0 | snr e624 | ber 000000b8 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe80 | snr e654 | ber 000000c0 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe20 | snr e6b2 | ber 000000c0 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fea0 | snr e682 | ber 00000028 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe60 | snr e654 | ber 000000d8 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe90 | snr e624 | ber 000000c8 | unc 00000000 | FE_HAS_LOCK
> 
> Card1 and Card5 recording:
> 
> status SCVYL | signal fe40 | snr e624 | ber 00000120 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe80 | snr e654 | ber 000000d0 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fea0 | snr e598 | ber 00000238 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe90 | snr e682 | ber 000000c8 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal feb0 | snr e654 | ber 00000068 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe90 | snr e654 | ber 00000118 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal feb0 | snr e6e0 | ber 00000038 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe50 | snr e4dc | ber 00000060 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe50 | snr e44e | ber 00000058 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fea0 | snr e5c6 | ber 000000d0 | unc 00000000 | FE_HAS_LOCK
> 
> Card2 recording by itself:
> 
> status SCVYL | signal fe20 | snr e53a | ber 00000130 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe20 | snr e53a | ber 000000b0 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe30 | snr e3c0 | ber 00000128 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe20 | snr e3c0 | ber 000000a8 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe40 | snr e568 | ber 00000060 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe00 | snr e4dc | ber 00000058 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe10 | snr e53a | ber 00000098 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fde0 | snr e4dc | ber 00000118 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe10 | snr e568 | ber 00000168 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fdf0 | snr e53a | ber 000001a0 | unc 00000000 | FE_HAS_LOCK
> 
> Card2 and Card4 recording:
> 
> status SCVYL | signal fe40 | snr e4ac | ber 000000d8 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe50 | snr e624 | ber 000001b8 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe70 | snr e598 | ber 000000a8 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe40 | snr e5c6 | ber 000000b0 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe40 | snr e53a | ber 000000d8 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe50 | snr e50a | ber 00000098 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe10 | snr e50a | ber 000000a0 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe10 | snr e598 | ber 000000b0 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe30 | snr e5f6 | ber 000000c0 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe60 | snr e568 | ber 00000180 | unc 00000000 | FE_HAS_LOCK
> 
> Card2 and Card5 recording
> 
> status SCVYL | signal fe70 | snr e4ac | ber 000000b8 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe50 | snr e598 | ber 00000190 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe40 | snr e598 | ber 00000118 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe80 | snr e5c6 | ber 00000008 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe50 | snr e568 | ber 000000c0 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe70 | snr e5c6 | ber 00000178 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe40 | snr e53a | ber 00000120 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe70 | snr e50a | ber 00000168 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe60 | snr e598 | ber 000000b0 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe40 | snr e5c6 | ber 000000f8 | unc 00000000 | FE_HAS_LOCK
> 
> I don't see anything significant there.

The BER looks buggy in this driver, assuming these readings are false.

Me neither, other than the dvb cards are reporting bit-errors. This feels like a 
driver bug not a generic card problem. If these ber's area real then this will 
account for your video issues, but that would be unrelated to the PVR250.

It'd personally remove the PVR250's and get your DVB statistics to report 0 for 
BER before continuing.

> 
>> 2. Move the two cards as far apart as possible in the slots in the system 
>> and repeat the test above, any better?
>>
>> What happens?
> 
> This will require rmoving cards.  The old system had 5 PCI slots and I
> had a small ethernet NIC between the pair of 115s and x50s.  The new
> system only has 4 PCI slots so both pairs are in adjacent slots.  I'll
> try pulling the x50s one at a time this evening when I get home.

Fold some thick cardboard and place it in between the PVR and the DVB boards, 
this will block some RF which may be coming from the encoder directly into your 
demod.

Does this help?

- Steve

Re: PVR x50 corrupts ATSC 115 streams

[David Engel]

On Tue, Feb 17, 2009 at 03:29:13PM -0500, Steven Toth wrote:
> David Engel wrote:
>> On Tue, Feb 17, 2009 at 11:05:40AM -0500, Steven Toth wrote:
>>>> Does anyone know what might be going on?  These very same tuner cards
>>>> worked fine in the old system (Intel P4 3.0GHz CPU and Abit IC7
>>>> motherboard) for close to two years.
>>> Determine whether this is an RF issue, or a DMA corruption issue:
>>
>> Ahh, I didn't even think of RF.  I didn't have any RF problems in the
>> old system (that I know of) so that didn't even cross my mind.  I
>> actually was, and still am, more afraid of DMA issues, though.
>>
>>> 1. Check the RF SNR of the digital cards using femon, anything odd 
>>> going on when the PVR250 is running? Does it fall out of lock or SNR 
>>> dip dangerously low, bursts of BER's?
>>
>> Here are some 10 second captures from femon.  Card1 and Card2 are ATSC
>> 115s.  Card4 and Card5 are PVR x50s.
>>
>> Card1 recording by itself:
>>
>> status SCVYL | signal fe90 | snr e4dc | ber 000000b8 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fea0 | snr e682 | ber 00000038 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe60 | snr e682 | ber 00000078 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe80 | snr e624 | ber 000000a0 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fea0 | snr e682 | ber 000000d8 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe70 | snr e598 | ber 00000140 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe90 | snr e654 | ber 00000078 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fea0 | snr e6b2 | ber 00000090 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe70 | snr e654 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe60 | snr e654 | ber 000000d8 | unc 00000000 | FE_HAS_LOCK
>>
>> Card1 and Card4 recording:
>>
>> status SCVYL | signal fe80 | snr e5c6 | ber 000000b8 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe90 | snr e682 | ber 00000100 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fea0 | snr e53a | ber 000000c8 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fea0 | snr e568 | ber 00000130 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fea0 | snr e624 | ber 000000b8 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe80 | snr e654 | ber 000000c0 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe20 | snr e6b2 | ber 000000c0 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fea0 | snr e682 | ber 00000028 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe60 | snr e654 | ber 000000d8 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe90 | snr e624 | ber 000000c8 | unc 00000000 | FE_HAS_LOCK
>>
>> Card1 and Card5 recording:
>>
>> status SCVYL | signal fe40 | snr e624 | ber 00000120 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe80 | snr e654 | ber 000000d0 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fea0 | snr e598 | ber 00000238 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe90 | snr e682 | ber 000000c8 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal feb0 | snr e654 | ber 00000068 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe90 | snr e654 | ber 00000118 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal feb0 | snr e6e0 | ber 00000038 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe50 | snr e4dc | ber 00000060 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe50 | snr e44e | ber 00000058 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fea0 | snr e5c6 | ber 000000d0 | unc 00000000 | FE_HAS_LOCK
>>
>> Card2 recording by itself:
>>
>> status SCVYL | signal fe20 | snr e53a | ber 00000130 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe20 | snr e53a | ber 000000b0 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe30 | snr e3c0 | ber 00000128 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe20 | snr e3c0 | ber 000000a8 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe40 | snr e568 | ber 00000060 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe00 | snr e4dc | ber 00000058 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe10 | snr e53a | ber 00000098 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fde0 | snr e4dc | ber 00000118 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe10 | snr e568 | ber 00000168 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fdf0 | snr e53a | ber 000001a0 | unc 00000000 | FE_HAS_LOCK
>>
>> Card2 and Card4 recording:
>>
>> status SCVYL | signal fe40 | snr e4ac | ber 000000d8 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe50 | snr e624 | ber 000001b8 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe70 | snr e598 | ber 000000a8 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe40 | snr e5c6 | ber 000000b0 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe40 | snr e53a | ber 000000d8 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe50 | snr e50a | ber 00000098 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe10 | snr e50a | ber 000000a0 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe10 | snr e598 | ber 000000b0 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe30 | snr e5f6 | ber 000000c0 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe60 | snr e568 | ber 00000180 | unc 00000000 | FE_HAS_LOCK
>>
>> Card2 and Card5 recording
>>
>> status SCVYL | signal fe70 | snr e4ac | ber 000000b8 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe50 | snr e598 | ber 00000190 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe40 | snr e598 | ber 00000118 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe80 | snr e5c6 | ber 00000008 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe50 | snr e568 | ber 000000c0 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe70 | snr e5c6 | ber 00000178 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe40 | snr e53a | ber 00000120 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe70 | snr e50a | ber 00000168 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe60 | snr e598 | ber 000000b0 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe40 | snr e5c6 | ber 000000f8 | unc 00000000 | FE_HAS_LOCK
>>
>> I don't see anything significant there.
>
> The BER looks buggy in this driver, assuming these readings are false.
>
> Me neither, other than the dvb cards are reporting bit-errors. This feels 
> like a driver bug not a generic card problem. If these ber's area real 
> then this will account for your video issues, but that would be unrelated 
> to the PVR250.
>
> It'd personally remove the PVR250's and get your DVB statistics to report 
> 0 for BER before continuing.

I have anohter system, with only an ATSC 115 and a video card.  It has
nearly identical numbers from femon as the system with the PVRs.

>>> 2. Move the two cards as far apart as possible in the slots in the 
>>> system and repeat the test above, any better?
>>>
>>> What happens?
>>
>> This will require rmoving cards.  The old system had 5 PCI slots and I
>> had a small ethernet NIC between the pair of 115s and x50s.  The new
>> system only has 4 PCI slots so both pairs are in adjacent slots.  I'll
>> try pulling the x50s one at a time this evening when I get home.
>
> Fold some thick cardboard and place it in between the PVR and the DVB 
> boards, this will block some RF which may be coming from the encoder 
> directly into your demod.

OK.

David
-- 
David Engel
david@istwok.net

Re: PVR x50 corrupts ATSC 115 streams

[Devin Heitmueller]

On Tue, Feb 17, 2009 at 3:56 PM, David Engel <david@istwok.net> wrote:
> I have anohter system, with only an ATSC 115 and a video card.  It has
> nearly identical numbers from femon as the system with the PVRs.

Didn't the PVR-250/350 have some sort of PCI DMA issues?  (I thought I
remember reading that  couple of years ago but I may be crazy).  If
so, then that wouldn't show up with femon, as the demod and tuner
would be capturing fine, but then the packets would never make it back
to the host.

<Idle speculation mode off>

Devin

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

Re: PVR x50 corrupts ATSC 115 streams

[Steven Toth]

Devin Heitmueller wrote:
> On Tue, Feb 17, 2009 at 3:56 PM, David Engel <david@istwok.net> wrote:
>> I have anohter system, with only an ATSC 115 and a video card.  It has
>> nearly identical numbers from femon as the system with the PVRs.
> 
> Didn't the PVR-250/350 have some sort of PCI DMA issues?  (I thought I
> remember reading that  couple of years ago but I may be crazy).  If
> so, then that wouldn't show up with femon, as the demod and tuner
> would be capturing fine, but then the packets would never make it back
> to the host.
> 
> <Idle speculation mode off>

The driver is probably buggy. Either its really reporting pre-viterbi errors OR 
it's reporting real post-viterbi errors - but in which case why aren't we also 
measuring uncorrected blocks?

Regardless of Davids actual current problem, this sounds like a secondary 
unrelated issue.

- Steve

Re: PVR x50 corrupts ATSC 115 streams

[Devin Heitmueller]

On Tue, Feb 17, 2009 at 5:29 PM, Steven Toth <stoth@linuxtv.org> wrote:
> The driver is probably buggy. Either its really reporting pre-viterbi errors
> OR it's reporting real post-viterbi errors - but in which case why aren't we
> also measuring uncorrected blocks?
>
> Regardless of Davids actual current problem, this sounds like a secondary
> unrelated issue.
>
> - Steve

Sorry, I didn't intend to suggest that the BER code isn't buggy - just
that I doubt it has any bearing on his actual problem since they occur
regardless of whether the other cards are running.

Devin

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

Re: PVR x50 corrupts ATSC 115 streams

[Steven Toth]

Devin Heitmueller wrote:
> On Tue, Feb 17, 2009 at 5:29 PM, Steven Toth <stoth@linuxtv.org> wrote:
>> The driver is probably buggy. Either its really reporting pre-viterbi errors
>> OR it's reporting real post-viterbi errors - but in which case why aren't we
>> also measuring uncorrected blocks?
>>
>> Regardless of Davids actual current problem, this sounds like a secondary
>> unrelated issue.
>>
>> - Steve
> 
> Sorry, I didn't intend to suggest that the BER code isn't buggy - just
> that I doubt it has any bearing on his actual problem since they occur
> regardless of whether the other cards are running.

Agreed, probably a secondary issue - which probably needs some attention regardless.

I don't follow kworld products so I don't pretend to know which demod they're 
using. I guess my question to the wider audience is, do people with this same 
demod on other cards experience similar BER issues.

- Steve

Re: PVR x50 corrupts ATSC 115 streams

[CityK]

Steven Toth wrote:
> Agreed, probably a secondary issue - which probably needs some
> attention regardless.
>
> I don't follow kworld products so I don't pretend to know which demod
> they're using. I guess my question to the wider audience is, do people
> with this same demod on other cards experience similar BER issues.

The KWorld 11x uses the Nxt2004 demod ... and "Zoinks!", upon checking,
I find that my single 11x card is now exhibiting BER too !   This is
something new to me, as previous femon output was always free of such
errors.

Re: PVR x50 corrupts ATSC 115 streams

[Steven Toth]

CityK wrote:
> Steven Toth wrote:
>> Agreed, probably a secondary issue - which probably needs some
>> attention regardless.
>>
>> I don't follow kworld products so I don't pretend to know which demod
>> they're using. I guess my question to the wider audience is, do people
>> with this same demod on other cards experience similar BER issues.
> 
> The KWorld 11x uses the Nxt2004 demod ... and "Zoinks!", upon checking,
> I find that my single 11x card is now exhibiting BER too !   This is
> something new to me, as previous femon output was always free of such
> errors.

The numbers are suspicious, (presumably) post-viterbi errors without UCB 
shouldn't happen, unless the driver isn't properly querying the demod stats. I'm 
not sure of the nxt2004's history so maybe this has always been an issue, maybe 
BER and UCB were never properly implemented? If I had a card I'd take a look. I 
don't so I can't help.

Clearly, I wouldn't trust that driver or its numbers right now.

- Steve

Re: PVR x50 corrupts ATSC 115 streams

[David Engel]

On Tue, Feb 17, 2009 at 03:29:13PM -0500, Steven Toth wrote:
> David Engel wrote:
>> On Tue, Feb 17, 2009 at 11:05:40AM -0500, Steven Toth wrote:
>>>> Does anyone know what might be going on?  These very same tuner cards
>>>> worked fine in the old system (Intel P4 3.0GHz CPU and Abit IC7
>>>> motherboard) for close to two years.
>>> Determine whether this is an RF issue, or a DMA corruption issue:
>>
>> Ahh, I didn't even think of RF.  I didn't have any RF problems in the
>> old system (that I know of) so that didn't even cross my mind.  I
>> actually was, and still am, more afraid of DMA issues, though.
>>
>>> 1. Check the RF SNR of the digital cards using femon, anything odd 
>>> going on when the PVR250 is running? Does it fall out of lock or SNR 
>>> dip dangerously low, bursts of BER's?
>>
>> Here are some 10 second captures from femon.  Card1 and Card2 are ATSC
>> 115s.  Card4 and Card5 are PVR x50s.
>>
>> Card1 recording by itself:
>>
>> status SCVYL | signal fe90 | snr e4dc | ber 000000b8 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fea0 | snr e682 | ber 00000038 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe60 | snr e682 | ber 00000078 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe80 | snr e624 | ber 000000a0 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fea0 | snr e682 | ber 000000d8 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe70 | snr e598 | ber 00000140 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe90 | snr e654 | ber 00000078 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fea0 | snr e6b2 | ber 00000090 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe70 | snr e654 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe60 | snr e654 | ber 000000d8 | unc 00000000 | FE_HAS_LOCK
>>
>> Card1 and Card4 recording:
>>
>> status SCVYL | signal fe80 | snr e5c6 | ber 000000b8 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe90 | snr e682 | ber 00000100 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fea0 | snr e53a | ber 000000c8 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fea0 | snr e568 | ber 00000130 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fea0 | snr e624 | ber 000000b8 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe80 | snr e654 | ber 000000c0 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe20 | snr e6b2 | ber 000000c0 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fea0 | snr e682 | ber 00000028 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe60 | snr e654 | ber 000000d8 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe90 | snr e624 | ber 000000c8 | unc 00000000 | FE_HAS_LOCK
>>
>> Card1 and Card5 recording:
>>
>> status SCVYL | signal fe40 | snr e624 | ber 00000120 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe80 | snr e654 | ber 000000d0 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fea0 | snr e598 | ber 00000238 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe90 | snr e682 | ber 000000c8 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal feb0 | snr e654 | ber 00000068 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe90 | snr e654 | ber 00000118 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal feb0 | snr e6e0 | ber 00000038 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe50 | snr e4dc | ber 00000060 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe50 | snr e44e | ber 00000058 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fea0 | snr e5c6 | ber 000000d0 | unc 00000000 | FE_HAS_LOCK
>>
>> Card2 recording by itself:
>>
>> status SCVYL | signal fe20 | snr e53a | ber 00000130 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe20 | snr e53a | ber 000000b0 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe30 | snr e3c0 | ber 00000128 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe20 | snr e3c0 | ber 000000a8 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe40 | snr e568 | ber 00000060 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe00 | snr e4dc | ber 00000058 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe10 | snr e53a | ber 00000098 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fde0 | snr e4dc | ber 00000118 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe10 | snr e568 | ber 00000168 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fdf0 | snr e53a | ber 000001a0 | unc 00000000 | FE_HAS_LOCK
>>
>> Card2 and Card4 recording:
>>
>> status SCVYL | signal fe40 | snr e4ac | ber 000000d8 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe50 | snr e624 | ber 000001b8 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe70 | snr e598 | ber 000000a8 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe40 | snr e5c6 | ber 000000b0 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe40 | snr e53a | ber 000000d8 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe50 | snr e50a | ber 00000098 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe10 | snr e50a | ber 000000a0 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe10 | snr e598 | ber 000000b0 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe30 | snr e5f6 | ber 000000c0 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe60 | snr e568 | ber 00000180 | unc 00000000 | FE_HAS_LOCK
>>
>> Card2 and Card5 recording
>>
>> status SCVYL | signal fe70 | snr e4ac | ber 000000b8 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe50 | snr e598 | ber 00000190 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe40 | snr e598 | ber 00000118 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe80 | snr e5c6 | ber 00000008 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe50 | snr e568 | ber 000000c0 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe70 | snr e5c6 | ber 00000178 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe40 | snr e53a | ber 00000120 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe70 | snr e50a | ber 00000168 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe60 | snr e598 | ber 000000b0 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe40 | snr e5c6 | ber 000000f8 | unc 00000000 | FE_HAS_LOCK
>>
>> I don't see anything significant there.
>
> The BER looks buggy in this driver, assuming these readings are false.
>
> Me neither, other than the dvb cards are reporting bit-errors. This feels 
> like a driver bug not a generic card problem. If these ber's area real 
> then this will account for your video issues, but that would be unrelated 
> to the PVR250.
>
> It'd personally remove the PVR250's and get your DVB statistics to report 
> 0 for BER before continuing.
>
>>
>>> 2. Move the two cards as far apart as possible in the slots in the 
>>> system and repeat the test above, any better?
>>>
>>> What happens?
>>
>> This will require rmoving cards.  The old system had 5 PCI slots and I
>> had a small ethernet NIC between the pair of 115s and x50s.  The new
>> system only has 4 PCI slots so both pairs are in adjacent slots.  I'll
>> try pulling the x50s one at a time this evening when I get home.
>
> Fold some thick cardboard and place it in between the PVR and the DVB 
> boards, this will block some RF which may be coming from the encoder 
> directly into your demod.
>
> Does this help?

Here's the configuration I started with:

slot 1: ATSC 115
slot 2: ATSC 115
slot 3: PVR 250
slot 4: PVR 350
slot 5: empty PCIe
slot 6: empty PCIe
slot 7: GF6200 PCIe

I reconfirmed the previous results - clean QAM recordings when no x50
in use and some corruption when either x50 in use.

I wedged a 33-page, 5x7 inch, motherboard manual between the 115 in
slot 2 and the 250 in slot 3.  There was no change.

I then removed the 250 from slot 3 leaving the 350 in slot 4.  There
was no change.

I then replaced the 350 in slot 4 with the 250.  There was no change.

During all of the above testing, the femon output was comparable to
waht I sent earlier.  BTW, I wonder if the ber counts are the result
of the massive signal spltting I am doing.  I have a powered,
aplifying, 4-way splitter in the mix.  Two of the outputs from the
4-way splitter are split again in two to feed the pairs of 115s and
x50s.  Also, a possible explanation for the unc always being 0 is the
clear QAM streams I am recording are all retransmissions of OTA
streams so I believe there is a lot of redundancy and error correction
information included in them.

Anyway, here is where things got weird until I eventually figured out
why.

I then removed the 250 from slot 4 leaving the 115s in slots 1 and 2.
The ber was through the roof and the recorded strams were filled with
errors and were barely playable at best.

I then removed the 115 from slot 2 leaving just one 115 in slot 1.
Same severe errors as above.  I moved the remaining 115 to the other
slots.  Same severe errors.

I put the x50s back, this time in slots 1 and 2 with the 115s in slots
3 and 4.  The results were back to what I had been getting -- clean
when no x50 in use and some corruption when either x50 in use.

I then put things back how I started, screwed everything back in and
closed the case.  

It then dawned on my why the 115-only results were so bad.  I had left
the 4-way splitter output used for the x50s unterminated.  Sure
enough, if I disconnected the x50s, I reproduced the severe errors.  I
didn't tear everything back apart to verify it, but I believe the 115s
would work fine by themselves if I terminated the cables properly.

So what does all of this indicate?  My original hunch was that it's a
problem with the x50 hardware or driver (at least in combination with
my motherboard).  I think I'm back to that conclusion.

BTW, in my testing last night, I tried changing the PCI latency timer
on the x50 cards.  I thought maybe it was holding off access to the
115 cards.  Changing that had no effect.

David
-- 
David Engel
david@istwok.net

Re: PVR x50 corrupts ATSC 115 streams

[Rudy Zijlstra]

> 
> It then dawned on my why the 115-only results were so bad.  I had left
> the 4-way splitter output used for the x50s unterminated.  Sure
> enough, if I disconnected the x50s, I reproduced the severe errors.  I
> didn't tear everything back apart to verify it, but I believe the 115s
> would work fine by themselves if I terminated the cables properly.
> 

Have you ever checked signal levels? May sound strange, but too high
signal levels also cause this type of problems.

> So what does all of this indicate?  My original hunch was that it's a
> problem with the x50 hardware or driver (at least in combination with
> my motherboard).  I think I'm back to that conclusion.
> 
> BTW, in my testing last night, I tried changing the PCI latency timer
> on the x50 cards.  I thought maybe it was holding off access to the
> 115 cards.  Changing that had no effect.
> 
> David
-- 
Cheers,


Rudy

Re: PVR x50 corrupts ATSC 115 streams

[David Engel]

On Wed, Feb 18, 2009 at 09:25:07AM +0100, Rudy Zijlstra wrote:
> > It then dawned on my why the 115-only results were so bad.  I had left
> > the 4-way splitter output used for the x50s unterminated.  Sure
> > enough, if I disconnected the x50s, I reproduced the severe errors.  I
> > didn't tear everything back apart to verify it, but I believe the 115s
> > would work fine by themselves if I terminated the cables properly.
> > 
> 
> Have you ever checked signal levels? May sound strange, but too high
> signal levels also cause this type of problems.

No.  On multiple occasions, though, I have tried adjusting the
amplification on the splitter from min to max and multiple settings in
between.  It never made any difference as far as I could see.

David
-- 
David Engel
david@istwok.net

Re: PVR x50 corrupts ATSC 115 streams

[Steven Toth]

> I then removed the 250 from slot 4 leaving the 115s in slots 1 and 2.
> The ber was through the roof and the recorded strams were filled with
> errors and were barely playable at best.

This ^^^^ is bad, you have something wrong with your feeds. They're probably 
over amp'd and your leaking RF like crazy.

Go back to basics, put the single unsplit and unamped feed into a single 115 and 
get that working reliably. Then, split (or amp) and try the second 115.

Try to work out what's causing BER to be > 0 and fix that first.

Personally, I wouldn't add the 250/350 back into the system until I had both 
115's running flawlessly with 0 BER and 0 UNC.

Chances are, the 250/350 will work correctly after this - unless the drivers 
really do have a DMA issue. It's too early to say given the BER/UNC issues 
you're seeing though.

- Steve

Re: PVR x50 corrupts ATSC 115 streams

[David Engel]

On Wed, Feb 18, 2009 at 09:56:13AM -0500, Steven Toth wrote:
>> I then removed the 250 from slot 4 leaving the 115s in slots 1 and 2.
>> The ber was through the roof and the recorded strams were filled with
>> errors and were barely playable at best.
>
> This ^^^^ is bad, you have something wrong with your feeds. They're 
> probably over amp'd and your leaking RF like crazy.
>
> Go back to basics, put the single unsplit and unamped feed into a single 
> 115 and get that working reliably. Then, split (or amp) and try the 
> second 115.
>
> Try to work out what's causing BER to be > 0 and fix that first.
>
> Personally, I wouldn't add the 250/350 back into the system until I had 
> both 115's running flawlessly with 0 BER and 0 UNC.
>
> Chances are, the 250/350 will work correctly after this - unless the 
> drivers really do have a DMA issue. It's too early to say given the 
> BER/UNC issues you're seeing though.

OK.  I've got another window this evening where I can do some testing
without disupting things too much.

David
-- 
David Engel
david@istwok.net

Re: PVR x50 corrupts ATSC 115 streams

[David Engel]

On Wed, Feb 18, 2009 at 09:34:22AM -0600, David Engel wrote:
> On Wed, Feb 18, 2009 at 09:56:13AM -0500, Steven Toth wrote:
> >> I then removed the 250 from slot 4 leaving the 115s in slots 1 and 2.
> >> The ber was through the roof and the recorded strams were filled with
> >> errors and were barely playable at best.
> >
> > This ^^^^ is bad, you have something wrong with your feeds. They're 
> > probably over amp'd and your leaking RF like crazy.
> >
> > Go back to basics, put the single unsplit and unamped feed into a single 
> > 115 and get that working reliably. Then, split (or amp) and try the 
> > second 115.
> >
> > Try to work out what's causing BER to be > 0 and fix that first.
> >
> > Personally, I wouldn't add the 250/350 back into the system until I had 
> > both 115's running flawlessly with 0 BER and 0 UNC.
> >
> > Chances are, the 250/350 will work correctly after this - unless the 
> > drivers really do have a DMA issue. It's too early to say given the 
> > BER/UNC issues you're seeing though.
> 
> OK.  I've got another window this evening where I can do some testing
> without disupting things too much.

Well, that was a frustrating, mostly waste of time!

I'll start with what worked.

I replaced the active, 4-way splitter with a passive one.  The BER
reported by the ATSC 115s increased by about 50-100% from what it
showed with the active splitter.  There were still no UNCs reported.
The 115 recordings followed the same pattern as before -- clean when
no x50 activity and some corruption with x50 activity.

FWIW, an analog TV connected off one of the splitter legs (via yet
another splitter) clearly showed a degraded signal with the passive,
4-way splitter.  The PVR x50s faired a little better.  The x50
recordings looked OK, but I really only checked those to make sure
something could be reocrded.

I replaced the passive, 4-way splitter with a passive, 2-way splitter.
This left only the 115s and x50s in the troublesome system connected.
Everything else in my clulttered computer room was left unconnected.
The BER reported by the ATSC 115s was about 25-50% higher than with
the active spllitter.  Again, there were no UNCs.  The same clean
vs. corrupted recordings pattern held.

Now, here is the stuff that didn't work and has me completely stumped.
I'm sure I'm missing something very stupid, but I don't know what.

The 115s absolutely refused to work if the x50s were not connected to
anything or were removed from the system altogether.  I tried with a
cable straight from the wall to each 115, one at a time, and with a
calbe from the wall with a single 2-way splitter to both 115s at the
same time.  I tried this with and without the x50s installed.  In all
cases, the 115s reported a BER at or near 7ff8 and UNC around 00ff and
FE_HAS_LOCK most of the time.  MythTV apparently never received
anything meaningful since it never wrote anything to the recording
file.

FWIW, I used a different 115 with that same motherboard for several
months up until about two weeks ago and with that same graphics card
for most of that time.  Like I said above, I've got to be missing
something very stupid here.  

BTW, during all of the testing without the active splitter, I had it
unplugged to make sure it wasn't contributing any extra RF noise.  I
won't have an opportunity to do any more testing until this weekend.

David
-- 
David Engel
david@istwok.net

Re: PVR x50 corrupts ATSC 115 streams

[Steven Toth]

> 
> FWIW, I used a different 115 with that same motherboard for several
> months up until about two weeks ago and with that same graphics card
> for most of that time.  Like I said above, I've got to be missing
> something very stupid here.  
> 
> BTW, during all of the testing without the active splitter, I had it
> unplugged to make sure it wasn't contributing any extra RF noise.  I
> won't have an opportunity to do any more testing until this weekend.

I think CityK confirmed that the nxt2004 driver statistics are probably bogus so 
I doubt you're going to get your 115's running with BER 0 regardless, which is 
unfortunate.

Assuming your original configuration was fine, the second part of the problem 
remains then.... is the DMA being screwed by the mix of boards.

I'm not sure I have an easy way for you to determine this, other than making 
sure everything is on it's own interrupt, going back to basics to a single 115 
and a single 250 and trying to isolate the changes step by step.

- Steve

Re: PVR x50 corrupts ATSC 115 streams

[CityK]

David Engel wrote:
> I'll start with what worked.
>
> ... [test results of BER and UNC under varying configurations ] ...
>   

Steven Toth wrote:
> I think CityK confirmed that the nxt2004 driver statistics are
> probably bogus so I doubt you're going to get your 115's running with
> BER 0 regardless, which is unfortunate. 

FWIW:

I'm not seeing any UNC, just the BER (which seems consistent to most,
but not all, of David's results with varying configurations).

Presently (and a situation that is unlikely to change), I don't have an
older kernel built/installed with which I can test/confirm, but from
memory, IIRC, I believe that it must have been from around ~2.6.22 that
I recall error free femon output.

Re: PVR x50 corrupts ATSC 115 streams

[David Engel]

On Sun, Feb 22, 2009 at 02:35:00PM -0500, CityK wrote:
> David Engel wrote:
> > I'll start with what worked.
> >
> > ... [test results of BER and UNC under varying configurations ] ...
> >   
> 
> Steven Toth wrote:
> > I think CityK confirmed that the nxt2004 driver statistics are
> > probably bogus so I doubt you're going to get your 115's running with
> > BER 0 regardless, which is unfortunate. 
> 
> FWIW:
> 
> I'm not seeing any UNC, just the BER (which seems consistent to most,
> but not all, of David's results with varying configurations).
> 
> Presently (and a situation that is unlikely to change), I don't have an
> older kernel built/installed with which I can test/confirm, but from
> memory, IIRC, I believe that it must have been from around ~2.6.22 that
> I recall error free femon output.

I've used 2.6.27.17 in most my testing, either with stock drivers or
with drivers from Mercurial.  I tried 2.6.26, .25 and .24 on Saturday,
but it made no difference.  After seeing this message, I tried 2.6.22
and .21 yesterday (Sunday).  Again, it made no difference.  I think
the ATSC 115s are just going to always report at least some level of
BER.

Anyway, here are the other results of more testing over the weekend.

I tried an ATSC 115 with a PVR 250 in my desktop system.  Like with my
MythTV backend, the 115 digital recordings were slightly corrupted
when the x50 was active.  The corruption appeared to be a little less
frequent, though.  Instead of some corruption occuring every couple of
seconds, it was more like every 4 or 5 seconds.

Both my desktop and current MythTV backend are AMD systems with Nvidia
chipsets.  My old backend, which didn't exhibit the corruption
problem, was a P4 system with an Intel chipset.

I can't get any 115 to work in my current backend without an x50
installed and connected to cable.  I tried a single 115 is every slot.
I tried older kernels.  I tried multiple 115s in combinations.  I
tried a 115 with an Audigy sound card I had.  In every case, the 115
reports excessive BER and UNC and capture of any digital stream is
almost impossible.  The 115s will behave this way until I install at
least one x50 card and connect it the cable.

I even tried the same 115 I had used not more than a month ago with
the same motherboard and graphics card as my desktop.  Only the case,
power suuply and disks are now different.  Could there be some kind of
short on the motherboard or case that could case this behavior?

I remembered I had a DVICO FusionHDTV5 lying around.  I don't use that
card much because, in my past experience, the cx88 driver doesn't play
as well with the ivtv driver as the saa7134 driver.  See below for an
example (*).

The HDTV5 does report 0 for bER:

status SCVYL | signal fd43 | snr 22a0 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fcde | snr 2292 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fd87 | snr 22b7 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fd65 | snr 22a4 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fd65 | snr 22a4 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fd43 | snr 2292 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fda9 | snr 22c5 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe34 | snr 22c1 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fe11 | snr 22bc | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status SCVYL | signal fda9 | snr 22a0 | ber 00000000 | unc 00000000 | FE_HAS_LOCK

In addition, the HDTV5 does not have any corruption when the x50s are
active.  I ran one test with the HDTV5, one 115 and two x50s.  The
HDTV5 didn't show corruption while the 115 did.  To be sure it wasn't
the content, I stopped the digital recordings and restarted them so
the cards would be swapped.  The corruption stayed with the 115.

To summarize, I have two problems.

First, the 115s show corruption when an x50 is active.  This occurs on
two differnt systems with Nvidia chipsets, but did not occur in a
system with an Intel chipset.  An HDTV in the same system does not
show the corruption problem.

Second, the 115s apparently can't receive a clean signal unless theer
is a x50 installed and connected.

(*) About half the time I boot with the HDTV5 and x50 cards, the x50
tuners don't work.  The x50s will only record static until I manually
unload and reload the tuner modules.

David
-- 
David Engel
david@istwok.net

Re: PVR x50 corrupts ATSC 115 streams

[Steven Toth]

David Engel wrote:
> On Sun, Feb 22, 2009 at 02:35:00PM -0500, CityK wrote:
>> David Engel wrote:
>>> I'll start with what worked.
>>>
>>> ... [test results of BER and UNC under varying configurations ] ...
>>>   
>> Steven Toth wrote:
>>> I think CityK confirmed that the nxt2004 driver statistics are
>>> probably bogus so I doubt you're going to get your 115's running with
>>> BER 0 regardless, which is unfortunate. 
>> FWIW:
>>
>> I'm not seeing any UNC, just the BER (which seems consistent to most,
>> but not all, of David's results with varying configurations).
>>
>> Presently (and a situation that is unlikely to change), I don't have an
>> older kernel built/installed with which I can test/confirm, but from
>> memory, IIRC, I believe that it must have been from around ~2.6.22 that
>> I recall error free femon output.
> 
> I've used 2.6.27.17 in most my testing, either with stock drivers or
> with drivers from Mercurial.  I tried 2.6.26, .25 and .24 on Saturday,
> but it made no difference.  After seeing this message, I tried 2.6.22
> and .21 yesterday (Sunday).  Again, it made no difference.  I think
> the ATSC 115s are just going to always report at least some level of
> BER.
> 
> Anyway, here are the other results of more testing over the weekend.
> 
> I tried an ATSC 115 with a PVR 250 in my desktop system.  Like with my
> MythTV backend, the 115 digital recordings were slightly corrupted
> when the x50 was active.  The corruption appeared to be a little less
> frequent, though.  Instead of some corruption occuring every couple of
> seconds, it was more like every 4 or 5 seconds.
> 
> Both my desktop and current MythTV backend are AMD systems with Nvidia
> chipsets.  My old backend, which didn't exhibit the corruption
> problem, was a P4 system with an Intel chipset.
> 
> I can't get any 115 to work in my current backend without an x50
> installed and connected to cable.  I tried a single 115 is every slot.
> I tried older kernels.  I tried multiple 115s in combinations.  I
> tried a 115 with an Audigy sound card I had.  In every case, the 115
> reports excessive BER and UNC and capture of any digital stream is
> almost impossible.  The 115s will behave this way until I install at
> least one x50 card and connect it the cable.
> 
> I even tried the same 115 I had used not more than a month ago with
> the same motherboard and graphics card as my desktop.  Only the case,
> power suuply and disks are now different.  Could there be some kind of
> short on the motherboard or case that could case this behavior?
> 
> I remembered I had a DVICO FusionHDTV5 lying around.  I don't use that
> card much because, in my past experience, the cx88 driver doesn't play
> as well with the ivtv driver as the saa7134 driver.  See below for an
> example (*).
> 
> The HDTV5 does report 0 for bER:
> 
> status SCVYL | signal fd43 | snr 22a0 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fcde | snr 2292 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fd87 | snr 22b7 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fd65 | snr 22a4 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fd65 | snr 22a4 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fd43 | snr 2292 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fda9 | snr 22c5 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe34 | snr 22c1 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fe11 | snr 22bc | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status SCVYL | signal fda9 | snr 22a0 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> 
> In addition, the HDTV5 does not have any corruption when the x50s are
> active.  I ran one test with the HDTV5, one 115 and two x50s.  The
> HDTV5 didn't show corruption while the 115 did.  To be sure it wasn't
> the content, I stopped the digital recordings and restarted them so
> the cards would be swapped.  The corruption stayed with the 115.
> 
> To summarize, I have two problems.
> 
> First, the 115s show corruption when an x50 is active.  This occurs on
> two differnt systems with Nvidia chipsets, but did not occur in a
> system with an Intel chipset.  An HDTV in the same system does not
> show the corruption problem.
> 
> Second, the 115s apparently can't receive a clean signal unless theer
> is a x50 installed and connected.
> 
> (*) About half the time I boot with the HDTV5 and x50 cards, the x50
> tuners don't work.  The x50s will only record static until I manually
> unload and reload the tuner modules.

"In every case, the 115
reports excessive BER and UNC and capture of any digital stream is
almost impossible."

If this this is true then it's an RF noise issue, not a DMA issue. The encoders 
are generating noise that's finding it's way into your DVB frontends.

Try running the DVB + 250 side by side but disconnect the antenna input to the 
250 once it's running. (Ie noise is boing couple into the antenna cable)

Do you still see high BER and high UNC?

- Steve

Re: PVR x50 corrupts ATSC 115 streams

[David Engel]

On Mon, Feb 23, 2009 at 02:06:56PM -0500, Steven Toth wrote:
> David Engel wrote:
>> On Sun, Feb 22, 2009 at 02:35:00PM -0500, CityK wrote:
>>> David Engel wrote:
>>>> I'll start with what worked.
>>>>
>>>> ... [test results of BER and UNC under varying configurations ] ...
>>>>   
>>> Steven Toth wrote:
>>>> I think CityK confirmed that the nxt2004 driver statistics are
>>>> probably bogus so I doubt you're going to get your 115's running with
>>>> BER 0 regardless, which is unfortunate. 
>>> FWIW:
>>>
>>> I'm not seeing any UNC, just the BER (which seems consistent to most,
>>> but not all, of David's results with varying configurations).
>>>
>>> Presently (and a situation that is unlikely to change), I don't have an
>>> older kernel built/installed with which I can test/confirm, but from
>>> memory, IIRC, I believe that it must have been from around ~2.6.22 that
>>> I recall error free femon output.
>>
>> I've used 2.6.27.17 in most my testing, either with stock drivers or
>> with drivers from Mercurial.  I tried 2.6.26, .25 and .24 on Saturday,
>> but it made no difference.  After seeing this message, I tried 2.6.22
>> and .21 yesterday (Sunday).  Again, it made no difference.  I think
>> the ATSC 115s are just going to always report at least some level of
>> BER.
>>
>> Anyway, here are the other results of more testing over the weekend.
>>
>> I tried an ATSC 115 with a PVR 250 in my desktop system.  Like with my
>> MythTV backend, the 115 digital recordings were slightly corrupted
>> when the x50 was active.  The corruption appeared to be a little less
>> frequent, though.  Instead of some corruption occuring every couple of
>> seconds, it was more like every 4 or 5 seconds.
>>
>> Both my desktop and current MythTV backend are AMD systems with Nvidia
>> chipsets.  My old backend, which didn't exhibit the corruption
>> problem, was a P4 system with an Intel chipset.
>>
>> I can't get any 115 to work in my current backend without an x50
>> installed and connected to cable.  I tried a single 115 is every slot.
>> I tried older kernels.  I tried multiple 115s in combinations.  I
>> tried a 115 with an Audigy sound card I had.  In every case, the 115
>> reports excessive BER and UNC and capture of any digital stream is
>> almost impossible.  The 115s will behave this way until I install at
>> least one x50 card and connect it the cable.
>>
>> I even tried the same 115 I had used not more than a month ago with
>> the same motherboard and graphics card as my desktop.  Only the case,
>> power suuply and disks are now different.  Could there be some kind of
>> short on the motherboard or case that could case this behavior?
>>
>> I remembered I had a DVICO FusionHDTV5 lying around.  I don't use that
>> card much because, in my past experience, the cx88 driver doesn't play
>> as well with the ivtv driver as the saa7134 driver.  See below for an
>> example (*).
>>
>> The HDTV5 does report 0 for bER:
>>
>> status SCVYL | signal fd43 | snr 22a0 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fcde | snr 2292 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fd87 | snr 22b7 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fd65 | snr 22a4 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fd65 | snr 22a4 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fd43 | snr 2292 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fda9 | snr 22c5 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe34 | snr 22c1 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fe11 | snr 22bc | ber 00000000 | unc 00000000 | FE_HAS_LOCK
>> status SCVYL | signal fda9 | snr 22a0 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
>>
>> In addition, the HDTV5 does not have any corruption when the x50s are
>> active.  I ran one test with the HDTV5, one 115 and two x50s.  The
>> HDTV5 didn't show corruption while the 115 did.  To be sure it wasn't
>> the content, I stopped the digital recordings and restarted them so
>> the cards would be swapped.  The corruption stayed with the 115.
>>
>> To summarize, I have two problems.
>>
>> First, the 115s show corruption when an x50 is active.  This occurs on
>> two differnt systems with Nvidia chipsets, but did not occur in a
>> system with an Intel chipset.  An HDTV in the same system does not
>> show the corruption problem.
>>
>> Second, the 115s apparently can't receive a clean signal unless theer
>> is a x50 installed and connected.
>>
>> (*) About half the time I boot with the HDTV5 and x50 cards, the x50
>> tuners don't work.  The x50s will only record static until I manually
>> unload and reload the tuner modules.
>
> "In every case, the 115
> reports excessive BER and UNC and capture of any digital stream is
> almost impossible."
>
> If this this is true then it's an RF noise issue, not a DMA issue. The 
> encoders are generating noise that's finding it's way into your DVB 
> frontends.
>
> Try running the DVB + 250 side by side but disconnect the antenna input 
> to the 250 once it's running. (Ie noise is boing couple into the antenna 
> cable)
>
> Do you still see high BER and high UNC?

I won't be able to try anything more until tomorrow evening.

I think you're missing something, though, Steven.  The "In every case"
was in reference to "without an x50 installed and connected to cable".
That includes the cases where there are no x50s installed at all.  How
can the x50 encoder be causing noise when it's not even installed?

To help clarify things, here is a rephrasing of this weekend's results:

  115 by itself = excessive BER
  115 with one or two other 115s = excessive BER
  115 with HDTV5 = excessive BER
  115 with Audigy = excessive BER
  115 with x50 and x50 not connected and x50 not encoding = excessive BER
  115 with x50 and x50 connected and x50 not encoding = low BER and no corruption
  115 with x50 and x50 connected and x50 encoding = low BER and minor corruption
  HDTV5 with anything = 0 BER and no corruption

David
-- 
David Engel
david@istwok.net

Re: PVR x50 corrupts ATSC 115 streams

[Steven Toth]

>> Do you still see high BER and high UNC?
> 
> I won't be able to try anything more until tomorrow evening.
> 
> I think you're missing something, though, Steven.  The "In every case"
> was in reference to "without an x50 installed and connected to cable".
> That includes the cases where there are no x50s installed at all.  How
> can the x50 encoder be causing noise when it's not even installed?

I'm out of time. Someone else want to jump in and assist?

- Steve

Re: PVR x50 corrupts ATSC 115 streams

[Devin Heitmueller]

On Mon, Feb 23, 2009 at 4:53 PM, Steven Toth <stoth@linuxtv.org> wrote:
>>> Do you still see high BER and high UNC?
>>
>> I won't be able to try anything more until tomorrow evening.
>>
>> I think you're missing something, though, Steven.  The "In every case"
>> was in reference to "without an x50 installed and connected to cable".
>> That includes the cases where there are no x50s installed at all.  How
>> can the x50 encoder be causing noise when it's not even installed?
>
> I'm out of time. Someone else want to jump in and assist?
>
> - Steve

Given David's last summary of results, it seems like the BER indicator
for that particular demodulator is completely unreliable (which isn't
terribly surprising).  If you take that out of the equation, it seems
like the only time there is corruption is when both the 115 and the
x50 is encoding.

So, it seems like we're back to either an RF issue or a DMA issue.
Did David attempt to move the cards farther apart, or put any sort of
shielding between the two cards?  If the shielding has any effect,
then we're probably talking about an RF issue.  If it had no effect,
then we are probably talking about a DMA issue.

Either way, it seems like we should stop talking about the BER as any
sort of indicator of a problem.

Devin


-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

Re: PVR x50 corrupts ATSC 115 streams

[David Engel]

On Mon, Feb 23, 2009 at 05:03:28PM -0500, Devin Heitmueller wrote:
> On Mon, Feb 23, 2009 at 4:53 PM, Steven Toth <stoth@linuxtv.org> wrote:
> > I'm out of time. Someone else want to jump in and assist?
> >
> > - Steve
> 
> Given David's last summary of results, it seems like the BER indicator
> for that particular demodulator is completely unreliable (which isn't
> terribly surprising).  If you take that out of the equation, it seems
> like the only time there is corruption is when both the 115 and the
> x50 is encoding.

The BER isn't totally unreliable.  Yes, when it's low, it does seem to
be meaningless.  However, when it's high, as in my recent attempts to
try a 115 by itself, it indicates that nothing will work.

> So, it seems like we're back to either an RF issue or a DMA issue.
> Did David attempt to move the cards farther apart, or put any sort of
> shielding between the two cards?  If the shielding has any effect,
> then we're probably talking about an RF issue.  If it had no effect,
> then we are probably talking about a DMA issue.

I tried separating the cards as far as possible.  I tried shoving a
small manual (~1/8 inch thick) between the 115 cards and the x50 cards
to shield them.  Neither action had any effect.  Also, one of the
tests I tried yesterday had the HDTV5 between the 115 and the x50s.
The 115 showed corruption and the HDTV5 didn't even though it was
nearest to the x50s.

> Either way, it seems like we should stop talking about the BER as any
> sort of indicator of a problem.

David
-- 
David Engel
david@istwok.net

Re: PVR x50 corrupts ATSC 115 streams

[Devin Heitmueller]

On Mon, Feb 23, 2009 at 5:48 PM, David Engel <david@istwok.net> wrote:
> The BER isn't totally unreliable.  Yes, when it's low, it does seem to
> be meaningless.  However, when it's high, as in my recent attempts to
> try a 115 by itself, it indicates that nothing will work.

Maybe I am missing something.  Your last summary said you had a high
BER even the 115 is the only card in the system.  That would lead me
to believe that it's always screwed up.

> I tried separating the cards as far as possible.  I tried shoving a
> small manual (~1/8 inch thick) between the 115 cards and the x50 cards
> to shield them.  Neither action had any effect.  Also, one of the
> tests I tried yesterday had the HDTV5 between the 115 and the x50s.
> The 115 showed corruption and the HDTV5 didn't even though it was
> nearest to the x50s.

Different cards interfere with each other in different ways (based on
things such as the PCB layout).  The fact that the HDTV5 doesn't have
issues doesn't really mean *anything*.  Same goes for the fact that
it's BER indicator is always zero.  That could just as easily indicate
that the BER checking is properly implemented for that particular
demod.

Anyway, I don't have the card and all my suggestions were very
general.  If you can't find a developer with the card willing to debug
the issue then you're probably SOL.

Devin

-- 
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

Re: PVR x50 corrupts ATSC 115 streams

[pat-lkml]

Devin Heitmueller wrote:
> On Mon, Feb 23, 2009 at 5:48 PM, David Engel <david@istwok.net> wrote:
>> The BER isn't totally unreliable.  Yes, when it's low, it does seem to
>> be meaningless.  However, when it's high, as in my recent attempts to
>> try a 115 by itself, it indicates that nothing will work.
> 
> Maybe I am missing something.  Your last summary said you had a high
> BER even the 115 is the only card in the system.  That would lead me
> to believe that it's always screwed up.
> 
>> I tried separating the cards as far as possible.  I tried shoving a
>> small manual (~1/8 inch thick) between the 115 cards and the x50 cards
>> to shield them.  Neither action had any effect.  Also, one of the
>> tests I tried yesterday had the HDTV5 between the 115 and the x50s.
>> The 115 showed corruption and the HDTV5 didn't even though it was
>> nearest to the x50s.
> 
> Different cards interfere with each other in different ways (based on
> things such as the PCB layout).  The fact that the HDTV5 doesn't have
> issues doesn't really mean *anything*.  Same goes for the fact that
> it's BER indicator is always zero.  That could just as easily indicate
> that the BER checking is properly implemented for that particular
> demod.
> 
> Anyway, I don't have the card and all my suggestions were very
> general.  If you can't find a developer with the card willing to debug
> the issue then you're probably SOL.
> 
> Devin
> 
To chime in late in this conversation...

David said that the original system died with these cards in it.  And that
the cards don't seem to work without another device in the system hooked up
to the same splitter.  This makes it sound like the shielding pin on these
cards has been disconnected some how, and when the other device (pvrx50 in
this case) is hooked up, the shielding is electrically connected through the
bus somehow.  When the pvrs start recording, they likely change the load on
the shielding in some way that causes interference for the 115 cards.  

David, do you happen to have another device you could test in the system with
the 2 115s, without the x50s?  If this case works fine, it REALLY points to
something being wrong with your 115s electrically.  I'd try ohming out the
shielding trace to the connector on the back of the board, if possible.

Pat Erley

Re: PVR x50 corrupts ATSC 115 streams

[David Engel]

On Mon, Feb 23, 2009 at 05:58:54PM -0500, Devin Heitmueller wrote:
> On Mon, Feb 23, 2009 at 5:48 PM, David Engel <david@istwok.net> wrote:
> > The BER isn't totally unreliable.  Yes, when it's low, it does seem to
> > be meaningless.  However, when it's high, as in my recent attempts to
> > try a 115 by itself, it indicates that nothing will work.
> 
> Maybe I am missing something.  Your last summary said you had a high
> BER even the 115 is the only card in the system.  That would lead me
> to believe that it's always screwed up.

I should have been clearer about BER when the 115 doesn't work at all.
In those cases, BER is something like 00007ff8 and UNC is 000000ff.
In the cases where the 115 does work (with or without corruption), the
BER is typically less than 00000200 and UNC is always 00000000.

> Anyway, I don't have the card and all my suggestions were very
> general.  If you can't find a developer with the card willing to debug
> the issue then you're probably SOL.

FWIW, my expectation was to be SOL.  I'm very appreciative of all the
help I've received so far.

On Mon, Feb 23, 2009 at 08:38:16PM -0500, pat-lkml wrote:
> David said that the original system died with these cards in it.  And that
> the cards don't seem to work without another device in the system hooked up
> to the same splitter.  This makes it sound like the shielding pin on these
> cards has been disconnected some how, and when the other device (pvrx50 in
> this case) is hooked up, the shielding is electrically connected through the
> bus somehow.  When the pvrs start recording, they likely change the load on
> the shielding in some way that causes interference for the 115 cards.  
> 
> David, do you happen to have another device you could test in the system with
> the 2 115s, without the x50s?  If this case works fine, it REALLY points to
> something being wrong with your 115s electrically.  I'd try ohming out the
> shielding trace to the connector on the back of the board, if possible.

Yes, I have a Fusion HDTV5.  I tried the HDTV5 with one of the 115s
and the 115 did not work in that configuration.  How do I identify the
shielding trace?  If it helps, Newegg has decent pictures of the card
at

http://www.newegg.com/Product/ShowImage.aspx?Image=15-260-005-17.jpg%2c15-260-005-10.jpg%2c15-260-005-11.jpg%2c15-260-005-12.jpg%2c15-260-005-13.jpg%2c15-260-005-14.jpg%2c15-260-005-15.jpg%2c15-260-005-16.jpg&S7ImageFlag=0&WaterMark=1&Item=N82E16815260005&Depa=0&Description=KWORLD PlusTV HD PCI-115 TV Tuner ATSC 115

or 

http://tinyurl.com/amkk6e

On Mon, Feb 23, 2009 at 07:05:17PM -0500, Andy Walls wrote:
> On Mon, 2009-02-23 at 14:10 -0600, David Engel wrote:
> > To help clarify things, here is a rephrasing of this weekend's results:
> > 
> >   115 by itself = excessive BER
> >   115 with one or two other 115s = excessive BER
> >   115 with HDTV5 = excessive BER
> >   115 with Audigy = excessive BER
> >   115 with x50 and x50 not connected and x50 not encoding = excessive BER
> >   115 with x50 and x50 connected and x50 not encoding = low BER and no corruption
> >   115 with x50 and x50 connected and x50 encoding = low BER and minor corruption
> >   HDTV5 with anything = 0 BER and no corruption
> 
> David,
> 
> I cannot reconcile the two lines with HDTV5 as they seem to say "x" and
> "not x".

The result is for the first card listed on the line.

So, for "HDTV5 with anything = 0 BER and no corruption", the HDTV5 had
0 BER and showed no corruption.  IOW, the HDTV5 always worked no
matter what configuration I tried it in.

For "115 with HDTV5 = excessive BER", the 115 had BER of 00007ff8 when
it was tried with the HDTV5 and nothing else.

> Aside from that, here are my thoughts:
> 
> If it's not one thing, then it's two.  :)  It could be that you have
> both both an Electro-Magnetic Interference (EMI) problem and a buffer
> handling problem.  You need to work the solution to one while you have
> mitigated or controlled the effects of the other.

I believe you are right about there being two problems.  Of the two, I
consider the EMI problem more important since I'll eventually retire
the x50s and just use the 3 115s in the case.

> 1. You have indications that hooking up the PVR-x50 mitigates EMI or RF
> problems, but you don't know why.  So without knowing details about your
> signal distribution plant, I'll make some guesses as to what might be
> going on:
> 
> a. The unsplit signal is overdriving the frontend of the 115.  The
> intermodulation products that show up, due to a strong signal hitting
> non-linearities in the frontend, act as raised noise floor at other
> frequencies.
> 
> b. Without a splitter or some other device in the way, you have a
> created a ground loop between you and the cable company.  This current
> on the ground conductor shows up as EMI/a raised noise floor.  (I doubt
> a PVR-x50 on it's own would be mitigating a ground loop.)
> 
> c. You have improperly terminated connections or an impedance mistmatch
> somewhere causing signal reflections in your cabling plant, that show up
> as a raised noise floor.  On analog video you would likely see ghosting.
> 
> I could go on guessing, but instead, just make sure you're using good
> practices when it comes to RF signal distribution:
> 
> http://www.ivtvdriver.org/index.php/Howto:Improve_signal_quality

I try to follow good practices.  I think the biggest thing from your
list that I don't have is an isolation transformer.

> 2.  When multiple devices encoding leads to a corrupt stream, I'll
> assert it is the driver of the device delivering the corrupted stream
> that is mishandling buffers or DMA completion notifications.  So I
> believe the driver for the 115 (saa7134) is probably the culprit here.
> Its logic probably works on unloaded systems, but on busy systems it's
> doing the wrong thing.  Your test with the HDTV5 and PVR-x50's support
> this assertion.  It's not the ivtv driver, nor the cx88 driver that
> misbahves in a busy system; it's the saa7134 driver that doesn't do
> something right on busy system.
> 
> Does running 3 115 captures (with a PVRx50 installed and idle) cause
> corruption as well?  I'm betting it does.

I'll try this.

David
-- 
David Engel
david@istwok.net

Re: PVR x50 corrupts ATSC 115 streams

[Andy Walls]

On Mon, 2009-02-23 at 14:10 -0600, David Engel wrote:
> On Mon, Feb 23, 2009 at 02:06:56PM -0500, Steven Toth wrote:
> > David Engel wrote:
> >> On Sun, Feb 22, 2009 at 02:35:00PM -0500, CityK wrote:
> >>> David Engel wrote:

> I won't be able to try anything more until tomorrow evening.
> 
> I think you're missing something, though, Steven.  The "In every case"
> was in reference to "without an x50 installed and connected to cable".
> That includes the cases where there are no x50s installed at all.  How
> can the x50 encoder be causing noise when it's not even installed?
> 
> To help clarify things, here is a rephrasing of this weekend's results:
> 
>   115 by itself = excessive BER
>   115 with one or two other 115s = excessive BER
>   115 with HDTV5 = excessive BER
>   115 with Audigy = excessive BER
>   115 with x50 and x50 not connected and x50 not encoding = excessive BER
>   115 with x50 and x50 connected and x50 not encoding = low BER and no corruption
>   115 with x50 and x50 connected and x50 encoding = low BER and minor corruption
>   HDTV5 with anything = 0 BER and no corruption

David,

I cannot reconcile the two lines with HDTV5 as they seem to say "x" and
"not x".

Aside from that, here are my thoughts:

If it's not one thing, then it's two.  :)  It could be that you have
both both an Electro-Magnetic Interference (EMI) problem and a buffer
handling problem.  You need to work the solution to one while you have
mitigated or controlled the effects of the other.


1. You have indications that hooking up the PVR-x50 mitigates EMI or RF
problems, but you don't know why.  So without knowing details about your
signal distribution plant, I'll make some guesses as to what might be
going on:

a. The unsplit signal is overdriving the frontend of the 115.  The
intermodulation products that show up, due to a strong signal hitting
non-linearities in the frontend, act as raised noise floor at other
frequencies.

b. Without a splitter or some other device in the way, you have a
created a ground loop between you and the cable company.  This current
on the ground conductor shows up as EMI/a raised noise floor.  (I doubt
a PVR-x50 on it's own would be mitigating a ground loop.)

c. You have improperly terminated connections or an impedance mistmatch
somewhere causing signal reflections in your cabling plant, that show up
as a raised noise floor.  On analog video you would likely see ghosting.

I could go on guessing, but instead, just make sure you're using good
practices when it comes to RF signal distribution:

http://www.ivtvdriver.org/index.php/Howto:Improve_signal_quality



2.  When multiple devices encoding leads to a corrupt stream, I'll
assert it is the driver of the device delivering the corrupted stream
that is mishandling buffers or DMA completion notifications.  So I
believe the driver for the 115 (saa7134) is probably the culprit here.
Its logic probably works on unloaded systems, but on busy systems it's
doing the wrong thing.  Your test with the HDTV5 and PVR-x50's support
this assertion.  It's not the ivtv driver, nor the cx88 driver that
misbahves in a busy system; it's the saa7134 driver that doesn't do
something right on busy system.

Does running 3 115 captures (with a PVRx50 installed and idle) cause
corruption as well?  I'm betting it does.


Regards,
Andy


> David

Re: PVR x50 corrupts ATSC 115 streams

[David Engel]

On Tue, Feb 17, 2009 at 09:53:35AM -0600, David Engel wrote:
> I moved the disks and tuner cards (2 Kworld ATSC 115s, 1 Hauppauge PVR
> 250 and 1 Hauppauge PVR 350) to the new system (AMD X2 3600 CPU and
> Biostar TForce 550 motherboard).  Things went fairly smoothly and I
> seemed to have full stability again for the first time in several
> weeks.
> 
> Then, I started noticing frequent corruption in some of my claar QAM
> recordings from the ATSC 115 cards.  When the corruption is present,
> it occurs every few seconds -- a splotch of garbage in the picture
> here, a stutter and a skipped frame there.  Sure enough, MythTV and
> mplayer both report CRC, damage, splice and other errors when playing
> the streams.
> 
> I finally determined the stream corruption happens if and only if one
> of the PVR x50 cards is being used at the same time.  If only the ATSC
> 115s are used, there is no corruption.  As soon as either of the PVr
> X50 is used with an ATSC 115, there is corruption.  I tested with the
> stock drivers from the 2.6.27.17 kernel and from current Hg.  The
> corruption happens with both sets of drivers.  FWIW, I haven't noticed
> any corruption with the analog recordings from the PVR x50s.
> 
> Does anyone know what might be going on?  These very same tuner cards
> worked fine in the old system (Intel P4 3.0GHz CPU and Abit IC7
> motherboard) for close to two years.

I want to follow up on this for the benefit of anyone who runs across
it in the archives.

The short version is the problem appears to have been caused by the
motherboard.  My guess is noise or a grounding problem.

The slightly longer version is I've been using a non-optimal
arrangement of tuner cards to avoid the corruption problems described
above.  About two weeks ago, I started having problems with one and
then multiple SATA disks.  Process of elimination led to the
motherboard.  I tried the previously troublesome combination of cards
today with the new motherboard and no longer see the problem.

David
-- 
David Engel
david@istwok.net