[mythtv-users] Fwd: Playback of recordings end prematurely

[Michael T. Dean]

On 09/02/2008 07:00 AM, Julian Cerruti wrote:
> On Wed, Aug 27, 2008 at 10:42 PM, Michael T. Dean wrote:
>> On 08/27/2008 07:12 PM, Julian Cerruti wrote:
>>     
>>> I wonder if someone could give me some advice on how to go about
>>> resolving this issue.
>>>
>>> For a long while (I don't know when this started, probably about a
>>> year ago) all the recordings from shows end earlier than their real
>>> length when played from the mythTV "watch recordings" page. For
>>> example, when I record a program of 30 minutes length, playback shows
>>> a duration of 23:47. I noticed that the recording is indeed longer
>>> than that, for example, by playing back the .mpg file externally using
>>> mplayer. Also, depending on how playback is configured in mythTV, it
>>> would continue playing past 23:47, only the progress counter would
>>> stop moving (it remains in 23:47 of 23:47) and also many navigation
>>> functions (FFWD, RWD) are lost. Also is commercial auto-skip.

Somehow I missed that last statement in the original post.  IME, playing 
beyond the "end" of the recording should not happen in a properly 
functioning Myth box.  Instead, for the issue I was talking about, the 
30-minute recording whose length shows as 23:47 should just take 30:00 
to play back (with the progress counter moving slightly slower than real 
time--i.e. the seconds increment every 1.26 seconds).

If your system keeps playing past the displayed end time, it means you 
probably have a problem with the data in your database (i.e. invalid 
starttime and/or endtime values and possibly broken seektables).  The 
fact that the data for every new recording is wrong seems to indicate a 
time problem on your system.  If you have multiple backends, you 
probably have different times on the different systems (they should 
really be synchronized with ntp).  If you have only a single, you're 
probably losing ticks somewhere (I think some versions of the ivtv 
driver can cause this with some configurations).

I highly recommend running optimize_mythdb.pl as a first step, then 
trying to figure out if anything untoward is going on with your clocks.

>>> In fact:
>>> I have a slight suspicion that in many cases, commercial flagging is
>>> not worken as well as it could because of this.
>>>
>>> A couple more details: I notice that the "end time" reported by the
>>> mythTV player is suspiciously similar for similar length recordings.
>>> Something like: 30 mins -> 23:47; 1hr -> 47:58; etc. Also, I verified
>>> the guide data is reasonably OK (this time discrepancy doesn't seem to
>>> come from there). I am currently running mythtv 0.21 from mythbuntu
>>> 8.04.1 out-of-the-box. I use a Hauppauge 500 with ivtv 1.1.0. Only
>>> unusual setting is that because of my location (Argentina) I'm using
>>> Pal-Nc and a custom-written XMLTV grabber.
>>>       

And, again, I missed that important statement.  I don't think the issue 
I described should happen with a PVR-x50-created recording.  If so, it 
would be due to the difference between a 12- and 15-frame GOP length, 
but I'd think more PAL users would have said something about the 
inaccuracy.  So, if that is the issue, I'd assume your ivtv 
configuration needs fixing.  (But, as an NTSC/15-frame/GOP user, I'm not 
able to help with that.)

>>> Any advice on how to go about diagnosing this or tips to try to fix it
>>> would be greatly appreciated.
>>>       
>> The approach Myth uses to calculate duration of the recordings is
>> imprecise with certain types of shows (i.e. shows broadcast with one
>> frame rate while part--such as commercials--use another).  The "issue"
>> is purely cosmetic but fixing it properly is a /lot/ of work, so fixing
>> it has been very low priority (for the couple of years the plan has been
>> in place to fix it).
>>
>> There are tickets related to the issue and it will eventually be fixed.
>> Until then, just get used to how your local channels work and "adjust"
>> in your head.  Soon, when someone says, "Let's meet in an hour," you'll
>> show up 1 hour 8 minutes and 34 seconds later and get accused of being
>> late, but you'll know--from watching your TV shows--that 52:30 is really
>> one hour, so you're actually on time.  :)
>>     
> Thanks for the background. Could you please point me to the tickets that
> reference this problem? Who knows, maybe one day, in a parallel universe, I
> will have time, skill and thoroughness enough that I may want to take a
> crack at it. Or, it could just satisfy my technical curiosity to understand
> what the problem is in more detail.

#799 and #1088 , for what it's worth.  I didn't mention them before 
because most anyone who reads through them (actually most anyone would 
only read a couple statements on them before they) would think they 
don't apply.

But, now, I'm thinking you weren't describing the problem I thought.  
Sorry for the false lead.  It's still possible that the display issue is 
related to MARK_GOP_START (and a 12- vs 15-frames/GOP distinction), but 
if your system continues to play beyond the "end" of the recording, 
there's something more happening, too, and you can probably fix it.

Mike