[mythtv-users] Strange time counter issue with recent NBC OTA recordings

[Gabe Rubin]

On Thu, Nov 14, 2013 at 4:09 PM, Jim Stichnoth <stichnot at gmail.com> wrote:

> On Thu, Nov 14, 2013 at 3:43 PM, Tom Dexter <digitalaudiorock at gmail.com>wrote:
>
> On Thu, Nov 14, 2013 at 3:47 AM, John Pilkington <J.Pilk at tesco.net> wrote:
>> > On 14/11/13 03:42, Tom Dexter wrote:
>> >>
>> >> I record New York City OTA stations and am running MythTV 0.25.3.
>> >>
>> >> For the last couple of weeks, all my NBC (channel 4.1) recordings have
>> >> had strange things happening with the progress time counters.  The
>> >> shows record and play just fine...nothing missing or anything else
>> >> like that.  What's odd is that, while a one hour show will in fact
>> >> show as having a length of 1:00:00 or thereabouts, the progress while
>> >> it's playing will go from 0 to 50 minutes.  Also, if I jump to 50
>> >> minutes or anything past that, it ends up at the end of the show.
>> >>
>> >> NBC has had a long history of mixing frame rates and other odd stuff.
>> >> If I remember correctly, in earlier versions of MythTV things like
>> >> this that used to cause MythTV to report incorrect show lengths.  I
>> >> figured this may be something similar.
>> >>
>> >> Anyone else noticing anything like this?
>> >>
>> >> Thanks
>> >> Tom
>> >
>> >
>> > This sounds like seektable trouble.  Does mythcommflag --rebuild improve
>> > matters?
>> >
>> > ISTR that commits that probably aren't in 0.25.3 store time marks as
>> well as
>> > frame numbers in or around the seektables to handle variable frame
>> rates.
>> > Doesn't explain why it's suddenly happening for you, though.
>> >
>> > John P
>> >
>>
>> It seemed a little unlikely to me that this would be a seektable
>> issue, given that it's happening specifically (and only) on NBC
>> recordings starting a couple of weeks ago.  Also, just like previous
>> frame rate issues I recall in the past with NBC is does *not* occur
>> with things like reality shows, but rather only with things like
>> dramas were they tend to do this sort of stuff.
>>
>> However as a test I decided to try a seektable rebuild on one of the
>> shows with this issue.  Whatever is going on with the frame rates or
>> whatever there is apparently enough to trip up that reuild.  The
>> progress went up to a bit over 80% (exactly 50 minutes / 60 minutes),
>> and failed with this:
>>
>> mythcommflag --rebuild --chanid 1041 --starttime 20131111220100
>> 2013-11-14 17:59:00.590753 C  mythcommflag version: fixes/0.25
>> [vmythtv-0.25.3] www.mythtv.org
>> 2013-11-14 17:59:00.590830 C  Qt version: compile: 4.8.4, runtime: 4.8.4
>> MythTV Commercial Flagger, building seek table for:
>>     The Blacklist - General Ludd
>> Rebuild started at Thu Nov 14 17:59:00 2013
>> Rebuild completed at Thu Nov 14 18:01:09 2013
>> 2013-11-14 18:01:09.077420 E  decoding error
>>             eno: Input/output error (5)
>>
>> Strange one...like I said...progress counter aside, these shows
>> actually play perfectly.
>>
>> 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.
>
>
Does this mean recordings affected by this in versions < .27 will be fixed
once upgraded to .27 or that seek tables need to be rebuilt?

Incidentally, I see a similar, yet different issue with Brooklyn Nine-Nine
(a fox show), where it shows the correct status time but indicates its an
hour-long show as opposed to a 30 minute show.  But the progress bar shows
the accurate elapsed time (recording via firewire from an HD box).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20131114/0dbb57bc/attachment.html>