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

Stuart Auchterlonie stuarta at squashedfrog.net
Sun Feb 7 22:13:19 UTC 2016


On 06/02/16 04:02, David Parker wrote:
> Hello,
> 
> I've made a ~100 MB sample available here:
> 
> https://drive.google.com/file/d/0BypQdHvM5DGjeF9jT1NzcDVEbjA/view?usp=sharing
> [1]
> 
> This is the first 54 seconds of the recording which I have been testing
> with this whole time.  This file is choppy when played through MythTV,
> but plays fine everywhere else.  It even plays just fine in the Google
> player which shows in browser when you first click the link.
> 
> I've tried the other suggestions (thanks for those, guys!), and here are
> my results:
> 

So this sample plays perfectly for me. It is as the data below reports
mpeg2 running at 60fps.

You need to pull up the "playback data" screen and see where your issues
are with this recording.

When watching the recording hit 'M', then navigate to "Playback" then
"Playback Data".

Several key data points to check.
- Storage to buffer value should be significantly above buffer to
  decoder value
- "Available Buffer" (should really say "used buffer") should be as
  high as possible, around ~99% in the optimal case.
- Frames decoded / available, you want the frames decoded figure to
  be maxed out and stay there, if it goes low / zero, you've run out
  of decoded frames to display = stutter

Look at this data on one of your "good" recordings first, to get a
feel for what the data looks like when it's working properly. That'll
help you identify what isn't right on the "faulty" recording.


Regards
Stuart Auchterlonie

