<div dir="ltr">On Thu, Nov 14, 2013 at 3:43 PM, Tom Dexter <span dir="ltr"><<a href="mailto:digitalaudiorock@gmail.com" target="_blank">digitalaudiorock@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thu, Nov 14, 2013 at 3:47 AM, John Pilkington <<a href="mailto:J.Pilk@tesco.net">J.Pilk@tesco.net</a>> wrote:<br>
> On 14/11/13 03:42, Tom Dexter wrote:<br>
>><br>
>> I record New York City OTA stations and am running MythTV 0.25.3.<br>
>><br>
>> For the last couple of weeks, all my NBC (channel 4.1) recordings have<br>
>> had strange things happening with the progress time counters. The<br>
>> shows record and play just fine...nothing missing or anything else<br>
>> like that. What's odd is that, while a one hour show will in fact<br>
>> show as having a length of 1:00:00 or thereabouts, the progress while<br>
>> it's playing will go from 0 to 50 minutes. Also, if I jump to 50<br>
>> minutes or anything past that, it ends up at the end of the show.<br>
>><br>
>> NBC has had a long history of mixing frame rates and other odd stuff.<br>
>> If I remember correctly, in earlier versions of MythTV things like<br>
>> this that used to cause MythTV to report incorrect show lengths. I<br>
>> figured this may be something similar.<br>
>><br>
>> Anyone else noticing anything like this?<br>
>><br>
>> Thanks<br>
>> Tom<br>
><br>
><br>
> This sounds like seektable trouble. Does mythcommflag --rebuild improve<br>
> matters?<br>
><br>
> ISTR that commits that probably aren't in 0.25.3 store time marks as well as<br>
> frame numbers in or around the seektables to handle variable frame rates.<br>
> Doesn't explain why it's suddenly happening for you, though.<br>
><br>
> John P<br>
><br>
<br>
</div>It seemed a little unlikely to me that this would be a seektable<br>
issue, given that it's happening specifically (and only) on NBC<br>
recordings starting a couple of weeks ago. Also, just like previous<br>
frame rate issues I recall in the past with NBC is does *not* occur<br>
with things like reality shows, but rather only with things like<br>
dramas were they tend to do this sort of stuff.<br>
<br>
However as a test I decided to try a seektable rebuild on one of the<br>
shows with this issue. Whatever is going on with the frame rates or<br>
whatever there is apparently enough to trip up that reuild. The<br>
progress went up to a bit over 80% (exactly 50 minutes / 60 minutes),<br>
and failed with this:<br>
<br>
mythcommflag --rebuild --chanid 1041 --starttime 20131111220100<br>
2013-11-14 17:59:00.590753 C mythcommflag version: fixes/0.25<br>
[vmythtv-0.25.3] <a href="http://www.mythtv.org" target="_blank">www.mythtv.org</a><br>
2013-11-14 17:59:00.590830 C Qt version: compile: 4.8.4, runtime: 4.8.4<br>
MythTV Commercial Flagger, building seek table for:<br>
The Blacklist - General Ludd<br>
Rebuild started at Thu Nov 14 17:59:00 2013<br>
Rebuild completed at Thu Nov 14 18:01:09 2013<br>
2013-11-14 18:01:09.077420 E decoding error<br>
eno: Input/output error (5)<br>
<br>
Strange one...like I said...progress counter aside, these shows<br>
actually play perfectly.<br><br></blockquote><div>For years, MythTV has been playing whack-a-mole with dealing with accurate position/duration display and seeking, for recordings with variable frame rates and discontinuous timecodes. In 0.27, that problem has been fixed "once and for all" (at least I hope). It's quite likely that your suspicion is right and your NBC affiliate is doing something new like splicing 720p ads into the 1080i show. I assume you're only seeing this for new recordings.</div>
<div><br></div><div>BTW, you always see this "error" in the mythcommflag log. This particular one just means it reached EOF.</div><div><br></div><div>Jim</div></div></div></div>