<div dir="auto"><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Thu, Aug 13, 2020, 3:11 AM John Pilkington <<a href="mailto:johnpilk222@gmail.com">johnpilk222@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 13/08/2020 04:28, Stephen Worthington wrote:<br>
> On Wed, 12 Aug 2020 13:47:04 -0500, you wrote:<br>
> <br>
>> On Mon, Aug 10, 2020 at 4:39 AM John Pilkington <<a href="mailto:johnpilk222@gmail.com" target="_blank" rel="noreferrer">johnpilk222@gmail.com</a>><br>
>> wrote:<br>
>><br>
>>><br>
>>> That's an intriguing idea, and as you say it could be decoder-dependent.<br>
>>>    But it might be worth looking at the audio readahead setting:<br>
>>><br>
>>> Frontend setup > Video > Playback > Advanced Playback Settings ><br>
>>>     Audio read ahead (ms)<br>
>>><br>
>>> "Increase this value if audio cuts out frequently....."<br>
>>><br>
>>> Default is 100 ms.  On my GT 710 box it's at 400 ms.  I suppose I did that.<br>
>>><br>
>>> John P<br>
>>><br>
>><br>
>> Using multiple steps, I tried using HandBrake to transcode the example<br>
>> video to h.264,  swapped the original file with the h.264 version, rebuilt<br>
>> the seek tables for the h.264 doppelganger, ran a full mythcommflag pass on<br>
>> it to detect commercial breaks, and changed audio from 5.2 to stereo.  None<br>
>> of these worked, but I did notice that the h.264 file was easily 1/3 the<br>
>> size of the original.  My conclusion is to just watch the troublesome<br>
>> recordings on the BE/FE and/or re-record them now that I'm using an<br>
>> (external) infiniTV 6 instead of a pair of PVR-500 cards.  Besides, if/when<br>
>> I break down and upgrade my MythTV version, things may clear up. ?<br>
>><br>
>> In any case, a big thank you to all for the many suggestions.  They were<br>
>> all worth a try.<br>
> <br>
> Running mythcommflag to re-do the commercial breaks does not rebuild<br>
> the seek table.  If you want to rebuild the seek table, which is what<br>
> works for me, you need to do "mythcommflag --rebuild", and then after<br>
> that if you want the commercial flagging, run mythcommflag again to do<br>
> that.<br>
<br>
I don't know if after all that action you still have the original file <br>
playable on one of your frontends.  If so, you could try a 'lossless' <br>
mythtranscode --mpeg2<br>
<br>
Do a mythcommflag --rebuild first.  Then you could, if you wish, <br>
establish a cutlist.  Or just go ahead and do the cutting later.   I <br>
haven't used mythtranscode recently, but it ought to work.<br></blockquote></div><div dir="auto"><br></div><div dir="auto">Other than using a different tool to transcode, I'm not sure why it might make a difference, but anything is worth a try. Hopefully I can test that later today.  I also need to try the audio readahead adjustment, although, IIRC, the playback <span style="font-family:sans-serif">doesn't just drop/lose the audio, it </span>either freezes up completely or stutters (like going into slow-motion) -- can't recall which at the moment.</div><div dir="auto"><div data-smartmail="gmail_signature" style="font-family:sans-serif" dir="auto"><br>-- <br>Craig.</div></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div>