> 1. Running "femon -H" shows the same information regardless of what
> channel I am watching.  It just says this:
> 
>     status SCVYL | signal  92% | snr   0% | ber -1 | unc 0 | FE_HAS_LOCK
>     status SCVYL | signal  92% | snr   0% | ber -1 | unc 0 | FE_HAS_LOCK
>     status SCVYL | signal  92% | snr   0% | ber -1 | unc 0 | FE_HAS_LOCK
> 
> Note sure what the -1 BER value means, and Google wasn't much help.  But
> the other channels work fine and still had that value, so it seems like
> it's ok (that could be a gross misjudgment on my part, though).
> 
> 2. The original recording and the 100 MB sample I extracted both stutter
> terribly in MythTV.  But the version created using "mythtranscode -m"
> plays perfectly.  Any idea why?
> 
> Thanks John for the mythtranscode tip.  This is a bit less of a
> show-stopper now, since it looks like I can record from this channel and
> then run a mythtranscode job to fix the video.  I still don't know why
> this particular channel causes such trouble, though, but only for MythTV.
> 
>     Thanks!
>     Dave
> 
> [1] Note for future readers: not a permanent link.
> 
> On Fri, Feb 5, 2016 at 11:53 AM, John Pilkington <J.Pilk at tesco.net
> <mailto:J.Pilk at tesco.net>> wrote:
> 
>     On 05/02/16 16:08, David Parker wrote:
> 
>         On Fri, Feb 5, 2016 at 9:33 AM, David Parker
>         <parker.david.a at gmail.com <mailto:parker.david.a at gmail.com>
>         <mailto:parker.david.a at gmail.com
>         <mailto:parker.david.a at gmail.com>>> wrote:
> 
>             On Fri, Feb 5, 2016 at 7:33 AM, John Pilkington
>         <J.Pilk at tesco.net <mailto:J.Pilk at tesco.net>
>             <mailto:J.Pilk at tesco.net <mailto:J.Pilk at tesco.net>>> wrote:
> 
>                 On 05/02/16 04:35, David Parker wrote:
> 
>                 <snip>
> 
>                     I haven't had a chance to try the lossless transcode
>         yet,
>                     but I did
>                     verify that this is only a MythTV issue.  I recorded a
>                     program from this
>                     troublesone channel, and it has consistently had choppy
>                     audio and video
>                     every time I've watched the recording in MythTV.  I
>         copied
>                     the mpeg file
>                     from the "recorded" directory to another PC with far
>         worse
>                     hardware and
>                     an older version of Debian.  The video played
>         flawlessly in
>                     Xine on the
>                     other PC.
> 
> 
>                 Have you looked at the frontend log, perhaps with -v
>         playback?
>                 There are other tools you could use to examine the file
>         (vlc,
>                 mediainfo) but it doesn't sound as if your problems are with
>                 faulty or noisy capture.
> 
>                 There are ways of filtering out unwanted streams;  mythutil
>                 --help shows several tools for mpeg-ts files (which I
>         have never
>                 tried) and I routinely use a script to do it - but it
>         would be
>                 better to get the recorder to do that rather than try to fix
>                 things later.  There are a few options in mythtvsetup.
> 
>                 HP-mini had some good suggestions too, but I won't copy
>         them here.
> 
> 
>                     What's really got me scratching my head is the fact that
>                     this one single
>                     channel is choppy when I watch it live through
>         MythTV, too.
>                     So for some
>                     reason, MythTV is having issues with the data coming
>         from
>                     the tuner for
>                     this one particular channel.  Same channel which MythTV
>                     couldn't even
>                     find until I told it where to look.
> 
>                     The channel is crystal clear on the TV.
> 
> 
>             Thanks for the suggestions, guys.  I'll give these a try.  I
>         want to
>             avoid troubleshooting this as an issue with the stream itself,
>             though.  As I said before, if I take the mpeg recorded by
>         MythTV and
>             play it in another player (such as Xine), it's fine.  So
>         this seems
>             to only be an issue with MythTV's playback of the recording, and
>             only seems to be with recordings from that particular
>         channel.  It's
>             very strange.
> 
>             I'll try some of these suggestions and post back my results.
> 
>             Thanks!
> 
> 
>         As a quick first test, I tried playing a few videos through
>         MythTV with
>         "-v playback" set, as John suggested.
> 
>         For a problematic recording, the following lines were logged by
>         avformatdecorder.cpp which may be useful (timestamps and thread info
>         removed for brevity):
> 
>         CoreContext avformatdecoder.cpp:980 (InitByteContext) - AFD: Buffer
>         size: 32768 streamed 0 seekable 1
>         CoreContext avformatdecoder.cpp:2099 (ScanStreams) - AFD: Stream
>         #0, has
>         id 0x6f codec id MPEG2VIDEO, type Video, bitrate 0 at 0x308b360
>         CoreContext avformatdecoder.cpp:2099 (ScanStreams) - AFD: Stream
>         #1, has
>         id 0x70 codec id AC3, type Audio, bitrate 384000 at 0x30708e0
>         CoreContext avformatdecoder.cpp:2141 (ScanStreams) - AFD: codec
>         AC3 has
>         6 channels
>         CoreContext avformatdecoder.cpp:2198 (ScanStreams) - AFD:
>         Looking for
>         decoder for AC3
>         CoreContext avformatdecoder.cpp:2632 (OpenAVCodec) - AFD: Opened
>         codec
>         0x3084b40, id(AC3) type(Audio)
>         CoreContext avformatdecoder.cpp:2099 (ScanStreams) - AFD: Stream
>         #2, has
>         id 0x71 codec id AC3, type Audio, bitrate 192000 at 0x3084fa0
>         CoreContext avformatdecoder.cpp:2141 (ScanStreams) - AFD: codec
>         AC3 has
>         2 channels
>         CoreContext avformatdecoder.cpp:2198 (ScanStreams) - AFD:
>         Looking for
>         decoder for AC3
>         CoreContext avformatdecoder.cpp:2632 (OpenAVCodec) - AFD: Opened
>         codec
>         0x3095900, id(AC3) type(Audio)
>         CoreContext avformatdecoder.cpp:2340 (ScanStreams) - AFD: Trying to
>         select best video track
>         CoreContext avformatdecoder.cpp:2376 (ScanStreams) - AFD:
>         Selected track
>         #0 (id 0x6f codec id MPEG2VIDEO, type Video, bitrate 500000 at
>         0x308b360)
>         CoreContext avformatdecoder.cpp:2511 (ScanStreams) - AFD: Using
>         0 CPUs
>         for decoding
>         CoreContext avformatdecoder.cpp:1556 (InitVideoCodec) - AFD:
>         InitVideoCodec() 0x308b640 id(MPEG2VIDEO) type (Video).
>         CoreContext avformatdecoder.cpp:1460 (normalized_fps) - AFD:
>         Selected
>         FPS is 59.9401 (avg 59.9401 codec 59.9401 container 90000
>         estimated 59.9401)
>         CoreContext avformatdecoder.cpp:1918 (UpdateATSCCaptionTracks) -
>         AFD:
>         EIA-608 caption service #1 is in the Unknown language.
>         CoreContext avformatdecoder.cpp:2523 (ScanStreams) - AFD: Using
>         ffmpeg
>         for video decoding
>         CoreContext avformatdecoder.cpp:2632 (OpenAVCodec) - AFD: Opened
>         codec
>         0x308b640, id(MPEG2VIDEO) type(Video)
>         CoreContext avformatdecoder.cpp:1359 (OpenFile) - AFD: Position
>         map found
>         CoreContext avformatdecoder.cpp:1364 (OpenFile) - AFD: Successfully
>         opened decoder for file:
>         "/mnt/data/recorded/1115_20160204170000.mpg".
>         novideo(0)
> 
>         Then the video began playing, choppy as always.  The log was
>         filled with
>         lines like this:
> 
>         CoreContext mythplayer.cpp:1967 (AVSync) - Player(0): Video is
>         3.2288
>         frames ahead of audio,
>                                  doubling video frame interval to slow down.
>         RingBuffer ringbuffer.cpp:1037 (run) -
>         RingBuf(/mnt/data/recorded/1115_20160204170000.mpg):
>         safe_read(... at 786432, 32768) -> 32768, took 0 ms (1000Mbps) avg
>         187 ms
>         CoreContext mythplayer.cpp:1967 (AVSync) - Player(0): Video is
>         3.50501
>         frames ahead of audio,
>                                  doubling video frame interval to slow down.
>         RingBuffer ringbuffer.cpp:1037 (run) -
>         RingBuf(/mnt/data/recorded/1115_20160204170000.mpg):
>         safe_read(... at 819200, 32768) -> 32768, took 0 ms (1000Mbps) avg
>         187 ms
>         CoreContext mythplayer.cpp:1967 (AVSync) - Player(0): Video is
>         3.45711
>         frames ahead of audio,
>                                  doubling video frame interval to slow down.
>         RingBuffer ringbuffer.cpp:1037 (run) -
>         RingBuf(/mnt/data/recorded/1115_20160204170000.mpg):
>         safe_read(... at 851968, 32768) -> 32768, took 0 ms (1000Mbps) avg
>         187 ms
>         CoreContext mythplayer.cpp:1967 (AVSync) - Player(0): Video is
>         3.1661
>         frames ahead of audio,
>                                  doubling video frame interval to slow down.
>         RingBuffer ringbuffer.cpp:1037 (run) -
>         RingBuf(/mnt/data/recorded/1115_20160204170000.mpg):
>         safe_read(... at 884736, 32768) -> 32768, took 0 ms (1000Mbps) avg
>         187 ms
>         RingBuffer ringbuffer.cpp:1037 (run) -
>         RingBuf(/mnt/data/recorded/1115_20160204170000.mpg):
>         safe_read(... at 917504, 65536) -> 65536, took 0 ms (1000Mbps) avg
>         187 ms
>         RingBuffer ringbuffer.cpp:1037 (run) -
>         RingBuf(/mnt/data/recorded/1115_20160204170000.mpg):
>         safe_read(... at 983040, 32768) -> 32768, took 0 ms (1000Mbps) avg
>         187 ms
>         RingBuffer ringbuffer.cpp:1037 (run) -
>         RingBuf(/mnt/data/recorded/1115_20160204170000.mpg):
>         safe_read(... at 1015808, 32768) -> 32768, took 0 ms (1000Mbps) avg
>         187 ms
>         CoreContext mythplayer.cpp:1967 (AVSync) - Player(0): Video is
>         3.25613
>         frames ahead of audio,
>                                  doubling video frame interval to slow down.
>         RingBuffer ringbuffer.cpp:1037 (run) -
>         RingBuf(/mnt/data/recorded/1115_20160204170000.mpg):
>         safe_read(... at 1048576, 65536) -> 65536, took 0 ms (1000Mbps) avg
>         187 ms
>         CoreContext mythplayer.cpp:1967 (AVSync) - Player(0): Video is
>         3.34328
>         frames ahead of audio,
>                                  doubling video frame interval to slow down.
>         CoreContext mythplayer.cpp:1967 (AVSync) - Player(0): Video is
>         3.15387
>         frames ahead of audio,
>                                  doubling video frame interval to slow down.
> 
>         Then I played a video recorded off a different HD channel, which
>         plays
>         fine.  The avformatdecoder.cpp messages for this file were as
>         follows:
> 
>         CoreContext avformatdecoder.cpp:980 (InitByteContext) - AFD: Buffer
>         size: 32768 streamed 0 seekable 1
>         CoreContext avformatdecoder.cpp:2099 (ScanStreams) - AFD: Stream
>         #0, has
>         id 0x79 codec id MPEG2VIDEO, type Video, bitrate 0 at 0x33ed0a0
>         CoreContext avformatdecoder.cpp:2099 (ScanStreams) - AFD: Stream
>         #1, has
>         id 0x7a codec id AC3, type Audio, bitrate 384000 at 0x33deb60
>         CoreContext avformatdecoder.cpp:2141 (ScanStreams) - AFD: codec
>         AC3 has
>         2 channels
>         CoreContext avformatdecoder.cpp:2198 (ScanStreams) - AFD:
>         Looking for
>         decoder for AC3
>         CoreContext avformatdecoder.cpp:2632 (OpenAVCodec) - AFD: Opened
>         codec
>         0x3589be0, id(AC3) type(Audio)
>         CoreContext avformatdecoder.cpp:2099 (ScanStreams) - AFD: Stream
>         #2, has
>         id 0x7b codec id AC3, type Audio, bitrate 128000 at 0x35c1f20
>         CoreContext avformatdecoder.cpp:2141 (ScanStreams) - AFD: codec
>         AC3 has
>         2 channels
>         CoreContext avformatdecoder.cpp:2198 (ScanStreams) - AFD:
>         Looking for
>         decoder for AC3
>         CoreContext avformatdecoder.cpp:2632 (OpenAVCodec) - AFD: Opened
>         codec
>         0x33ffe80, id(AC3) type(Audio)
>         CoreContext avformatdecoder.cpp:2340 (ScanStreams) - AFD: Trying to
>         select best video track
>         CoreContext avformatdecoder.cpp:2376 (ScanStreams) - AFD:
>         Selected track
>         #0 (id 0x79 codec id MPEG2VIDEO, type Video, bitrate 500000 at
>         0x33ed0a0)
>         CoreContext avformatdecoder.cpp:2511 (ScanStreams) - AFD: Using
>         0 CPUs
>         for decoding
>         CoreContext avformatdecoder.cpp:1556 (InitVideoCodec) - AFD:
>         InitVideoCodec() 0x360c000 id(MPEG2VIDEO) type (Video).
>         CoreContext avformatdecoder.cpp:1460 (normalized_fps) - AFD:
>         Selected
>         FPS is 29.97 (avg 29.97 codec 29.97 container 90000 estimated 29.97)
>         CoreContext avformatdecoder.cpp:1918 (UpdateATSCCaptionTracks) -
>         AFD:
>         EIA-708 caption service #1 is in the English language.
>         CoreContext avformatdecoder.cpp:2523 (ScanStreams) - AFD: Using
>         ffmpeg
>         for video decoding
>         CoreContext avformatdecoder.cpp:2632 (OpenAVCodec) - AFD: Opened
>         codec
>         0x360c000, id(MPEG2VIDEO) type(Video)
>         CoreContext avformatdecoder.cpp:1359 (OpenFile) - AFD: Position
>         map found
>         CoreContext avformatdecoder.cpp:1364 (OpenFile) - AFD: Successfully
>         opened decoder for file:
>         "/mnt/data/recorded/1241_20160204160000.mpg".
>         novideo(0)
> 
>         There were a handful of those "doubling video frame interval to slow
>         down" messages logged within the first second that the video was
>         playing, but after that, all of the messages while it played
>         looked like
>         this:
> 
>         RingBuffer ringbuffer.cpp:1037 (run) -
>         RingBuf(/mnt/data/recorded/1241_20160204160000.mpg):
>         safe_read(... at 3145728, 32768) -> 32768, took 0 ms (1000Mbps) avg
>         187 ms
>         RingBuffer ringbuffer.cpp:1037 (run) -
>         RingBuf(/mnt/data/recorded/1241_20160204160000.mpg):
>         safe_read(... at 3178496, 32768) -> 32768, took 0 ms (1000Mbps) avg
>         187 ms
>         RingBuffer ringbuffer.cpp:1037 (run) -
>         RingBuf(/mnt/data/recorded/1241_20160204160000.mpg):
>         safe_read(... at 3211264, 32768) -> 32768, took 0 ms (1000Mbps) avg
>         187 ms
>         RingBuffer ringbuffer.cpp:1037 (run) -
>         RingBuf(/mnt/data/recorded/1241_20160204160000.mpg):
>         safe_read(... at 3244032, 98304) -> 98304, took 0 ms (1000Mbps) avg
>         187 ms
>         RingBuffer ringbuffer.cpp:1037 (run) -
>         RingBuf(/mnt/data/recorded/1241_20160204160000.mpg):
>         safe_read(... at 3342336, 65536) -> 65536, took 0 ms (1000Mbps) avg
>         187 ms
> 
>         I noticed that the AC3 audio bitrate of the choppy video is 192000,
>         while that of the stable video is 128000.  I also noticed that the
>         selected framerate of the choppy video was ~60 FPS, whereas that
>         of the
>         stable video was ~30 FPS.  Still, it seems that 60 FPS and an audio
>         bitrate of 192000 should be handled easily by this PC (AMD
>         Phenom II X3
>         2.8 GHz, 4 GB RAM).
> 
>         Thanks!
>         Dave
> 
> 
>     Well, the ~60 Hz vs ~30 Hz video frame rate offers a plausible
>     explanation; and both your samples seem to have prime audio rates of
>     384 kbs, so I guess that's standard.  I doubt that I can do much
>     more now, but a sample would probably be of interest  :-)
> 
>     Cheers,
> 
>     John
> 
> 
> 
>     _______________________________________________
>     mythtv-users mailing list
>     mythtv-users at mythtv.org <mailto:mythtv-users at mythtv.org>
>     http://lists.mythtv.org/mailman/listinfo/mythtv-users
>     http://wiki.mythtv.org/Mailing_List_etiquette
>     MythTV Forums: https://forum.mythtv.org
> 
> 
> 
> 
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
> 



More information about the mythtv-users mailing list