[mythtv-users] Channel scanner won't find a specific channel

Sun Feb 7 23:55:34 UTC 2016

     A. On Sun, 2016-02-07 at 15:41 -0500, David Parker wrote:
> On Sun, Feb 7, 2016 at 2:49 AM, HP-mini <blm-ubunet at slingshot.co.nz>
> wrote:
>         On Sat, 2016-02-06 at 22:27 +0000, John Pilkington wrote:
>         > A bit more info:
>         >
>         > ionice -c3 mythtranscode -m --video -i WFXVsample1.mpg -o
>         > WFXVsample1_mtr.mpg
>         >
>         > A few complaints in the log (below) and no mention of text
>         or
>         > unidentified streams.
>         >
>         > Both play smoothly as videos in 0.28-beta, but with stuff
>         like this:
>         >
<snip>
>         
>         That 60p sample plays fine here (Videos) in master with ffmpeg
>         CPU &
>         VDPAU.
>         I did not try the file with dummy recorder.
>         I noticed that the OP was using ffmpeg CPU decode.
>         CPU decode here uses 35% on mid-range core2duo, no jitter
>         problems (OSD
>         playback meter).
> 
> 
> Thanks for the info.  I just monitored the CPU usage on my MythTV box
> while a few different videos were playing, and it was consistently in
> the 5%-10% range except for the moment the video started.
> 
> 
> This is what I see when I play the sample I posted, while it's being
> all weird and choppy:
> 
> 
> 2016-02-07 15:28:16.094440 I  Player(2): FPS:   30.22 Mean: 33090
> Std.Dev:  1930 CPUs: 101% 100% 
> 2016-02-07 15:28:22.128193 I  Player(2): FPS:   39.61 Mean: 25243
> Std.Dev:  8344 CPUs: 8% 9% 6% 
> 2016-02-07 15:28:28.678682 I  Player(2): FPS:   36.49 Mean: 27405
> Std.Dev:  7991 CPUs: 7% 7% 8% 
> 2016-02-07 15:28:35.579324 I  Player(2): FPS:   34.64 Mean: 28871
> Std.Dev:  7393 CPUs: 5% 6% 7% 
> 2016-02-07 15:28:40.979659 I  Player(2): FPS:   44.26 Mean: 22593
> Std.Dev:  7991 CPUs: 8% 9% 9% 
> 2016-02-07 15:28:46.680104 I  Player(2): FPS:   41.93 Mean: 23849
> Std.Dev:  8265 CPUs: 8% 8% 7% 
> 2016-02-07 15:28:53.130608 I  Player(2): FPS:   37.05 Mean: 26987
> Std.Dev:  8102 CPUs: 8% 7% 9% 
> 2016-02-07 15:28:59.281147 I  Player(2): FPS:   38.86 Mean: 25732
> Std.Dev:  8317 CPUs: 7% 9% 8%
> 
> 
> Note the 30-40 FPS, when it's supposed to be 60.
> 
> 
> This is what happens when I play the 30 FPS recording from a different
> channel, which plays fine:
> 
> 
> 2016-02-07 15:29:20.983329 I  Player(2): FPS:   28.97 Mean: 34520
> Std.Dev: 19131 CPUs: 266% 100% 100% 
> 2016-02-07 15:29:25.017039 I  Player(2): FPS:   29.50 Mean: 33894
> Std.Dev:  3016 CPUs: 12% 8% 10% 
> 2016-02-07 15:29:29.000619 I  Player(2): FPS:   29.88 Mean: 33472
> Std.Dev:  1534 CPUs: 8% 8% 9% 
> 2016-02-07 15:29:33.101074 I  Player(2): FPS:   29.02 Mean: 34454
> Std.Dev:  4190 CPUs: 9% 7% 9% 
> 2016-02-07 15:29:37.067977 I  Player(2): FPS:   30.00 Mean: 33332
> Std.Dev:    75 CPUs: 10% 9% 11% 
> 2016-02-07 15:29:41.034890 I  Player(2): FPS:   30.00 Mean: 33332
> Std.Dev:    73 CPUs: 8% 9% 10% 
> 2016-02-07 15:29:45.051846 I  Player(2): FPS:   29.63 Mean: 33753
> Std.Dev:  2633 CPUs: 10% 8% 10% 
> 2016-02-07 15:29:49.118807 I  Player(2): FPS:   29.26 Mean: 34173
> Std.Dev:  3669 CPUs: 9% 8% 9%
> 
> 
> And this is what happens when I play the transcoded version of the
> problematic video:
> 
> 
> 2016-02-07 15:30:22.154231 I  Player(2): FPS:   59.51 Mean: 16803
> Std.Dev:  1911 CPUs: 100% 100% 100% 
> 2016-02-07 15:30:26.137813 I  Player(2): FPS:   60.00 Mean: 16665
> Std.Dev:    95 CPUs: 11% 11% 10% 
> 2016-02-07 15:30:30.138094 I  Player(2): FPS:   59.75 Mean: 16735
> Std.Dev:  1079 CPUs: 11% 12% 12% 
> 2016-02-07 15:30:34.138641 I  Player(2): FPS:   59.75 Mean: 16736
> Std.Dev:  1064 CPUs: 10% 12% 13% 
> 2016-02-07 15:30:38.122093 I  Player(2): FPS:   60.01 Mean: 16664
> Std.Dev:    96 CPUs: 11% 11% 11% 
> 2016-02-07 15:30:42.105712 I  Player(2): FPS:   60.00 Mean: 16665
> Std.Dev:    97 CPUs: 11% 12% 13% 
> 2016-02-07 15:30:46.089376 I  Player(2): FPS:   60.00 Mean: 16665
> Std.Dev:    92 CPUs: 12% 11% 16% 
> 2016-02-07 15:30:50.073166 I  Player(2): FPS:   60.00 Mean: 16666
> Std.Dev:   140 CPUs: 15% 12% 12%
> 
> 
> It maintains 60 FPS and there are no playback issues at all.  So there
> seems to be something about recorded video from this channel which
> causes a massive drop in framerate on this particular PC, and whatever
> this issue is, it's corrected by mythtranscode.  Any thoughts?  Just a
> wild guess, but is it possible the CPU in this PC is missing an
> instruction set which is needed for efficiently decoding the video
> stream from this channel?
> 
> 
> The continued help is much appreciated.
> 
<snip>

The jitter is still too high even for the 30p "good" recording.
Your system does not seem to have enough I/O bandwidth.
Or your display refresh rate or resolution/mode is non-ideal.
Would need to see the whole FE log file.

The original recording 18Mb/sec is on the high side.

Can you use / try h/w assisted video decode?

Maybe mythtranscode is dropping the bitrate or changing slice refresh B
frames into I frames (never used it here, never had mpeg2 video).
Normal broadcast OTA digital has uniform bitrate (no I frame spikes).

I'd follow Stuart's advise to check the playback jitterometer buffers..

HTH.