<p dir="ltr">On Feb 6, 2016 5:33 AM, "John Pilkington" <<a href="mailto:J.Pilk@tesco.net">J.Pilk@tesco.net</a>> wrote:<br>
><br>
> On 06/02/16 04:52, David Parker wrote:<br>
>><br>
>> On Fri, Feb 5, 2016 at 11:02 PM, David Parker <<a href="mailto:parker.david.a@gmail.com">parker.david.a@gmail.com</a><br>
>> <mailto:<a href="mailto:parker.david.a@gmail.com">parker.david.a@gmail.com</a>>> wrote:<br>
>><br>
>> Hello,<br>
>><br>
>> I've made a ~100 MB sample available here:<br>
>><br>
>> <a href="https://drive.google.com/file/d/0BypQdHvM5DGjeF9jT1NzcDVEbjA/view?usp=sharing">https://drive.google.com/file/d/0BypQdHvM5DGjeF9jT1NzcDVEbjA/view?usp=sharing</a><br>
>> [1]<br>
>><br>
>> This is the first 54 seconds of the recording which I have been<br>
>> testing with this whole time. This file is choppy when played<br>
>> through MythTV, but plays fine everywhere else. It even plays just<br>
>> fine in the Google player which shows in browser when you first<br>
>> click the link.<br>
>><br>
>> I've tried the other suggestions (thanks for those, guys!), and here<br>
>> are my results:<br>
>><br>
>> 1. Running "femon -H" shows the same information regardless of what<br>
>> channel I am watching. It just says this:<br>
>><br>
>> status SCVYL | signal 92% | snr 0% | ber -1 | unc 0 |<br>
>> FE_HAS_LOCK<br>
>> status SCVYL | signal 92% | snr 0% | ber -1 | unc 0 |<br>
>> FE_HAS_LOCK<br>
>> status SCVYL | signal 92% | snr 0% | ber -1 | unc 0 |<br>
>> FE_HAS_LOCK<br>
>><br>
>> Note sure what the -1 BER value means, and Google wasn't much help.<br>
>> But the other channels work fine and still had that value, so it<br>
>> seems like it's ok (that could be a gross misjudgment on my part,<br>
>> though).<br>
>><br>
>> 2. The original recording and the 100 MB sample I extracted both<br>
>> stutter terribly in MythTV. But the version created using<br>
>> "mythtranscode -m" plays perfectly. Any idea why?<br>
>><br>
>> Thanks John for the mythtranscode tip. This is a bit less of a<br>
>> show-stopper now, since it looks like I can record from this channel<br>
>> and then run a mythtranscode job to fix the video. I still don't<br>
>> know why this particular channel causes such trouble, though, but<br>
>> only for MythTV.<br>
>><br>
>><br>
>> Left out one thing. Also tried watching the channel but pausing for 30<br>
>> seconds to let it buffer a bunch of the stream. No difference, playback<br>
>> was still choppy in the buffered video (which I guess makes sense<br>
>> because it's choppy in recorded video, too).<br>
>><br>
>> - Dave<br>
>><br>
><br>
> 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<br>
><br>
> There are changes in GOP setting, A/V delay and number of text streams but nothing looks catastrophic at first glance.<br>
><br>
> Playback data shows up to 30% cpu on both cores in a core2duo 2.8 GHz i915 box.<br>
><br>
> Format settings, BVOP : Yes Format settings, BVOP : Yes<br>
> Format settings, Matrix : Custom Format settings, Matrix : Custom<br>
> Format settings, GOP : M=3, N=30 | Format settings, GOP : Variable<br>
> Codec ID : 2 Codec ID : 2<br>
></p>
<p dir="ltr">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<br>
"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.</p>
<p dir="ltr">I really appreciate everyone's help with this.</p>
<p dir="ltr"> - Dave</p>