HVR-1600 QAM recordings with slight glitches in them

HVR-1600 QAM recordings with slight glitches in them

[Brian J. Murrell]

[-- Attachment #1: Type: text/plain, Size: 6899 bytes --]

Hi,

I have an HVR-1600 on a 3GHz dual-core P4 running linux 3.2.0.

Whenever I record from clearqam using this card I frequently get small
"glitches" in playback.  Playing these same files with mplayer yields
things like:

demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
[mpeg2video @ 0x893a2e0]mb incr damaged
[mpeg2video @ 0x893a2e0]Warning MVs not available
[mpeg2video @ 0x893a2e0]concealing 66 DC, 66 AC, 66 MV errors

demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
Warning! FPS changed 23.976 -> 29.970  (-5.994005) [4]  

demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.

demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
Warning! FPS changed 23.976 -> 29.970  (-5.994005) [4]  

demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
[mpeg2video @ 0x893a2e0]invalid cbp at 4 12
[mpeg2video @ 0x893a2e0]Warning MVs not available
[mpeg2video @ 0x893a2e0]concealing 198 DC, 198 AC, 198 MV errors
[mpeg2video @ 0x893a2e0]ac-tex damaged at 11 24
[mpeg2video @ 0x893a2e0]Warning MVs not available
[mpeg2video @ 0x893a2e0]concealing 99 DC, 99 AC, 99 MV errors

demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
Warning! FPS changed 23.976 -> 29.970  (-5.994005) [4]  

demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.

demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
Warning! FPS changed 23.976 -> 29.970  (-5.994005) [4]  

demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.

demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
Warning! FPS changed 23.976 -> 29.970  (-5.994005) [4]  

demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.

demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
Warning! FPS changed 23.976 -> 29.970  (-5.994005) [4]  

demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
[mpeg2video @ 0x893a2e0]ac-tex damaged at 27 0
[mpeg2video @ 0x893a2e0]ac-tex damaged at 1 1
[mpeg2video @ 0x893a2e0]ac-tex damaged at 6 2
[mpeg2video @ 0x893a2e0]slice mismatch
[mpeg2video @ 0x893a2e0]mb incr damaged
[mpeg2video @ 0x893a2e0]invalid cbp at 15 6
[mpeg2video @ 0x893a2e0]mb incr damaged
[mpeg2video @ 0x893a2e0]ac-tex damaged at 4 8
[mpeg2video @ 0x893a2e0]slice mismatch
[mpeg2video @ 0x893a2e0]invalid mb type in B Frame at 21 10
[mpeg2video @ 0x893a2e0]slice mismatch
[mpeg2video @ 0x893a2e0]slice mismatch
[mpeg2video @ 0x893a2e0]mb incr damaged
[mpeg2video @ 0x893a2e0]slice mismatch
[mpeg2video @ 0x893a2e0]ac-tex damaged at 12 15
[mpeg2video @ 0x893a2e0]mb incr damaged
[mpeg2video @ 0x893a2e0]slice mismatch
[mpeg2video @ 0x893a2e0]invalid cbp at 14 18
[mpeg2video @ 0x893a2e0]invalid mb type in B Frame at 12 20
[mpeg2video @ 0x893a2e0]slice mismatch
[mpeg2video @ 0x893a2e0]mb incr damaged
[mpeg2video @ 0x893a2e0]ac-tex damaged at 1 22
[mpeg2video @ 0x893a2e0]invalid cbp at 1 23
[mpeg2video @ 0x893a2e0]ac-tex damaged at 20 24
[mpeg2video @ 0x893a2e0]invalid cbp at 1 25
[mpeg2video @ 0x893a2e0]mb incr damaged
[mpeg2video @ 0x893a2e0]slice mismatch
[mpeg2video @ 0x893a2e0]mb incr damaged
[mpeg2video @ 0x893a2e0]ac-tex damaged at 13 29
[mpeg2video @ 0x893a2e0]concealing 990 DC, 990 AC, 990 MV errors

demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
Warning! FPS changed 23.976 -> 29.970  (-5.994005) [4]  

demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.

demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
Warning! FPS changed 23.976 -> 29.970  (-5.994005) [4]  

demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.

demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
Warning! FPS changed 23.976 -> 29.970  (-5.994005) [4]  

demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
[mpeg2video @ 0x893a2e0]ac-tex damaged at 14 10
[mpeg2video @ 0x893a2e0]ac-tex damaged at 9 10
[mpeg2video @ 0x893a2e0]invalid mb type in P Frame at 2 11
[mpeg2video @ 0x893a2e0]mb incr damaged
[mpeg2video @ 0x893a2e0]ac-tex damaged at 24 14
[mpeg2video @ 0x893a2e0]ac-tex damaged at 9 14
[mpeg2video @ 0x893a2e0]ac-tex damaged at 3 18
[mpeg2video @ 0x893a2e0]ac-tex damaged at 16 16
[mpeg2video @ 0x893a2e0]ac-tex damaged at 10 17
[mpeg2video @ 0x893a2e0]ac-tex damaged at 10 18
[mpeg2video @ 0x893a2e0]invalid mb type in P Frame at 9 20
[mpeg2video @ 0x893a2e0]ac-tex damaged at 10 20
[mpeg2video @ 0x893a2e0]ac-tex damaged at 11 22
[mpeg2video @ 0x893a2e0]invalid cbp at 1 22
[mpeg2video @ 0x893a2e0]ac-tex damaged at 8 23
[mpeg2video @ 0x893a2e0]ac-tex damaged at 3 24
[mpeg2video @ 0x893a2e0]invalid cbp at 2 26
[mpeg2video @ 0x893a2e0]ac-tex damaged at 9 26
[mpeg2video @ 0x893a2e0]ac-tex damaged at 0 27
[mpeg2video @ 0x893a2e0]ac-tex damaged at 0 28
[mpeg2video @ 0x893a2e0]ac-tex damaged at 0 29
[mpeg2video @ 0x893a2e0]concealing 660 DC, 660 AC, 660 MV errors
[mpeg2video @ 0x893a2e0]mb incr damaged
[mpeg2video @ 0x893a2e0]concealing 297 DC, 297 AC, 297 MV errors
[mpeg2video @ 0x893a2e0]invalid cbp at 1 5
[mpeg2video @ 0x893a2e0]ac-tex damaged at 1 9
[mpeg2video @ 0x893a2e0]mb incr damaged
[mpeg2video @ 0x893a2e0]invalid mb type in B Frame at 5 15
[mpeg2video @ 0x893a2e0]invalid cbp at 16 18
[mpeg2video @ 0x893a2e0]mb incr damaged
[mpeg2video @ 0x893a2e0]mb incr damaged
[mpeg2video @ 0x893a2e0]invalid mb type in B Frame at 17 21
[mpeg2video @ 0x893a2e0]invalid mb type in B Frame at 11 22
[mpeg2video @ 0x893a2e0]invalid cbp at 2 23
[mpeg2video @ 0x893a2e0]ac-tex damaged at 9 25
[mpeg2video @ 0x893a2e0]invalid mb type in B Frame at 4 26
[mpeg2video @ 0x893a2e0]slice mismatch
[mpeg2video @ 0x893a2e0]concealing 891 DC, 891 AC, 891 MV errors

demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
Warning! FPS changed 23.976 -> 29.970  (-5.994005) [4]  
...
demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
[mpeg2video @ 0x893a2e0]slice mismatch
[mpeg2video @ 0x893a2e0]invalid cbp at 15 11
[mpeg2video @ 0x893a2e0]concealing 132 DC, 132 AC, 132 MV errors
[mpeg2video @ 0x893a2e0]concealing 21 DC, 21 AC, 21 MV errors
TS_PARSE: COULDN'T SYNC

I am in particular pointing out the "mpeg2video" errors not the
framerate switching messages.

There are no messages whatsoever in the kernel log when this
happens so whatever is happening the cx18 driver is being silent
about it.

I also can't very easily blame the cable signal as an HVR-950Q
recording from clearqam at the exact same time never has these
sorts of artifacts.

Any thoughts why these only happen on the HVR-1600?

Cheers,
b.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: HVR-1600 QAM recordings with slight glitches in them

[Andy Walls]

On Sun, 2012-04-22 at 23:30 -0400, Brian J. Murrell wrote:
> Hi,
> 
> I have an HVR-1600 on a 3GHz dual-core P4 running linux 3.2.0.
> 
> Whenever I record from clearqam using this card I frequently get small
> "glitches" in playback.  Playing these same files with mplayer yields
> things like:
> 
> demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
> [mpeg2video @ 0x893a2e0]mb incr damaged
> [mpeg2video @ 0x893a2e0]Warning MVs not available
> [mpeg2video @ 0x893a2e0]concealing 66 DC, 66 AC, 66 MV errors
> 
> demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
> Warning! FPS changed 23.976 -> 29.970  (-5.994005) [4]  
> 
> demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
> 
> demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
> Warning! FPS changed 23.976 -> 29.970  (-5.994005) [4]  
> 
> demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
> [mpeg2video @ 0x893a2e0]invalid cbp at 4 12
> [mpeg2video @ 0x893a2e0]Warning MVs not available
> [mpeg2video @ 0x893a2e0]concealing 198 DC, 198 AC, 198 MV errors
> [mpeg2video @ 0x893a2e0]ac-tex damaged at 11 24
> [mpeg2video @ 0x893a2e0]Warning MVs not available
> [mpeg2video @ 0x893a2e0]concealing 99 DC, 99 AC, 99 MV errors
> 
> demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
> Warning! FPS changed 23.976 -> 29.970  (-5.994005) [4]  
> 
> demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
> 
> demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
> Warning! FPS changed 23.976 -> 29.970  (-5.994005) [4]  
> 
> demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
> 
> demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
> Warning! FPS changed 23.976 -> 29.970  (-5.994005) [4]  
> 
> demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
> 
> demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
> Warning! FPS changed 23.976 -> 29.970  (-5.994005) [4]  
> 
> demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
> [mpeg2video @ 0x893a2e0]ac-tex damaged at 27 0
> [mpeg2video @ 0x893a2e0]ac-tex damaged at 1 1
> [mpeg2video @ 0x893a2e0]ac-tex damaged at 6 2
> [mpeg2video @ 0x893a2e0]slice mismatch
> [mpeg2video @ 0x893a2e0]mb incr damaged
> [mpeg2video @ 0x893a2e0]invalid cbp at 15 6
> [mpeg2video @ 0x893a2e0]mb incr damaged
> [mpeg2video @ 0x893a2e0]ac-tex damaged at 4 8
> [mpeg2video @ 0x893a2e0]slice mismatch
> [mpeg2video @ 0x893a2e0]invalid mb type in B Frame at 21 10
> [mpeg2video @ 0x893a2e0]slice mismatch
> [mpeg2video @ 0x893a2e0]slice mismatch
> [mpeg2video @ 0x893a2e0]mb incr damaged
> [mpeg2video @ 0x893a2e0]slice mismatch
> [mpeg2video @ 0x893a2e0]ac-tex damaged at 12 15
> [mpeg2video @ 0x893a2e0]mb incr damaged
> [mpeg2video @ 0x893a2e0]slice mismatch
> [mpeg2video @ 0x893a2e0]invalid cbp at 14 18
> [mpeg2video @ 0x893a2e0]invalid mb type in B Frame at 12 20
> [mpeg2video @ 0x893a2e0]slice mismatch
> [mpeg2video @ 0x893a2e0]mb incr damaged
> [mpeg2video @ 0x893a2e0]ac-tex damaged at 1 22
> [mpeg2video @ 0x893a2e0]invalid cbp at 1 23
> [mpeg2video @ 0x893a2e0]ac-tex damaged at 20 24
> [mpeg2video @ 0x893a2e0]invalid cbp at 1 25
> [mpeg2video @ 0x893a2e0]mb incr damaged
> [mpeg2video @ 0x893a2e0]slice mismatch
> [mpeg2video @ 0x893a2e0]mb incr damaged
> [mpeg2video @ 0x893a2e0]ac-tex damaged at 13 29
> [mpeg2video @ 0x893a2e0]concealing 990 DC, 990 AC, 990 MV errors
> 
> demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
> Warning! FPS changed 23.976 -> 29.970  (-5.994005) [4]  
> 
> demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
> 
> demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
> Warning! FPS changed 23.976 -> 29.970  (-5.994005) [4]  
> 
> demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
> 
> demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
> Warning! FPS changed 23.976 -> 29.970  (-5.994005) [4]  
> 
> demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
> [mpeg2video @ 0x893a2e0]ac-tex damaged at 14 10
> [mpeg2video @ 0x893a2e0]ac-tex damaged at 9 10
> [mpeg2video @ 0x893a2e0]invalid mb type in P Frame at 2 11
> [mpeg2video @ 0x893a2e0]mb incr damaged
> [mpeg2video @ 0x893a2e0]ac-tex damaged at 24 14
> [mpeg2video @ 0x893a2e0]ac-tex damaged at 9 14
> [mpeg2video @ 0x893a2e0]ac-tex damaged at 3 18
> [mpeg2video @ 0x893a2e0]ac-tex damaged at 16 16
> [mpeg2video @ 0x893a2e0]ac-tex damaged at 10 17
> [mpeg2video @ 0x893a2e0]ac-tex damaged at 10 18
> [mpeg2video @ 0x893a2e0]invalid mb type in P Frame at 9 20
> [mpeg2video @ 0x893a2e0]ac-tex damaged at 10 20
> [mpeg2video @ 0x893a2e0]ac-tex damaged at 11 22
> [mpeg2video @ 0x893a2e0]invalid cbp at 1 22
> [mpeg2video @ 0x893a2e0]ac-tex damaged at 8 23
> [mpeg2video @ 0x893a2e0]ac-tex damaged at 3 24
> [mpeg2video @ 0x893a2e0]invalid cbp at 2 26
> [mpeg2video @ 0x893a2e0]ac-tex damaged at 9 26
> [mpeg2video @ 0x893a2e0]ac-tex damaged at 0 27
> [mpeg2video @ 0x893a2e0]ac-tex damaged at 0 28
> [mpeg2video @ 0x893a2e0]ac-tex damaged at 0 29
> [mpeg2video @ 0x893a2e0]concealing 660 DC, 660 AC, 660 MV errors
> [mpeg2video @ 0x893a2e0]mb incr damaged
> [mpeg2video @ 0x893a2e0]concealing 297 DC, 297 AC, 297 MV errors
> [mpeg2video @ 0x893a2e0]invalid cbp at 1 5
> [mpeg2video @ 0x893a2e0]ac-tex damaged at 1 9
> [mpeg2video @ 0x893a2e0]mb incr damaged
> [mpeg2video @ 0x893a2e0]invalid mb type in B Frame at 5 15
> [mpeg2video @ 0x893a2e0]invalid cbp at 16 18
> [mpeg2video @ 0x893a2e0]mb incr damaged
> [mpeg2video @ 0x893a2e0]mb incr damaged
> [mpeg2video @ 0x893a2e0]invalid mb type in B Frame at 17 21
> [mpeg2video @ 0x893a2e0]invalid mb type in B Frame at 11 22
> [mpeg2video @ 0x893a2e0]invalid cbp at 2 23
> [mpeg2video @ 0x893a2e0]ac-tex damaged at 9 25
> [mpeg2video @ 0x893a2e0]invalid mb type in B Frame at 4 26
> [mpeg2video @ 0x893a2e0]slice mismatch
> [mpeg2video @ 0x893a2e0]concealing 891 DC, 891 AC, 891 MV errors
> 
> demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
> Warning! FPS changed 23.976 -> 29.970  (-5.994005) [4]  
> ...
> demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
> [mpeg2video @ 0x893a2e0]slice mismatch
> [mpeg2video @ 0x893a2e0]invalid cbp at 15 11
> [mpeg2video @ 0x893a2e0]concealing 132 DC, 132 AC, 132 MV errors
> [mpeg2video @ 0x893a2e0]concealing 21 DC, 21 AC, 21 MV errors
> TS_PARSE: COULDN'T SYNC
> 
> I am in particular pointing out the "mpeg2video" errors not the
> framerate switching messages.
> 
> There are no messages whatsoever in the kernel log when this
> happens so whatever is happening the cx18 driver is being silent
> about it.
> 
> I also can't very easily blame the cable signal as an HVR-950Q
> recording from clearqam at the exact same time never has these
> sorts of artifacts.
> 
> Any thoughts why these only happen on the HVR-1600?

Signal level varaition coupled with the HVR-1600's, at times, mediocre
digital tuning side:

Run 'femon' on the cx18's dvb frontend when you have a live QAM capture
ongoing.

Watch for the BER or UNCorrectable block count to increase at about the
same time you view a glitch in the video.  If this is the case, there is
something about the signal the HVR-1600 is having trouble with.  (The
older models don't have the best digital tuner and digital demod
combination out there.)
If the signal shown in femon is at a relatively high level most of the
time, then the cable signal probably has an instantaneous signal that
sometimes overdrives the frontend.  An inline attenuator might make the
problem go away.
If the signal is at a low level, it may drop below threshold
occasionally.  An in line amplifier, installed as close to where the
signal comes into you home as possible, might help.

If it's not signal level related and not DMA related, then it is a
problem with the cx18 driver feeding things to the DVB core, or a
problem with the DVB core itself.

Regards,
Andy

> Cheers,
> b.
> 

Re: HVR-1600 QAM recordings with slight glitches in them

[Brian J. Murrell]

[-- Attachment #1: Type: text/plain, Size: 10527 bytes --]

On 12-04-24 06:42 PM, Andy Walls wrote:
> 
> Signal level varaition coupled with the HVR-1600's, at times, mediocre
> digital tuning side:

Ahh.  Pity.
 
> Run 'femon' on the cx18's dvb frontend when you have a live QAM capture
> ongoing.

OK.  Ran it all evening during the evening capture window.  Started it
at 20:30, sharp to coincide with the evening's recording from that card
also starting at 20:30 sharp.  Here's where it found anomalies:

$ nl /var/tmp/femon.out | grep -v "| ber 00000000 | unc 00000000 |"

So you can see, since femon prints an output line each second, the
number on the left is the seconds since 20:30 and we are looking
for any line showing a ber or unc that is non-zero:

     1	FE: Samsung S5H1409 QAM/8VSB Frontend (ATSC)
    67	status SCVYL | signal 013a | snr 013a | ber 00000198 | unc 00000198 | FE_HAS_LOCK
   313	status SCVYL | signal 013c | snr 013c | ber 0000026b | unc 0000026b | FE_HAS_LOCK
   457	status SCVYL | signal 013a | snr 013a | ber 0000026e | unc 0000026e | FE_HAS_LOCK
   802	status SCVYL | signal 013c | snr 013c | ber 00000265 | unc 00000265 | FE_HAS_LOCK
  1093	status SCVYL | signal 013a | snr 013a | ber 0000014b | unc 0000014b | FE_HAS_LOCK
  1184	status SCVYL | signal 013a | snr 013a | ber 000001ca | unc 000001ca | FE_HAS_LOCK
  1192	status SCVYL | signal 013a | snr 013a | ber 00000267 | unc 00000267 | FE_HAS_LOCK
  1385	status SCVYL | signal 013c | snr 013c | ber 0000025d | unc 0000025d | FE_HAS_LOCK
  1435	status SCVYL | signal 013c | snr 013c | ber 00000268 | unc 00000268 | FE_HAS_LOCK
  1511	status SCVYL | signal 013c | snr 013c | ber 0000026c | unc 0000026c | FE_HAS_LOCK
  1657	status SCVYL | signal 013a | snr 013a | ber 0000026a | unc 0000026a | FE_HAS_LOCK
  1693	status SCVYL | signal 013a | snr 013c | ber 0000026f | unc 0000026f | FE_HAS_LOCK
  1749	status SCVYL | signal 013c | snr 013c | ber 00000184 | unc 00000184 | FE_HAS_LOCK
  1796	status SCVYL | signal 013a | snr 013a | ber 00001a8b | unc 00001a8b | FE_HAS_LOCK
  1814	status SCVYL | signal 013c | snr 013c | ber 0000026d | unc 0000026d | FE_HAS_LOCK
  2028	status SCVYL | signal 013c | snr 013c | ber 00000275 | unc 00000275 | FE_HAS_LOCK
  2081	status SCVYL | signal 013c | snr 013c | ber 0000023a | unc 0000023a | FE_HAS_LOCK
  2261	status SCVYL | signal 013c | snr 013c | ber 00000264 | unc 00000264 | FE_HAS_LOCK
  2307	status SCVYL | signal 013c | snr 013c | ber 00000279 | unc 00000279 | FE_HAS_LOCK
  2318	status SCVYL | signal 013c | snr 013c | ber 0000026b | unc 0000026b | FE_HAS_LOCK
  2474	status SCVYL | signal 013a | snr 013a | ber 0000026f | unc 0000026f | FE_HAS_LOCK
  2533	status SCVYL | signal 013c | snr 013c | ber 00000098 | unc 00000098 | FE_HAS_LOCK
  2612	status SCVYL | signal 013a | snr 013a | ber 0000026a | unc 0000026a | FE_HAS_LOCK
  2627	status SCVYL | signal 013c | snr 013c | ber 00000108 | unc 00000108 | FE_HAS_LOCK
  2671	status SCVYL | signal 013c | snr 013c | ber 00000196 | unc 00000196 | FE_HAS_LOCK
  2870	status SCVYL | signal 013c | snr 013c | ber 00000264 | unc 00000264 | FE_HAS_LOCK
  3084	status SCVYL | signal 013c | snr 013c | ber 00000274 | unc 00000274 | FE_HAS_LOCK
  3220	status SCVYL | signal 013c | snr 013c | ber 00000275 | unc 00000275 | FE_HAS_LOCK
  3323	status SCVYL | signal 013c | snr 013c | ber 0000026b | unc 0000026b | FE_HAS_LOCK
  3406	status SCVYL | signal 013c | snr 013c | ber 0000024f | unc 0000024f | FE_HAS_LOCK
  3433	status SCVYL | signal 013c | snr 013a | ber 0000022a | unc 0000022a | FE_HAS_LOCK
  3946	status SCVYL | signal 013c | snr 013c | ber 00000270 | unc 00000270 | FE_HAS_LOCK
  4129	status SCVYL | signal 013c | snr 013c | ber 0000026d | unc 0000026d | FE_HAS_LOCK
  4275	status SCVYL | signal 013c | snr 013c | ber 00000273 | unc 00000273 | FE_HAS_LOCK
  4284	status SCVYL | signal 013c | snr 013c | ber 00000267 | unc 00000267 | FE_HAS_LOCK
  4411	status SCVYL | signal 013c | snr 013c | ber 00000270 | unc 00000270 | FE_HAS_LOCK
  4718	status SCVYL | signal 013c | snr 013c | ber 00000204 | unc 00000204 | FE_HAS_LOCK
  4779	status SCVYL | signal 013c | snr 013c | ber 00000181 | unc 00000181 | FE_HAS_LOCK
  4927	status SCVYL | signal 013c | snr 013c | ber 0000025e | unc 0000025e | FE_HAS_LOCK
  4973	status SCVYL | signal 013c | snr 013c | ber 00000157 | unc 00000157 | FE_HAS_LOCK
  5024	status SCVYL | signal 013c | snr 013c | ber 0000024c | unc 0000024c | FE_HAS_LOCK
  5310	status SCVYL | signal 013c | snr 013c | ber 00000190 | unc 00000190 | FE_HAS_LOCK
  5328	status SCVYL | signal 013c | snr 013c | ber 00000277 | unc 00000277 | FE_HAS_LOCK
  5439	status SCVYL | signal 013a | snr 013a | ber 0000026a | unc 0000026a | FE_HAS_LOCK
  5441	status SCVYL | signal 0138 | snr 0138 | ber 0000024f | unc 0000024f | FE_HAS_LOCK
  5447	status SCVYL | signal 0138 | snr 0138 | ber 00000266 | unc 00000266 | FE_HAS_LOCK
  5885	status SCVYL | signal 013a | snr 013a | ber 000000b3 | unc 000000b3 | FE_HAS_LOCK
  5928	status SCVYL | signal 013a | snr 013a | ber 0000020b | unc 0000020b | FE_HAS_LOCK
  5942	status SCVYL | signal 013a | snr 013a | ber 0000026b | unc 0000026b | FE_HAS_LOCK
  5966	status SCVYL | signal 013a | snr 013a | ber 000004d4 | unc 000004d4 | FE_HAS_LOCK
  6178	status SCVYL | signal 013a | snr 013a | ber 0000026c | unc 0000026c | FE_HAS_LOCK
  6657	status SCVYL | signal 0138 | snr 013a | ber 0000026e | unc 0000026e | FE_HAS_LOCK
  6761	status SCVYL | signal 013a | snr 013a | ber 00000268 | unc 00000268 | FE_HAS_LOCK
  6769	status SCVYL | signal 013a | snr 013a | ber 00000276 | unc 00000276 | FE_HAS_LOCK
  6777	status SCVYL | signal 013a | snr 013a | ber 00000277 | unc 00000277 | FE_HAS_LOCK
  6814	status SCVYL | signal 013a | snr 013a | ber 00000267 | unc 00000267 | FE_HAS_LOCK
  6868	status SCVYL | signal 0138 | snr 0138 | ber 00000171 | unc 00000171 | FE_HAS_LOCK
  6881	status SCVYL | signal 0138 | snr 0138 | ber 00000198 | unc 00000198 | FE_HAS_LOCK
  6891	status SCVYL | signal 0136 | snr 0138 | ber 00000249 | unc 00000249 | FE_HAS_LOCK
  6924	status SCVYL | signal 0138 | snr 0138 | ber 0000026b | unc 0000026b | FE_HAS_LOCK
  7116	status SCVYL | signal 0138 | snr 0138 | ber 00000150 | unc 00000150 | FE_HAS_LOCK
  7119	status SCVYL | signal 0138 | snr 0138 | ber 00000197 | unc 00000197 | FE_HAS_LOCK
  7140	status SCVYL | signal 0138 | snr 0138 | ber 00000270 | unc 00000270 | FE_HAS_LOCK
  7602	status SCVYL | signal 0138 | snr 0138 | ber 00000264 | unc 00000264 | FE_HAS_LOCK
  7716	status SCVYL | signal 0138 | snr 0138 | ber 00000194 | unc 00000194 | FE_HAS_LOCK
  7732	status SCVYL | signal 0138 | snr 0138 | ber 00000272 | unc 00000272 | FE_HAS_LOCK
  7751	status SCVYL | signal 013a | snr 0138 | ber 00000181 | unc 00000181 | FE_HAS_LOCK
  7770	status SCVYL | signal 013a | snr 013a | ber 00000270 | unc 00000270 | FE_HAS_LOCK
  7781	status SCVYL | signal 0138 | snr 0138 | ber 0000026f | unc 0000026f | FE_HAS_LOCK
  7796	status SCVYL | signal 0138 | snr 0138 | ber 00000275 | unc 00000275 | FE_HAS_LOCK
  7808	status SCVYL | signal 0138 | snr 0138 | ber 0000022f | unc 0000022f | FE_HAS_LOCK
  7816	status SCVYL | signal 013a | snr 0138 | ber 0000024e | unc 0000024e | FE_HAS_LOCK
  7822	status SCVYL | signal 013a | snr 013a | ber 00000270 | unc 00000270 | FE_HAS_LOCK
  7956	status SCVYL | signal 0138 | snr 0138 | ber 00000268 | unc 00000268 | FE_HAS_LOCK
  8008	status SCVYL | signal 0138 | snr 0138 | ber 0000026d | unc 0000026d | FE_HAS_LOCK
  8011	status SCVYL | signal 0138 | snr 0138 | ber 00000260 | unc 00000260 | FE_HAS_LOCK
  8232	status SCVYL | signal 013a | snr 013a | ber 0000024b | unc 0000024b | FE_HAS_LOCK
  8235	status SCVYL | signal 013a | snr 013a | ber 00000073 | unc 00000073 | FE_HAS_LOCK
  8255	status SCVYL | signal 0138 | snr 0138 | ber 00000254 | unc 00000254 | FE_HAS_LOCK
  8274	status SCVYL | signal 0138 | snr 0138 | ber 0000024e | unc 0000024e | FE_HAS_LOCK
  8303	status SCVYL | signal 0138 | snr 0138 | ber 0000017f | unc 0000017f | FE_HAS_LOCK
  8305	status SCVYL | signal 0138 | snr 0138 | ber 00000184 | unc 00000184 | FE_HAS_LOCK
  8354	status SCVYL | signal 013a | snr 0138 | ber 00000270 | unc 00000270 | FE_HAS_LOCK
  8442	status SCVYL | signal 0138 | snr 0138 | ber 0000024b | unc 0000024b | FE_HAS_LOCK
  8473	status SCVYL | signal 0138 | snr 0138 | ber 0000014b | unc 0000014b | FE_HAS_LOCK
  8510	status SCVYL | signal 0138 | snr 0138 | ber 00000253 | unc 00000253 | FE_HAS_LOCK
  8557	status SCVYL | signal 013a | snr 013a | ber 00000260 | unc 00000260 | FE_HAS_LOCK
  8578	status SCVYL | signal 013a | snr 013a | ber 00000259 | unc 00000259 | FE_HAS_LOCK
  8639	status SCVYL | signal 0138 | snr 0138 | ber 00000151 | unc 00000151 | FE_HAS_LOCK
  8742	status SCVYL | signal 013a | snr 0138 | ber 0000018c | unc 0000018c | FE_HAS_LOCK
  8820	status SCVYL | signal 0138 | snr 0138 | ber 00000265 | unc 00000265 | FE_HAS_LOCK

First recording of the evening shows "glitches" at the following
intervals:

4
130
157
396
742
790
1035
1035
1035
1071
1134
1146
1203
1256
1328
1338
1378
1602
1638
1694

Not sure if that's a close enough correlation or not.  Not even sure
what those ber and unc values even mean.
 
> Watch for the BER or UNCorrectable block count to increase at about the
> same time you view a glitch in the video.  If this is the case, there is
> something about the signal the HVR-1600 is having trouble with.  (The
> older models don't have the best digital tuner and digital demod
> combination out there.)

So just sucky hardware in general?

> If the signal shown in femon is at a relatively high level most of the
> time, then the cable signal probably has an instantaneous signal that
> sometimes overdrives the frontend.  An inline attenuator might make the
> problem go away.
> If the signal is at a low level, it may drop below threshold
> occasionally.  An in line amplifier, installed as close to where the
> signal comes into you home as possible, might help.

Not sure if those signal and snr values represent normal, low or high
levels.  The values displayed above are fairly representative of the
rest of the samples for the period in terms of signal and snr.
 
> If it's not signal level related and not DMA related, then it is a
> problem with the cx18 driver feeding things to the DVB core, or a
> problem with the DVB core itself.

I guess I will have to leave that up to the expert(s).  :-)

b.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: HVR-1600 QAM recordings with slight glitches in them

[Brian J. Murrell]

[-- Attachment #1: Type: text/plain, Size: 4704 bytes --]

On 12-04-28 10:56 AM, Andy Walls wrote:
> 
> grepping out the 0 lines doesn't let one see the trends in Signal to
> Noise Ratio (SNR) before and after the uncorrectable (unc) block counts.

OK.  I have completely reworked the way I use femon.  I now start/stop
femon along with recordings so I should have a separate femon output for
each recording (using Mythtv system events and a couple of recording
start/stop scripts, fwiw).

> So I see SNR values from 0x138 to 0x13c ( 31.2 dB to 31.6 dB ) when you
> have problems.  For 256-QAM cable signals, I think that is considered
> marginal.  

OK.  Good to know.

> (Can someone else with 256-QAM North American cable please confirm? I
> only have OTA)

Would be great if somebody can.  Thanks in advance.

> When you have no errors, what is the SNR?  I'm guessing there are no
> large swings.

From what I recall of the data, no, the SNR was pretty much the same
throughout good and bad periods of the recordings.  But with my
configuration here, we will know for sure soon enough.

> Hard to tell, given that one of the other digital sub-channels may have
> been effected and not visible on the channel you were recording.

Ahhh.  I see.

> I normally watch DTV live with mplayer, and also have femon open in
> another window, when performing this sort of test.

That's effectively what I am doing with my recordings.  When a recording
starts, an femon starts and logs.  When the recording is done I use
mplayer (-nosound -vo null -benchmark, just to make it run as fast as
possible) and prune out the per frame counters so that what I am left
with is the bits that mplayer complains about in the stream along with
the frame count it happened at.  The femon output is also included for
cross reference.

> A video or audio
> glitch, 1 or 2 seconds after a non-zero uncorrectable block count, is
> usually a good indicator of correlation.

That's what I will look for.

> Well, not the best performer from what I hear.

Indeed.  I don't have any of these problems with my HVR-950Q.  This
HVR-1600 was a really good deal though, so I can't totally complain.  :-)

Speaking of the HVR-950Q, does femon not work with it?  I seem to always
get "zero" values across the board trying.

> But certainly works just
> fine for many people in many contexts.

Yes, and indeed, it works here for the most part even with small
glitches some of the time.  But some other times, the glitching is bad
enough to make a recording more or less useless.

> OK.  There are two ways to go here:
> 
> 1. We assume your signal is marginal.  Take a look here for things to
> check and fix if needed:
> 
> http://ivtvdriver.org/index.php/Howto:Improve_signal_quality

I will see what I can do with those.

> As a test, you you might also want to temporarily change your coax
> wiring setup to reduce the number of splits and connectors before the
> signal goes into the HVR-1600, and see if things are better.

Indeed.  That was at the top of my list also, so isolate the rest of the
cable plant in here.

> Every
> 2-way splitter will drop 3-5 dB of signal.

OK.  So about splitters.  Given that I'm in a house with 4 cable
television runs to different rooms, plus a cable modem, plus 4 PVR tuner
inputs (so yeah, 9 consumers), what is my best splitter plan/options.
Probably ideally I want to split the incoming signal into two, one for
the cable modem and one to feed the television consumers.

Once I have the feed off to the televisions though, am I best trying to
split that into 8, (i.e. equally with an 8-way splitter -- if that's
even possible) or would I be better served with some more smaller splits
in somewhat of a tree formation?

I'm also assuming that all splitters are not of the same quality and
that the "dollar store" ones are likely of inferior quality.  But
"dollar store" aside, even amongst reasonable retailers, how can I tell
(without having to get all electronics geeky with an oscilliscope and
whatnot) what's good and what's bad?

Also, splitting 8 ways, am I into amplification/boosting territory or am
I likely to just boost noise along with the signal?

> 2. We assume your signal is too strong, and that it is overdriving the
> MXL5005s digital tuner of the HVR-1600, causing problems for the CX24227
> demodulator.

Heh.  I wonder if that could be possible given my description above.  :-)

> Your corrective action here would be to attenuate the incoming RF signal
> with either an inline attenuator, or with additional, properly
> terminated, splitters.

Indeed.

Thanks sooooo much for all of the input here.

Cheers,
b.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: HVR-1600 QAM recordings with slight glitches in them

[Brian J. Murrell]

[-- Attachment #1: Type: text/plain, Size: 442 bytes --]

One more question...

On 12-04-28 10:56 AM, Andy Walls wrote:
>
> So I see SNR values from 0x138 to 0x13c ( 31.2 dB to 31.6 dB ) when you
> have problems.  For 256-QAM cable signals, I think that is considered
> marginal.  

I've never gotten my mind around SNRs and dBs, etc.  Generally speaking,
am I looking for these "snr" values to go up or down (i.e. closer to 0
or further away) to make my signal better?

Cheers,
b.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: HVR-1600 QAM recordings with slight glitches in them

[Brian J. Murrell]

[-- Attachment #1: Type: text/plain, Size: 1642 bytes --]

On 12-04-28 02:36 PM, Brian J. Murrell wrote:
> One more question...

And to answer my own question, and provide some more data...

> I've never gotten my mind around SNRs and dBs, etc.  Generally speaking,
> am I looking for these "snr" values to go up or down (i.e. closer to 0
> or further away) to make my signal better?

Clearly, bigger numbers are better.  When I hook my HVR-1600 directly up
to the cable connection coming into the house with a 25 foot cable and a
barrel connector the SNR goes up to "148" (32.8 dB) so that's my
ceiling.  I can't leave it hooked up like this for anything more than a
few minutes so I can't be sure that's a high enough SNR for me to get
perfect recordings every time.

If I add one two way splitter to the incoming cable with one feed going
off to my cable modem and one to the HVR-1600, the SNR drops to "145"
(32.5 dB).  But again, I can't really leave it like that for too long.
so splitting that leg of the 2-way split 3 more times through a 3 way
splitter reduces the SNR at the HVR-1600 to between "142" and "145"
(32.2 - 32.5 dB).

I typically have one more splitter downstream from that 3 way splitter
which is a 4 way splitter to feed all of the tuners on my Mythtv box and
introducing that splitter reduces the SNR at the HVR-1600 to between
"13c" and "13e" (31.6 - 31.8 dB).

I have no idea where in these range of values "acceptable" is though.
Given that the HVR-1600 seems to be more sensitive to signal quality
that just about anything else in here, I suppose I could feed it more
directly from a split closer to the source signal.

Cheers,
b.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: HVR-1600 QAM recordings with slight glitches in them

[Andy Walls]

On Sat, 2012-04-28 at 14:08 -0400, Brian J. Murrell wrote:
> On 12-04-28 10:56 AM, Andy Walls wrote:

> > OK.  There are two ways to go here:
> > 
> > 1. We assume your signal is marginal.  Take a look here for things to
> > check and fix if needed:
> > 
> > http://ivtvdriver.org/index.php/Howto:Improve_signal_quality
> 
> I will see what I can do with those.
> 
> > As a test, you you might also want to temporarily change your coax
> > wiring setup to reduce the number of splits and connectors before the
> > signal goes into the HVR-1600, and see if things are better.
> 
> Indeed.  That was at the top of my list also, so isolate the rest of the
> cable plant in here.
> 
> > Every
> > 2-way splitter will drop 3-5 dB of signal.
> 
> OK.  So about splitters.  Given that I'm in a house with 4 cable
> television runs to different rooms, plus a cable modem, plus 4 PVR tuner
> inputs (so yeah, 9 consumers), what is my best splitter plan/options.
> Probably ideally I want to split the incoming signal into two, one for
> the cable modem and one to feed the television consumers.

Assuming ideal splitters:
a  2 way split is a 3 dB signal loss for each leg
a  4 way split is a 6 dB signal loss for each leg
an 8 way split is a 9 dB signal loss for each leg

Signal losses in dB are additive.  So for example, a device downstream
from a 2-way split and then 4 way split, experiences a minimum of 9 dB
of signal loss.


> Once I have the feed off to the televisions though, am I best trying to
> split that into 8, (i.e. equally with an 8-way splitter -- if that's
> even possible) or would I be better served with some more smaller splits
> in somewhat of a tree formation?

With ideal splitters and perfect cable connections, it wouldn't matter.
With real-life splitters and cable connectors, the fewer the devices and
cable connections you use, the better.


> I'm also assuming that all splitters are not of the same quality and
> that the "dollar store" ones are likely of inferior quality.  But
> "dollar store" aside, even amongst reasonable retailers, how can I tell
> (without having to get all electronics geeky with an oscilliscope and
> whatnot) what's good and what's bad?

When looking for splitters as a consumer, you need to ensure frequency
range of the splitter covers your needed range.

Splitters for terrestrial OTA broadcasts only need to pass signals to
about 900 MHz.  Splitters for satellite TV need to pass signals to
around 2300 MHz (2.3 GHz) or so.  For cable you will need to pass
signals up to about 1000 MHz (1.0 GHz).

You shouldn't woory about splitter performance variabtions on the order
of 1 or 2 dB.  You can compensate for that with a distribution amplifier
and better quality cable and connectors.

BTW, I have in the past purchased a brand name, somewhat expensive, 4
way splitter from a Lowes hardware store, only to find one of the
outputs didn't pass any signal - it was broken. :(



> Also, splitting 8 ways, am I into amplification/boosting territory or am
> I likely to just boost noise along with the signal?

Yes you will be amplifying the incoming noise.  But you've got to do
something to preserve SNR against cable plant losses, which degrade
signal but don't reduce noise.

Put any distribution amplifier you purchase, as close to where the
signal comes into your home as possible.  Make sure it is a low noise
amplifier.  Variable gain is a nice feature, to avoid overdriving your
components.

BTW, the noise figure of a receiving system (your cable plant and
tuners) is dominated by the Noise Figure of it's first amplification
stage:
http://en.wikipedia.org/wiki/Friis_formulas_for_noise

A good, low noise, distribution amplifier can go a long way to helping
eliminate other problems.  Don't skimp; pay the money for a decent one.


Also, you must take steps to reduce other losses and stop signal
reflections: good cable, good cable connections, and properly terminate
every split/leg.  One missing or bad termination results in signal
reflections (i.e. additional noise) in your entire cable plant.


> > 2. We assume your signal is too strong, and that it is overdriving the
> > MXL5005s digital tuner of the HVR-1600, causing problems for the CX24227
> > demodulator.
> 
> Heh.  I wonder if that could be possible given my description above.  :-)

Probably not. :)

> > Your corrective action here would be to attenuate the incoming RF signal
> > with either an inline attenuator, or with additional, properly
> > terminated, splitters.
> 
> Indeed.
> 
> Thanks sooooo much for all of the input here.


No problem.

Regards,
Andy

Re: HVR-1600 QAM recordings with slight glitches in them

[Andy Walls]

On Sat, 2012-04-28 at 14:36 -0400, Brian J. Murrell wrote:
> One more question...
> 
> On 12-04-28 10:56 AM, Andy Walls wrote:
> >
> > So I see SNR values from 0x138 to 0x13c ( 31.2 dB to 31.6 dB ) when you
> > have problems.  For 256-QAM cable signals, I think that is considered
> > marginal.  
> 
> I've never gotten my mind around SNRs and dBs, etc.  Generally speaking,
> am I looking for these "snr" values to go up or down (i.e. closer to 0
> or further away) to make my signal better?

Higher SNR is better:
Higher SNR => lower probability of bit errors
Lower SNR => higher probability of bit errors

SNR in dB = 10 log (S/N)

S : Received signal power in Watts
N : Noise power at measurement point in Watts

A logarithmic scale (dB) is used to express the quantities in values
that are easier for people to comprehend and deal with.  Gains and
losses in dB are additive.

-3 dB corresponds to a drop by a factor of 1/2:  10 * log(1/2) = -3.01
+3 dB corresponds to a gain by a factor of 2:    10 * log(2)   =  3.01

Regards,
Andy

> Cheers,
> b.

Re: HVR-1600 QAM recordings with slight glitches in them

[Brian J. Murrell]

[-- Attachment #1: Type: text/plain, Size: 971 bytes --]

On 12-04-28 04:39 PM, Brian J. Murrell wrote:
> I typically have one more splitter downstream from that 3 way splitter
> which is a 4 way splitter to feed all of the tuners on my Mythtv box and
> introducing that splitter reduces the SNR at the HVR-1600 to between
> "13c" and "13e" (31.6 - 31.8 dB).

Interestingly enough, I moved the Myth backend to it's usual home, in
the basement, right next to the incoming cable signal and replaced that
25' run that I had going to where it was temporarily with a smaller, say
10' run (of RG-59 so still room for improvement) and my SNR at the
HVR-1600, even after all of the splitters is now "015c" or 34.8 dB.

I'm still going to go replacing all of that RG-59 with shorter, custom
made lengths of RG6 cables.  I can't go "too short" when making those
can I or would even a 6-12 inch cable be perfectly fine?  I'm thinking
of the runs between that last 4 way splitter and the tuners in the Myth
backend.

b.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: HVR-1600 QAM recordings with slight glitches in them

[Rudy Zijlstra]

On 29-04-12 00:21, Brian J. Murrell wrote:
> On 12-04-28 04:39 PM, Brian J. Murrell wrote:
>> I typically have one more splitter downstream from that 3 way splitter
>> which is a 4 way splitter to feed all of the tuners on my Mythtv box and
>> introducing that splitter reduces the SNR at the HVR-1600 to between
>> "13c" and "13e" (31.6 - 31.8 dB).
> Interestingly enough, I moved the Myth backend to it's usual home, in
> the basement, right next to the incoming cable signal and replaced that
> 25' run that I had going to where it was temporarily with a smaller, say
> 10' run (of RG-59 so still room for improvement) and my SNR at the
> HVR-1600, even after all of the splitters is now "015c" or 34.8 dB.
>
> I'm still going to go replacing all of that RG-59 with shorter, custom
> made lengths of RG6 cables.  I can't go "too short" when making those
> can I or would even a 6-12 inch cable be perfectly fine?  I'm thinking
> of the runs between that last 4 way splitter and the tuners in the Myth
> backend.
>
> b.
>
Brian,

There is no minimum cable length for RF. Although for practical reasons 
i rarely go below 30 cm (1 ').
It should be possible for you to buy "drop cables" which have a length 
of 1m5 (about 5') and are commonly used in HE to connect equipment.

screw-on F-connectors are another source of problems. Crimping 
F-connectors are best, but those need a fitting crimp tool.

Cheers,


Rudy

Re: HVR-1600 QAM recordings with slight glitches in them

[Brian J. Murrell]

[-- Attachment #1: Type: text/plain, Size: 780 bytes --]

On 12-04-29 03:02 AM, Rudy Zijlstra wrote:
> Brian,

Hi Rudy,

> There is no minimum cable length for RF. Although for practical reasons
> i rarely go below 30 cm (1 ').

Indeed.  Especially with RG6 they can get a bit stiff.

> It should be possible for you to buy "drop cables" which have a length
> of 1m5 (about 5') and are commonly used in HE to connect equipment.

Yeah, I'm trying to reduce the cable "nest" and I only have about 6"
between the back of the equipment and the wall, where the splitter will
be so 1' cables will probably do the trick.

> screw-on F-connectors are another source of problems.

Yes.

> Crimping
> F-connectors are best, but those need a fitting crimp tool.

Indeed, and I have one.  :-)

Thanks for the info!

b.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: HVR-1600 QAM recordings with slight glitches in them

[Devin Heitmueller]

On Sun, Apr 29, 2012 at 4:27 PM, James Courtier-Dutton
<james.dutton@gmail.com> wrote:
> There are two measurements.
> 1) SNR.
> This is a measure of the quality of the signal. Bigger is better. 30dB is a
> good value. Spliters and amplifiers should only slightly reduce the SNR
> value.

30 dB for ClearQAM is actually a very marginal SNR.  It caps out at 40
dB, and as Andy pointed out, it's a logarithmic scale.  On a good
cable plant, you should expect an SNR between 35 and 40.  Anything
below 32 and you're very likely to have significant error rates.
Don't confuse it with Over-the-Air ATSC, which will typically cap out
at 30.0 dB.

I don't know why you're not seeing valid data on femon with the 950q.
It should be printing out fine, and it's on the same 0.1 dB scale.
Try running just azap and see if the SNR is reported there.

This indeed feels like a marginal signal condition problem, and Andy's
assertion is well founded that the mxl5005/s5h1409 isn't exactly the
best combo compared to more modern tuners and demodulators (Hauppauge
switched to the tda18271 and s5h1411 for the newer revision of the
HVR-1600).  The Linux driver support should be on-par with Windows
though in terms of performance as I did a bunch of work some time back
to analyze the differences which resulted in some fixes.

Cheers,

Devin

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

Re: HVR-1600 QAM recordings with slight glitches in them

[Brian J. Murrell]

[-- Attachment #1: Type: text/plain, Size: 2685 bytes --]

On 12-04-29 08:09 PM, Devin Heitmueller wrote:
> 
> I don't know why you're not seeing valid data on femon with the 950q.
> It should be printing out fine, and it's on the same 0.1 dB scale.
> Try running just azap and see if the SNR is reported there.

$ azap -c ~/last-channel-scan.prev 100-3
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
tuning to 651000000 Hz
video pid 0x0000, audio pid 0x07c1
status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 | 
status 1f | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
...

Doesn't seem to be useful values.
 
> This indeed feels like a marginal signal condition problem, and Andy's
> assertion is well founded that the mxl5005/s5h1409 isn't exactly the
> best combo compared to more modern tuners and demodulators (Hauppauge
> switched to the tda18271 and s5h1411 for the newer revision of the
> HVR-1600).

Well, now that the coax connector has come loose on the digital tuner
(i.e. it spins albeit with enough friction that screwing a coax connector
on and off is still quite doable but it would seem spins enough to have
broken the connection internally and thus the tuner no longer receives
signal) maybe it's time to cut my losses here and just consider this
HVR-1600 garbage.  I've wasted more than enough time on what's turned
out to just be marginal hardware.  ~sigh~

I wonder if I can still find the supported hardware rev. of the KWorld
UB-435 around anywhere.  The local computer store has one for $40 but
they have no way of telling me if it's the new hardware rev. or the old
one.

Cheers,
b.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: HVR-1600 QAM recordings with slight glitches in them

[Devin Heitmueller]

Oh, and as Andy suggested, please provide a sample of the azap or
femon output for the HVR-1600 where you don't grep out the lines, so
we can see what the SNR looks like before and after the point in time
when the uncorrectable errors occurred.

Devin

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

Re: HVR-1600 QAM recordings with slight glitches in them

[Devin Heitmueller]

Resending with the ML back on the cc:.

On Wed, May 2, 2012 at 11:29 PM, Brian J. Murrell <brian@interlinx.bc.ca> wrote:
> On 12-04-29 08:09 PM, Devin Heitmueller wrote:
>>
>> I don't know why you're not seeing valid data on femon with the 950q.
>> It should be printing out fine, and it's on the same 0.1 dB scale.
>> Try running just azap and see if the SNR is reported there.
>
> $ azap -c ~/last-channel-scan.prev 100-3
> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
> tuning to 651000000 Hz
> video pid 0x0000, audio pid 0x07c1
> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
> status 1f | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> status 1f | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
> ...
>
> Doesn't seem to be useful values.

That actually is useful data.  The SNR of 0x190 means 40.0 dB (which
is a max good signal).  The fact that it sometimes goes between 0x190
and 0x000 is actually a bug in the driver I discovered a couple of
months ago but haven't submitted a patch for.  In fact it's strong
enough that you might actually be over driving the tuner and may wish
to try an attenuator.

This suggests the signal is fine (although I would probably run it for
longer and make sure you don't see intermittent UNC conditions).  And
you're using the exact same cabling for the 1600 as you are for the
950q above?

Also, which version of the HVR-1600 is this?  The one with the
mxl5005s or the tda18271?  You can check the dmesg output to tell (and
if you cannot tell, please pastebin the dmesg output so I can look).

Devin

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

Re: HVR-1600 QAM recordings with slight glitches in them

[Andy Walls]

Devin Heitmueller <dheitmueller@kernellabs.com> wrote:

>Resending with the ML back on the cc:.
>
>On Wed, May 2, 2012 at 11:29 PM, Brian J. Murrell
><brian@interlinx.bc.ca> wrote:
>> On 12-04-29 08:09 PM, Devin Heitmueller wrote:
>>>
>>> I don't know why you're not seeing valid data on femon with the
>950q.
>>> It should be printing out fine, and it's on the same 0.1 dB scale.
>>> Try running just azap and see if the SNR is reported there.
>>
>> $ azap -c ~/last-channel-scan.prev 100-3
>> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
>> tuning to 651000000 Hz
>> video pid 0x0000, audio pid 0x07c1
>> status 00 | signal 0000 | snr 0000 | ber 00000000 | unc 00000000 |
>> status 1f | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 |
>FE_HAS_LOCK
>> status 1f | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
>FE_HAS_LOCK
>> status 1f | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 |
>FE_HAS_LOCK
>> status 1f | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 |
>FE_HAS_LOCK
>> status 1f | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 |
>FE_HAS_LOCK
>> status 1f | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 |
>FE_HAS_LOCK
>> status 1f | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
>FE_HAS_LOCK
>> status 1f | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 |
>FE_HAS_LOCK
>> status 1f | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 |
>FE_HAS_LOCK
>> status 1f | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 |
>FE_HAS_LOCK
>> status 1f | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
>FE_HAS_LOCK
>> status 1f | signal 0190 | snr 0190 | ber 00000000 | unc 00000000 |
>FE_HAS_LOCK
>> status 1f | signal 0190 | snr 0000 | ber 00000000 | unc 00000000 |
>FE_HAS_LOCK
>> status 1f | signal 0000 | snr 0190 | ber 00000000 | unc 00000000 |
>FE_HAS_LOCK
>> ...
>>
>> Doesn't seem to be useful values.
>
>That actually is useful data.  The SNR of 0x190 means 40.0 dB (which
>is a max good signal).  The fact that it sometimes goes between 0x190
>and 0x000 is actually a bug in the driver I discovered a couple of
>months ago but haven't submitted a patch for.  In fact it's strong
>enough that you might actually be over driving the tuner and may wish
>to try an attenuator.
>
>This suggests the signal is fine (although I would probably run it for
>longer and make sure you don't see intermittent UNC conditions).  And
>you're using the exact same cabling for the 1600 as you are for the
>950q above?
>
>Also, which version of the HVR-1600 is this?  The one with the
>mxl5005s or the tda18271?  You can check the dmesg output to tell (and
>if you cannot tell, please pastebin the dmesg output so I can look).
>
>Devin
>
>-- 
>Devin J. Heitmueller - Kernel Labs
>http://www.kernellabs.com
>--
>To unsubscribe from this list: send the line "unsubscribe linux-media"
>in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

IIRC, Brian had a MXL5005s/S5H1409 variant.

I think Brian might have a bad cable or connector or splitter in the run feeding the hvr1600.  Just a guess...

Regards,
Andy

Re: HVR-1600 QAM recordings with slight glitches in them

[Brian J. Murrell]

[-- Attachment #1: Type: text/plain, Size: 1627 bytes --]

On 12-05-03 11:37 AM, Andy Walls wrote:
> Devin Heitmueller <dheitmueller@kernellabs.com> wrote:
>>
>> Also, which version of the HVR-1600 is this?  The one with the
>> mxl5005s or the tda18271?  You can check the dmesg output to tell (and
>> if you cannot tell, please pastebin the dmesg output so I can look).

http://brian.interlinx.bc.ca/hvr-1600-dmesg

> IIRC, Brian had a MXL5005s/S5H1409 variant.

The latter part sounds familiar from femon and gnutv.


> I think Brian might have a bad cable or connector or splitter in the run feeding the hvr1600.


The same 4-way splitter fed the HVR-950Q and the HVR-1600 and cables
were swapped just about every way they could be to try to get the
HVR-1600's SNR up.

But as I mentioned before, it's now completely non-functional due to the
coax connector on the card having become loose enough to turn (with some
effort, so screwing an female F-connector on/off was still quite
doable).  Perhaps it was marginal before due to that same problem.  I
guess I will never know... unless I try cracking this thing open and
reconnecting whatever has gotten disconnected -- if Hauppage won't RMA
it for me.  They seem to be pretty silent about that now though after an
initial e-mail exchange.

If not, I've got my eye on a KWorld UB435-Q if I can determine that it's
a hardware rev. 1 unit somehow since the store doesn't want to take it
out of the box to check for me.  It's less than half the price of an
HVR-950Q at $40, as much as I would love to stay loyal with Hauppage --
this coax connector on my HVR-1600 coming loose, aside.

Cheers,
b.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: HVR-1600 QAM recordings with slight glitches in them

[Devin Heitmueller]

On Thu, May 3, 2012 at 12:06 PM, Brian J. Murrell <brian@interlinx.bc.ca> wrote:
> But as I mentioned before, it's now completely non-functional due to the
> coax connector on the card having become loose enough to turn (with some
> effort, so screwing an female F-connector on/off was still quite
> doable).  Perhaps it was marginal before due to that same problem.  I
> guess I will never know... unless I try cracking this thing open and
> reconnecting whatever has gotten disconnected -- if Hauppage won't RMA
> it for me.  They seem to be pretty silent about that now though after an
> initial e-mail exchange.

If the F-connector is loose, that can *definitely* explain the
problem.  Let me know if you have problems getting an RMA.

> If not, I've got my eye on a KWorld UB435-Q if I can determine that it's
> a hardware rev. 1 unit somehow since the store doesn't want to take it
> out of the box to check for me.  It's less than half the price of an
> HVR-950Q at $40, as much as I would love to stay loyal with Hauppage --
> this coax connector on my HVR-1600 coming loose, aside.

Even if they take it out of the box, you would be unlikely to be able
to determine the revision without plugging it in to something and
checking the USB ID.

Devin

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