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

[David Parker]

On Feb 6, 2016 5:33 AM, "John Pilkington" <J.Pilk at tesco.net> wrote:
>
> On 06/02/16 04:52, David Parker wrote:
>>
>> On Fri, Feb 5, 2016 at 11:02 PM, David Parker <parker.david.a at gmail.com
>> <mailto:parker.david.a at gmail.com>> 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:
>>
>>     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.
>>
>>
>> Left out one thing.  Also tried watching the channel but pausing for 30
>> seconds to let it buffer a bunch of the stream.  No difference, playback
>> was still choppy in the buffered video (which I guess makes sense
>> because it's choppy in recorded video, too).
>>
>>      - Dave
>>
>
> Mostly it plays fine for me in 0.28-beta, both as a recording and as a
video.  The programme change at the start feels jumpy, but thereafter it's
smooth.  I've run mediainfo on the complete clip and on a clip without the
first 35 MB, and compared the outputs using diff -y
>
> There are changes in GOP setting, A/V delay and number of text streams
but nothing looks catastrophic at first glance.
>
> Playback data shows up to 30% cpu on both cores in a core2duo 2.8 GHz
i915 box.
>
> Format settings, BVOP                    : Yes                  Format
settings, BVOP                    : Yes
> Format settings, Matrix                  : Custom               Format
settings, Matrix                  : Custom
> Format settings, GOP                     : M=3, N=30          | Format
settings, GOP                     : Variable
> Codec ID                                 : 2                    Codec ID
                               : 2
>

Thanks, John.  Would you be willing to play the video in MythTV with "-v
playback" in the frontend options, and see if you get a lot of those
"Video is <n> frames ahead of audio..." messages in the log like I did?
I'm wondering if those will still show up even though it's playing smoothly.

I really appreciate everyone's help with this.

    - Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20160206/2ad68305/attachment.html>