> From: [email protected]
> To: [email protected]
> Date: Sat, 13 Feb 2010 23:05:41 -0500
> Subject: Re: [ivtv-users] hvr-1600, frame CRC mismatch - incomplete frame
> 
> On Sat, 2010-02-13 at 21:20 -0500, Kyle Lil wrote:
> > > From: [email protected]
> 
> 
> > OK, Great. So, enabling the debug messages as you described results in
> > a ton of these messages:
> > 
> > 
> > [ 1312.000257] cx18-0:  warning: failed to be awakened upon RPU
> > acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 10 msecs
> > [ 1312.500011] cx18-0:  warning: failed to be awakened upon RPU
> > acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 10 msecs
> > [ 1313.000017] cx18-0:  warning: failed to be awakened upon RPU
> > acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 10 msecs
> > [ 1315.080014] cx18-0:  warning: failed to be awakened upon RPU
> > acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 10 msecs
> > [ 1315.310061] cx18-0:  warning: failed to be awakened upon RPU
> > acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 10 msecs
> > [ 1316.330025] cx18-0:  warning: failed to be awakened upon RPU
> > acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 10 msecs
> > [ 1316.870079] cx18-0:  warning: failed to be awakened upon RPU
> > acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 10 msecs
> 
> Those aren't so bad.  These happen when we give a buffer bad to the
> CX23418 and it doesn't respond *right away*.  The cx18-0-out/n work
> handler will go to sleep waiting for a wake-up from the CX23418 via an
> IRQ.  Usually the ACK IRQ happens well within 10 msecs, but the Linux
> scheduler doesn't get around to waking up the cx18-0-out/n work handler,
> so you get this message instead when a timer ends up waking it up.
> 
> Short story: no big deal as far as the CX23418 is concerned.
> 
> 
> On the other hand, your system load or interrupt handling latency may be
> high.
> 
> 
> > and an occasional message like this:
> > 
> > 
> > [ 1311.480015] cx18-0:  warning: sending CX18_CPU_DE_SET_MDL timed out
> > waiting 10 msecs for RPU acknowledgement
> 
> This is an instance when the CX23418 firmware actually didn't ACK us
> within 10 msecs of us sending an empty buffer back.  This means the
> firmware was very busy at the moment, or was ignoring us because it
> didn't make sense for us to be giving it a buffer at that time (i.e. we
> were stopping the streaming). This isn't a big deal unless it happens
> often.
> 
> 
> > Executing mplayer as you described now attempts to fill the cache and
> > play video, but is taking forever to fill the cache. To get 0.1% (8192
> > bytes) takes 13 seconds. It hasn't yet completely filled the cache,
> > but it has given a couple of error messages saying
> > "dvb_streaming_read, attempt N. 6 failed with errno 0 when reading x
> > bytes". It is now at about 10%
> 
> That's certainly not what should happen normally.  With a good stream
> (or good signal?), it should get up to 19% cache fill and start playing
> within about 5 seconds.
> 
> Like so:
> 
> $ time mplayer dvb://WTTG\ DT -cache 8192
> MPlayer SVN-r28461-4.3.2 (C) 2000-2009 MPlayer Team
> CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (Family: 15, Model:
> 43, Stepping: 1)
> mplayer: could not open config files /home/andy/.lircrc and /etc/lircrc
> mplayer: No such file or directory
> Failed to read LIRC config file ~/.lircrc.
> 
> Playing dvb://WTTG DT.
> dvb_tune Freq: 605028615
> Cache fill: 19.14% (1605632 bytes)   
> TS file format detected.
> VIDEO MPEG2(pid=49) AUDIO A52(pid=52) NO SUBS (yet)!  PROGRAM N. 0
> VIDEO:  MPEG2  1280x720  (aspect 3)  59.940 fps  19000.0 kbps (2375.0
> kbyte/s)
> ==========================================================================
> Opening video decoder: [mpegpes] MPEG 1/2 Video passthrough
> VDec: vo config request - 1280 x 720 (preferred colorspace: Mpeg PES)
> Could not find matching colorspace - retrying with -vf scale...
> Opening video filter: [scale]
> The selected video_out device is incompatible with this codec.
> Try appending the scale filter to your filter list,
> e.g. -vf spp,scale instead of -vf spp.
> VDecoder init failed :(
> Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
> Selected video codec: [ffmpeg2] vfm: ffmpeg (FFmpeg MPEG-2)
> ==========================================================================
> ==========================================================================
> Opening audio decoder: [liba52] AC3 decoding with liba52
> Using SSE optimized IMDCT transform
> Using MMX optimized resampler
> AUDIO: 48000 Hz, 2 ch, s16le, 448.0 kbit/29.17% (ratio: 56000->192000)
> Selected audio codec: [a52] afm: liba52 (AC3-liba52)
> ==========================================================================
> AO: [pulse] 48000Hz 2ch s16le (2 bytes per sample)
> Starting playback...
> VDec: vo config request - 1280 x 720 (preferred colorspace: Planar YV12)
> VDec: using Planar YV12 as output csp (no 0)
> Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
> VO: [xv] 1280x720 => 1280x720 Planar YV12 
> A:49184.3 V:49184.7 A-V: -0.335 ct: -0.065  40/ 40 126%  6%  5.1% 4 0
> 14%       
> Exiting... (Quit)
> 
> real  0m4.303s
> user  0m0.604s
> sys   0m0.148s
> 
> 
> 
> With a poor stream due to weak signal, I get something like this with
> ATSC:
> 
> $ time mplayer dvb://WJLA-HD -cache 8192
> MPlayer SVN-r28461-4.3.2 (C) 2000-2009 MPlayer Team
> CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (Family: 15, Model:
> 43, Stepping: 1)
> mplayer: could not open config files /home/andy/.lircrc and /etc/lircrc
> mplayer: No such file or directory
> Failed to read LIRC config file ~/.lircrc.
> 
> Playing dvb://WJLA-HD.
> dvb_tune Freq: 177028615
> Cache fill:  8.79% (737280 bytes)   dvb_streaming_read, attempt N. 6
> failed with errno 0 when reading 844 bytes
> Cache fill:  8.79% (737280 bytes)   dvb_streaming_read, attempt N. 5
> failed with errno 0 when reading 844 bytes
> Cache fill: 19.34% (1622016 bytes)   
> TS file format detected.
> VIDEO MPEG2(pid=49) AUDIO A52(pid=52) NO SUBS (yet)!  PROGRAM N. 0
> VIDEO:  MPEG2  1280x720  (aspect 3)  59.940 fps  17782.8 kbps (2222.8
> kbyte/s)
> ==========================================================================
> Opening video decoder: [mpegpes] MPEG 1/2 Video passthrough
> VDec: vo config request - 1280 x 720 (preferred colorspace: Mpeg PES)
> Could not find matching colorspace - retrying with -vf scale...
> Opening video filter: [scale]
> The selected video_out device is incompatible with this codec.
> Try appending the scale filter to your filter list,
> e.g. -vf spp,scale instead of -vf spp.
> VDecoder init failed :(
> Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
> Selected video codec: [ffmpeg2] vfm: ffmpeg (FFmpeg MPEG-2)
> ==========================================================================
> ==========================================================================
> Opening audio decoder: [liba52] AC3 decoding with liba52
> Using SSE optimized IMDCT transform
> a52: CRC check failed!  
> Using MMX optimized resampler
> AUDIO: 48000 Hz, 2 ch, s16le, 384.0 kbit/25.00% (ratio: 48000->192000)
> Selected audio codec: [a52] afm: liba52 (AC3-liba52)
> ==========================================================================
> AO: [pulse] 48000Hz 2ch s16le (2 bytes per sample)
> Starting playback...
> a52: error at resampling
> a52: CRC check failed!  
> a52: error at resampling
> a52: CRC check failed!  
> a52: error at resampling
> a52: CRC check failed!  
> a52: error at resampling
> a52: CRC check failed!  
> a52: error at resampling
> a52: CRC check failed!  
> a52: error at resampling
> VDec: vo config request - 1280 x 720 (preferred colorspace: Planar YV12)
> VDec: using Planar YV12 as output csp (no 0)
> Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
> VO: [xv] 1280x720 => 1280x720 Planar YV12 
> [mpeg2video @ 0xac4480]skipped MB in I frame at 65 5
> [mpeg2video @ 0xac4480]Warning MVs not available
> [mpeg2video @ 0xac4480]concealing 1984 DC, 1984 AC, 1984 MV errors
> a52: CRC check failed!  1481.898 ct:  0.000   1/  1 ??% ??% ??,?% 0 0
> 1%        
> a52: error at resampling
> a52: CRC check failed!  
> a52: error at resampling
> a52: CRC check failed!  
> a52: error at resampling
> a52: CRC check failed!  
> a52: error at resampling
> a52: CRC check failed!  
> a52: error at resampling
> [mpeg2video @ 0xac4480]concealing 2000 DC, 2000 AC, 2000 MV errors
> a52: CRC check failed!    2.479 ct:  0.002   2/  2 ??% ??% ??,?% 0 0
> 0%         
> a52: error at resampling
> a52: CRC check failed!  
> [mpeg2video @ 0xac4480]concealing 2000 DC, 2000 AC, 2000 MV errors
> a52: CRC check failed!    2.496 ct:  0.003   3/  3 ??% ??% ??,?% 0 0
> 0%         
> a52: error at resampling
> a52: CRC check failed!  
> a52: CRC check failed!  
> a52: error at resampling
> a52: CRC check failed!  
> a52: error at resampling
> [mpeg2video @ 0xac4480]ac-tex damaged at 62 28
> [mpeg2video @ 0xac4480]Warning MVs not available
> [mpeg2video @ 0xac4480]concealing 1352 DC, 1352 AC, 1352 MV errors
> a52: CRC check failed!    3.353 ct:  0.005   4/  4 ??% ??% ??,?% 0 0
> 0%         
> a52: CRC check failed!  
> a52: error at resampling
> a52: CRC check failed!  
> a52: error at resampling
> a52: CRC check failed!  
> a52: error at resampling
> a52: CRC check failed!    3.537 ct:  0.007   5/  5 ??% ??% ??,?% 0 0
> 0%         
> a52: error at resampling
> a52: CRC check failed!  
> a52: CRC check failed!  
> a52: error at resampling
> a52: CRC check failed!  
> a52: error at resampling
> a52: CRC check failed!    3.844 ct:  0.008   6/  6 ??% ??% ??,?% 1 0
> 0%         
> a52: error at resampling
> a52: CRC check failed!  
> a52: error at resampling
> a52: CRC check failed!  
> a52: error at resampling
> A:91484.4 V:91480.1 A-V:  4.286 ct:  0.010   7/  7 ??% ??% ??,?% 2 0
> 0%         
> Exiting... (Quit)
> 
> real  0m8.538s
> user  0m0.318s
> sys   0m0.163s
> 
> 
> 
> 
> So mplayer is not very robust when dealing with streams with errors.  It
> is very good at indicating to you that you have a stream with errors
> apparently.
> 
> Windows might be able to better render smoothly through the errors.
> BTW, what does the Windows utility form Hauppauge show for signal
> strength?  (I haven't used it, I just heard that Hauppauge provides one
> with its osftware.)
> 
> 
> 
> The only other thing I can think of is that the cable signal could be
> slightly overamplified so it is overdriving the front end of the tuner
> and introducing these errors.
> 
> You might want to put an attenuator in line to reduce the RF level a bit
> and see if that helps.  If you can't find an in-line attenuator at a
> local electronics store, here's how to build a Bridged-T attenuator from
> resistors yourself:
> 
> http://www.mail-archive.com/[email protected]/msg08735.html
> 
> I guess you would want to try a "Gain" of about -3 dB first and then -10
> dB if the problem still seems to happen.
> 
> 
> 
> And of course there's always the checklist here to go through:
> 
> http://www.ivtvdriver.org/index.php/Howto:Improve_signal_quality
> 
> 
> Regards,
> Andy
> 
> 
> _______________________________________________
> ivtv-users mailing list
> [email protected]
> http://ivtvdriver.org/mailman/listinfo/ivtv-users


OK, so it seems like we're narrowing down the problem. 
After ~25minutes of mplayer trying to fill the cache today, I get to the "TS 
file format detected" message. Then about 15 minutes later came the 
dvb_streaming_read message. It never began to show video in the 72 minutes I 
allowed it to try. 
$time mplayer "dvb://WHDH HD" -cache 8192MPlayer UNKNOWN-4.4.1 (C) 2000-2009 
MPlayer Team
Playing dvb://WHDH HD.dvb_tune Freq: 799789900Cache fill: 19.92% (1671168 
bytes)   TS file format detected.dvb_streaming_read, attempt N. 6 failed with 
errno 0 when reading 1896 bytes
I was able to use vlc to view the stream. It also had video glitches, but with 
less noticeable audio buzzing accompanying them. VLC spit out the following 
messages around the same time as the glitches. I deleted a bunch of the 
libdvbpsi PMT decoder messages, b/c they are generated constantly (and I think 
they're related to vlc's inability to deal with subchannels). The TS 
discontinuity errors at the beginning occurred at approximately the same time 
as the glitch. The QPainter messages came in the seconds following the glitch.  
libdvbpsi error (PMT decoder): invalid section (table_id == 0xc1)libdvbpsi 
error (PSI decoder): TS discontinuity (received 2, expected 4) for PID 
0libdvbpsi error (PSI decoder): TS discontinuity (received 8, expected 7) for 
PID 48libdvbpsi error (PMT decoder): invalid section (table_id == 
0xc0)libdvbpsi error (PSI decoder): TS discontinuity (received 12, expected 11) 
for PID 49libdvbpsi error (PMT decoder): invalid section (table_id == 
0xc0)libdvbpsi error (PSI decoder): TS discontinuity (received 5, expected 4) 
for PID 50libdvbpsi error (PMT decoder): invalid section (table_id == 
0xc0)libdvbpsi error (PSI decoder): TS discontinuity (received 4, expected 3) 
for PID 0libdvbpsi error (PMT decoder): invalid section (table_id == 
0xc0)libdvbpsi error (PMT decoder): invalid section (table_id == 0xc0)libdvbpsi 
error (PMT decoder): invalid section (table_id == 0xc0)libdvbpsi error (PMT 
decoder): invalid section (table_id == 0xc0)libdvbpsi error (PMT decoder): 
invalid section (table_id == 0xc1)QPainter::begin: Paint device returned engine 
== 0, type: 1libdvbpsi error (PMT decoder): invalid section (table_id == 
0xc0)libdvbpsi error (PMT decoder): invalid section (table_id == 0xc1)libdvbpsi 
error (PMT decoder): invalid section (table_id == 0xc1)libdvbpsi error (PMT 
decoder): invalid section (table_id == 0xc0)libdvbpsi error (PMT decoder): 
invalid section (table_id == 0xc0)libdvbpsi error (PMT decoder): invalid 
section (table_id == 0xc0)QPainter::begin: Paint device returned engine == 0, 
type: 1libdvbpsi error (PMT decoder): invalid section (table_id == 
0xc0)libdvbpsi error (PMT decoder): invalid section (table_id == 
0xc0)QPainter::begin: Paint device returned engine == 0, type: 
1QPainter::begin: Paint device returned engine == 0, type: 1libdvbpsi error 
(PMT decoder): invalid section (table_id == 0xc0)libdvbpsi error (PMT decoder): 
invalid section (table_id == 0xc0)libdvbpsi error (PMT decoder): invalid 
section (table_id == 0xc0)libdvbpsi error (PMT decoder): invalid section 
(table_id == 0xc0)libdvbpsi error (PMT decoder): invalid section (table_id == 
0xc1)

I'm not sure if this offers any more clues, but I figured I'd post it just in 
case. 
Previously I'd had the tuner connected at the end of additional splitters and 
devices, but I shortened the chain in troubleshooting. I'll try attenuating the 
signal again to see if that helps. I hadn't consider the possibility that the 
cable signal might exceed the devices input limits.
Thanks again for all your ideas, Kyle 

                                          
_________________________________________________________________
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/201469230/direct/01/
_______________________________________________
ivtv-users mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-users

Reply via email to