[mythtv] Possible bug when using override with postroll

[Bruce Markey]

Chris Pinkham wrote:
> Replies in context....
> 
> 
>>However, the *roll recordings didn't go as expected. The
>>program info for the recording shows the original times rather
>>than the effective times. The filename are also based on
>>the orig times.
> 
> 
> The filename has to match the times in recorded and oldrecorded unless we
> start storing the pre/postroll info in recorded which doesn't make sense.

I mis-spoke in several ways. I was in a hurry to go to dinner.
Of course recorded and filename must match, I was just trying
confirm that the orig times were being used in places where the
rec* times should have been used. 


> I'd prefer the filenames and program info displayed when viewing the
> scheduled recordings to be the actual start/stop times (after applying
> pre/postroll).

I agree. I think it is most useful to the user to see times
that reflect when the recording happened and reflect the
correct duration.

...
> I'm wondering if it's best to keep startts/endts as the actual start/stop
> times and instead of having recstartts/recendts, have
> origstartts/origendts.  Then for the places that need the original times,
> they coud use the origstartts/origendts, but everywhere else could use
> startts/endts which are the actual start/end times after applying
> pre/postroll.   I think the key thing is passing around both sets which is
> currently done, it just may make sense to reverse where they're stored.

I would prefer that. Here was another blunder while rushing;
both set are passed, it's a question of which sets are used
where.

>>During the preroll time, the playbox showed the early recording
>>in progress in white. After the orig starttime they were
>>highlighted in yellow.
> 
> 
> This is that "shows in preroll show in a different color" stuff going on.


Just another data point where the wrong timestamp is being
used =).

>>I could go on with details but I think what it might boil
>>down to is that maybe both sets of timestamps need to be
>>available and used in the appropriate places. The orig times
>>to check against the program and override table, and the
>>effective times to be used for conflict resolution and the
>>real record start and end times. 
> 
> 
> This is why I'm thinking reverse the two, so starts/endts are the
> actual start/stop times which are used in most places, then have
> origstartts/origendts for use in checking against the program and
> override tables.  

If that would mean that *roll would work as it did yesterday
and recordoverride would always match on orig* times, then I'm
all for it.

>>I liked the way *roll worked yesterday and I like the way
>>overrides are tracked today. Can either of you see a way to use
>>the effective times for recording the way they were yesterday?
> 
> 
> Want to have your cake and eat it too huh? :)

I want the most powerful, flexible, reliable, expandable,
multituner, multiscreen (monitor or TV) networked DVR system
imaginable. Years ahead of anything we'll see from commercial
vendors. I wanna record two games, Survivor, Friends and CNN
at the same time and FF thru any of them from where ever I happen
to be sitting (or reclining =). I want to watch this much talked
about Wright Brothers "Nova" episode tonight and I want to know
who shot JFK (but that will have to wait until the three hour
Frontline special next week on Lee Harvey Oswald). I also want
to know when Isaac's birthday is and how to send him an
appropriate gift.

However, for now I want to make "NBA Basketball" an anywhere
record, High Quality, low rank, with 90min postroll (I have
lots of tuners ;-) and X out the rebroadcasts and games I know
I won't watch. This is very close to being possible =).

--  bjm