* PVR x50 corrupts ATSC 115 streams @ 2009-02-17 15:53 David Engel 2009-02-17 16:05 ` Steven Toth 2009-08-07 2:50 ` David Engel 0 siblings, 2 replies; 34+ messages in thread From: David Engel @ 2009-02-17 15:53 UTC (permalink / raw) To: linux-media, V4L; +Cc: Hans Verkuil 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-17 15:53 PVR x50 corrupts ATSC 115 streams David Engel @ 2009-02-17 16:05 ` Steven Toth 2009-02-17 20:17 ` David Engel 2009-08-07 2:50 ` David Engel 1 sibling, 1 reply; 34+ messages in thread From: Steven Toth @ 2009-02-17 16:05 UTC (permalink / raw) To: David Engel; +Cc: linux-media, V4L > 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-17 16:05 ` Steven Toth @ 2009-02-17 20:17 ` David Engel 2009-02-17 20:29 ` Steven Toth 0 siblings, 1 reply; 34+ messages in thread From: David Engel @ 2009-02-17 20:17 UTC (permalink / raw) To: Steven Toth; +Cc: linux-media, V4L 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-17 20:17 ` David Engel @ 2009-02-17 20:29 ` Steven Toth 2009-02-17 20:56 ` David Engel 2009-02-18 5:19 ` David Engel 0 siblings, 2 replies; 34+ messages in thread From: Steven Toth @ 2009-02-17 20:29 UTC (permalink / raw) To: David Engel; +Cc: linux-media, V4L 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-17 20:29 ` Steven Toth @ 2009-02-17 20:56 ` David Engel 2009-02-17 21:05 ` Devin Heitmueller 2009-02-18 5:19 ` David Engel 1 sibling, 1 reply; 34+ messages in thread From: David Engel @ 2009-02-17 20:56 UTC (permalink / raw) To: Steven Toth; +Cc: linux-media, V4L 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-17 20:56 ` David Engel @ 2009-02-17 21:05 ` Devin Heitmueller 2009-02-17 22:29 ` Steven Toth 0 siblings, 1 reply; 34+ messages in thread From: Devin Heitmueller @ 2009-02-17 21:05 UTC (permalink / raw) To: David Engel; +Cc: Steven Toth, linux-media, V4L 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-17 21:05 ` Devin Heitmueller @ 2009-02-17 22:29 ` Steven Toth 2009-02-17 22:38 ` Devin Heitmueller 0 siblings, 1 reply; 34+ messages in thread From: Steven Toth @ 2009-02-17 22:29 UTC (permalink / raw) To: Devin Heitmueller; +Cc: David Engel, linux-media, V4L 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-17 22:29 ` Steven Toth @ 2009-02-17 22:38 ` Devin Heitmueller 2009-02-18 15:16 ` Steven Toth 0 siblings, 1 reply; 34+ messages in thread From: Devin Heitmueller @ 2009-02-17 22:38 UTC (permalink / raw) To: Steven Toth; +Cc: David Engel, linux-media, V4L 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-17 22:38 ` Devin Heitmueller @ 2009-02-18 15:16 ` Steven Toth 2009-02-19 2:11 ` CityK 0 siblings, 1 reply; 34+ messages in thread From: Steven Toth @ 2009-02-18 15:16 UTC (permalink / raw) To: Devin Heitmueller; +Cc: David Engel, linux-media, V4L 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-18 15:16 ` Steven Toth @ 2009-02-19 2:11 ` CityK 2009-02-19 15:26 ` Steven Toth 0 siblings, 1 reply; 34+ messages in thread From: CityK @ 2009-02-19 2:11 UTC (permalink / raw) To: Steven Toth; +Cc: Devin Heitmueller, V4L, David Engel, linux-media 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-19 2:11 ` CityK @ 2009-02-19 15:26 ` Steven Toth 0 siblings, 0 replies; 34+ messages in thread From: Steven Toth @ 2009-02-19 15:26 UTC (permalink / raw) To: CityK; +Cc: Devin Heitmueller, V4L, David Engel, linux-media 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-17 20:29 ` Steven Toth 2009-02-17 20:56 ` David Engel @ 2009-02-18 5:19 ` David Engel 2009-02-18 8:25 ` Rudy Zijlstra 2009-02-18 14:56 ` Steven Toth 1 sibling, 2 replies; 34+ messages in thread From: David Engel @ 2009-02-18 5:19 UTC (permalink / raw) To: Steven Toth; +Cc: linux-media, V4L 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-18 5:19 ` David Engel @ 2009-02-18 8:25 ` Rudy Zijlstra 2009-02-18 15:29 ` David Engel 2009-02-18 14:56 ` Steven Toth 1 sibling, 1 reply; 34+ messages in thread From: Rudy Zijlstra @ 2009-02-18 8:25 UTC (permalink / raw) To: David Engel; +Cc: Steven Toth, V4L, linux-media > > 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-18 8:25 ` Rudy Zijlstra @ 2009-02-18 15:29 ` David Engel 0 siblings, 0 replies; 34+ messages in thread From: David Engel @ 2009-02-18 15:29 UTC (permalink / raw) To: Rudy Zijlstra; +Cc: V4L, linux-media 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-18 5:19 ` David Engel 2009-02-18 8:25 ` Rudy Zijlstra @ 2009-02-18 14:56 ` Steven Toth 2009-02-18 15:34 ` David Engel 1 sibling, 1 reply; 34+ messages in thread From: Steven Toth @ 2009-02-18 14:56 UTC (permalink / raw) To: David Engel; +Cc: linux-media, V4L > 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-18 14:56 ` Steven Toth @ 2009-02-18 15:34 ` David Engel 2009-02-19 16:28 ` David Engel 0 siblings, 1 reply; 34+ messages in thread From: David Engel @ 2009-02-18 15:34 UTC (permalink / raw) To: Steven Toth; +Cc: linux-media, V4L 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-18 15:34 ` David Engel @ 2009-02-19 16:28 ` David Engel 2009-02-19 16:44 ` Steven Toth 2009-02-22 19:35 ` CityK 0 siblings, 2 replies; 34+ messages in thread From: David Engel @ 2009-02-19 16:28 UTC (permalink / raw) To: Steven Toth; +Cc: linux-media, V4L 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-19 16:28 ` David Engel @ 2009-02-19 16:44 ` Steven Toth 2009-02-22 19:35 ` CityK 1 sibling, 0 replies; 34+ messages in thread From: Steven Toth @ 2009-02-19 16:44 UTC (permalink / raw) To: David Engel; +Cc: linux-media, V4L > > 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-19 16:28 ` David Engel 2009-02-19 16:44 ` Steven Toth @ 2009-02-22 19:35 ` CityK 2009-02-23 18:39 ` David Engel 1 sibling, 1 reply; 34+ messages in thread From: CityK @ 2009-02-22 19:35 UTC (permalink / raw) To: David Engel; +Cc: Steven Toth, linux-media, V4L 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-22 19:35 ` CityK @ 2009-02-23 18:39 ` David Engel 2009-02-23 19:06 ` Steven Toth 0 siblings, 1 reply; 34+ messages in thread From: David Engel @ 2009-02-23 18:39 UTC (permalink / raw) To: CityK; +Cc: Steven Toth, linux-media, V4L 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-23 18:39 ` David Engel @ 2009-02-23 19:06 ` Steven Toth 2009-02-23 20:10 ` David Engel 0 siblings, 1 reply; 34+ messages in thread From: Steven Toth @ 2009-02-23 19:06 UTC (permalink / raw) To: David Engel; +Cc: CityK, linux-media, V4L 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-23 19:06 ` Steven Toth @ 2009-02-23 20:10 ` David Engel 2009-02-23 21:53 ` Steven Toth 2009-02-24 0:05 ` Andy Walls 0 siblings, 2 replies; 34+ messages in thread From: David Engel @ 2009-02-23 20:10 UTC (permalink / raw) To: Steven Toth; +Cc: CityK, linux-media, V4L 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-23 20:10 ` David Engel @ 2009-02-23 21:53 ` Steven Toth 2009-02-23 22:03 ` Devin Heitmueller 2009-02-24 0:05 ` Andy Walls 1 sibling, 1 reply; 34+ messages in thread From: Steven Toth @ 2009-02-23 21:53 UTC (permalink / raw) To: linux-media; +Cc: David Engel, CityK, V4L >> 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-23 21:53 ` Steven Toth @ 2009-02-23 22:03 ` Devin Heitmueller 2009-02-23 22:48 ` David Engel 0 siblings, 1 reply; 34+ messages in thread From: Devin Heitmueller @ 2009-02-23 22:03 UTC (permalink / raw) To: Steven Toth; +Cc: linux-media, V4L, David Engel, CityK 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-23 22:03 ` Devin Heitmueller @ 2009-02-23 22:48 ` David Engel 2009-02-23 22:58 ` Devin Heitmueller 0 siblings, 1 reply; 34+ messages in thread From: David Engel @ 2009-02-23 22:48 UTC (permalink / raw) To: Devin Heitmueller; +Cc: Steven Toth, linux-media, V4L, CityK 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-23 22:48 ` David Engel @ 2009-02-23 22:58 ` Devin Heitmueller 2009-02-24 1:38 ` pat-lkml 2009-02-24 16:40 ` David Engel 0 siblings, 2 replies; 34+ messages in thread From: Devin Heitmueller @ 2009-02-23 22:58 UTC (permalink / raw) To: David Engel; +Cc: Steven Toth, linux-media, V4L, CityK 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-23 22:58 ` Devin Heitmueller @ 2009-02-24 1:38 ` pat-lkml 2009-02-24 16:40 ` David Engel 1 sibling, 0 replies; 34+ messages in thread From: pat-lkml @ 2009-02-24 1:38 UTC (permalink / raw) To: Devin Heitmueller; +Cc: David Engel, CityK, V4L, linux-media 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-23 22:58 ` Devin Heitmueller 2009-02-24 1:38 ` pat-lkml @ 2009-02-24 16:40 ` David Engel 1 sibling, 0 replies; 34+ messages in thread From: David Engel @ 2009-02-24 16:40 UTC (permalink / raw) To: Devin Heitmueller, pat-lkml, Andy Walls Cc: Steven Toth, linux-media, V4L, CityK 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-23 20:10 ` David Engel 2009-02-23 21:53 ` Steven Toth @ 2009-02-24 0:05 ` Andy Walls 1 sibling, 0 replies; 34+ messages in thread From: Andy Walls @ 2009-02-24 0:05 UTC (permalink / raw) To: David Engel; +Cc: Steven Toth, V4L, CityK, linux-media 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-17 15:53 PVR x50 corrupts ATSC 115 streams David Engel 2009-02-17 16:05 ` Steven Toth @ 2009-08-07 2:50 ` David Engel 1 sibling, 0 replies; 34+ messages in thread From: David Engel @ 2009-08-07 2:50 UTC (permalink / raw) To: linux-media, V4L 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams
@ 2009-02-18 12:41 Andreas
2009-02-18 15:39 ` David Engel
2009-02-19 3:37 ` CityK
0 siblings, 2 replies; 34+ messages in thread
From: Andreas @ 2009-02-18 12:41 UTC (permalink / raw)
To: linux-media
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
^ permalink raw reply [flat|nested] 34+ messages in thread* Re: PVR x50 corrupts ATSC 115 streams 2009-02-18 12:41 Andreas @ 2009-02-18 15:39 ` David Engel 2009-02-19 3:37 ` CityK 1 sibling, 0 replies; 34+ messages in thread From: David Engel @ 2009-02-18 15:39 UTC (permalink / raw) To: Andreas; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-18 12:41 Andreas 2009-02-18 15:39 ` David Engel @ 2009-02-19 3:37 ` CityK 2009-02-19 13:30 ` Andreas 1 sibling, 1 reply; 34+ messages in thread From: CityK @ 2009-02-19 3:37 UTC (permalink / raw) To: Andreas; +Cc: linux-media 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). ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: PVR x50 corrupts ATSC 115 streams 2009-02-19 3:37 ` CityK @ 2009-02-19 13:30 ` Andreas 0 siblings, 0 replies; 34+ messages in thread From: Andreas @ 2009-02-19 13:30 UTC (permalink / raw) To: CityK; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2009-08-07 2:50 UTC | newest] Thread overview: 34+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-02-17 15:53 PVR x50 corrupts ATSC 115 streams David Engel 2009-02-17 16:05 ` Steven Toth 2009-02-17 20:17 ` David Engel 2009-02-17 20:29 ` Steven Toth 2009-02-17 20:56 ` David Engel 2009-02-17 21:05 ` Devin Heitmueller 2009-02-17 22:29 ` Steven Toth 2009-02-17 22:38 ` Devin Heitmueller 2009-02-18 15:16 ` Steven Toth 2009-02-19 2:11 ` CityK 2009-02-19 15:26 ` Steven Toth 2009-02-18 5:19 ` David Engel 2009-02-18 8:25 ` Rudy Zijlstra 2009-02-18 15:29 ` David Engel 2009-02-18 14:56 ` Steven Toth 2009-02-18 15:34 ` David Engel 2009-02-19 16:28 ` David Engel 2009-02-19 16:44 ` Steven Toth 2009-02-22 19:35 ` CityK 2009-02-23 18:39 ` David Engel 2009-02-23 19:06 ` Steven Toth 2009-02-23 20:10 ` David Engel 2009-02-23 21:53 ` Steven Toth 2009-02-23 22:03 ` Devin Heitmueller 2009-02-23 22:48 ` David Engel 2009-02-23 22:58 ` Devin Heitmueller 2009-02-24 1:38 ` pat-lkml 2009-02-24 16:40 ` David Engel 2009-02-24 0:05 ` Andy Walls 2009-08-07 2:50 ` David Engel -- strict thread matches above, loose matches on Subject: below -- 2009-02-18 12:41 Andreas 2009-02-18 15:39 ` David Engel 2009-02-19 3:37 ` CityK 2009-02-19 13:30 ` Andreas
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox