[mythtv] [mythtv-commits] Ticket #799: DTV recordings sometimes show doubled recording length

[Tom Dexter]

>* On Sun Sep 30, 2007 at 04:27:40PM -0000, MythTV wrote:
>> #799: DTV recordings sometimes show doubled recording length
>
>> Comment(by Tom Dexter <digitalaudiorock[at]hotmail.com>):
>
>totalLength is also set in NuppelVideoPlayer::SetLength.
>
>When a recording ends, the recorder (TVRec) sends a DONE_RECORDING
>event. This event contains the card number and the recording
>length. This gets received by the TV class (tv_play.cpp) and
>TV::customEvent calls NuppelVideoPlayer::SetLength().
>
>This is how the totalLength is getting set without you seeing it
>in your debugging code.
>
>I think the reason that the length is getting hosed up is that
>the DVB recorder (and possibly others) doesn't know/set the frame
>rate of the video that it is recording, so it defaults to the
>29.97 that is set in the construction of RecorderBase.
>
>TVRec::TeardownRecorder() does this:
>
>filelen = (int)((float)GetFramesWritten() / GetFramerate());
>
>TVRec::GetFramerate() calls RecorderBase::GetFrameRate() which
>just returns Recorderbase::video_frame_rate.
>
>RecoderBase::video_frame_rate is only set by the DVB recorder
>in RecorderBase's constructor.
>
>I see there is even a comment about this in the code in tv_rec.cpp.
>It's not specifically about the double length, but saying the way
>it calculates the length is wrong because of changing framerates
>in DTV recordings.
>
>// This is a bad way to calculate this, the framerate
>// may not be constant if using a DTV based recorder.
>filelen = (int)((float)GetFramesWritten() / GetFramerate());
>
>The only accurate way for the player to know how long the recording
>is in this case is for the recorder to keep track of it which it
>doesn't currently. The recorder could look at the frame rate and
>do a calculation based on that, but that is not foolproof since
>the frame rate could change in the recording (and does in some
>places where commercials are at different rates than the show).
>
>The player knows the _current_ frame rate, so the numbers
>will jump around when you are playing a video that changes
>frame rates in the middle. Calculations based on these changing
>frame rates are another big issue that hasn't been solved yet.
>The player doesn't handle them in a lot of cases, and neither does
>the commercial flagger.
>
>--
>Chris

Sorry for not replying properly to this.  I didn't belong to the list
at the time it was posted.

Thanks for the explanation of this and all the related issues.  I'm
curious on one thing here:  What situation is it that actually
requires that tv_play call NuppelVideoPlayer::SetLength using the
length reported by the recorder when changing from WatchingRecording
to a WatchingPreRecorded state?  I imagine there is, but in my
situation anyway (all DVB recordings) simply commenting out that
SetLength call in tv_play seems to prevent this bug with no ill
affects, as NuppelVideoPlayer already has a correct length (or
reasonably correct) based on the DB and the remote encoder.

The situation where stations use different frame rates certainly
sounds like an ugly one.  I've been noticing the incorrect total
lengths on NBC broadcasts (53 minutes rather than an hour for example)
from that one.  Is this something these stations have just started
doing recently?  Sounds like a pretty awful practice to me.

Thanks again.
Tom