[mythtv] Re: [mythtv-commits] Re: Ticket #255: Improved scheduling of consecutive programs with pre-roll/overrecord

[Bruce Markey]

MythTV wrote:
> #255: Improved scheduling of consecutive programs with pre-roll/overrecord
> ---------------------------------------------+------------------------------
>  Reporter:  Max Barry <mythtv at maxbarry.com>  |        Owner:  gigem
>      Type:  patch                            |       Status:  new  
>  Priority:  minor                            |    Milestone:       
> Component:  mythtv                           |      Version:  head 
>  Severity:  medium                           |   Resolution:       
>        Cc:                                   |  
> ---------------------------------------------+------------------------------
> Comment (by Max Barry <mythtv at maxbarry.com>):
> 
>  As requested by David, I've modified the patch to include a setting with
>  which to control its behaviour.
> 
>  In "Utilities/Setup" -> "Setup" -> "TV Settings" -> "General" there is now
>  a dedicated OverTime page. A new setting on this page asks when the user
>  would like MythTV to apply the OverTime buffers. Options are:
> 
>  0) [Default] Apply unless it would create a conflict, require the use of
>  an additional tuner card, or require MythTV to record an earlier or later
>  showing. In other words, ignore pre-roll and overrecord unless they can be
>  honoured without affecting anything else. This is MythTV's current
>  behavior.
> 
>  1) Apply unless it would create a conflict or require the use of an idle
>  tuner. MythTV will, however, select an earlier/later showing if this
>  enables it to honour the OverTime settings.
> 
>  2) Apply unless it would create a conflict. MythTV will, however, assign
>  programs to idle tuner cards or record earlier/later showings if this is
>  necessary to capture the pre-roll/overrecord. [IMHO this should be
>  MythTV's new default behaviour.]
> 
>  3) Apply always. This turns OverTime into a hard setting, which MythTV
>  will always obey even if this means creating a conflict.
> 
>  Hopefully this makes everyone happy, by allowing users to employ the
>  OverTime setting in whichever way works best for them.
> 
>  Thanks to David for taking the time to discuss the issues with me and
>  provide guidance!


There can be a small annoyance when a recording starts. If the
scheduled time is 8pm and the recorder starts at 20:00:00, it may
take a short amount of time for the drivers to initialize, memory
alloc'ed then audio and video frames stored. More importantly, if
an external tuner is used, it may take a couple seconds for the
script to run and the STB may splash an OSD for a few seconds.
Because of this, in the early versions of myth, a "preroll" feature
was added so that at run time, the recorder could get a few
seconds of leader time so that the recorder would be 'up to speed'
by the scheduled start time. This is a Good Thing but not so
critical that it should cause back to back recordings to fail.
It's more important to record the 9pm show than it is to let
it fail just because it couldn't get a 3 or 5 second head start.
Therefore, this is ignored if the recorder is already busy when
there are consecutive recordings.

At the time, myth could only (hopefully =) schedule a show from
the listed start time to the listed end time. Because some shows
have content that falls outside of the scheduled times, some
people started using this to add minutes and added a counterpart
for the endtime. Adding a few seconds to the end can also be
useful for catching the hugging at the end of American Idol or
the loser's comments at the end of Survivor. Again, as leader
time it is not so important that it should cancel the next
recordings for a few extra seconds that will almost always be
credits, commercials, promos or the intro for the next show.
This still didn't account for Joe Schmo starting 4 minutes
late after wrestling or baseball games running an hour or hour
and a half over.

Chris Pinkham added a set a variables now called startoffset and
endoffset. These are stored in the record rules and allow the
minutes for the scheduled time to be adjusted. These are used
by the scheduler to plan how things should fit hours, days or
weeks ahead of time. These default to 0 and can be set once for
a recurring rule or for a single showing with single record or
an override. This also allows for negative offsets for things
like NBC who at the time would list start and end times at HH:59.
These offsets let users see what the plan is ahead of time and
allows them to tweak difficult situations based on what they
know and want.

A problem over the past couple years is that people often choose
to make the assumption that runtime recorder head start can be
abused as a magic substitute for planned scheduled time. The
hope is that this will always grab minutes of content that spill
outside the times in the TV listings yet not create unnecessary
conflicts. This seems to work because >98% of shows start and end
within the listed times. The extra times is cruft and when there
are back to back recordings, normally nothing is missed. But
then there is Murphy's Law. A show that is known to fall beyond
the listed time will be back to back with something else and one
or both of the shows will be cut off.

The planned schedule offsets should be used to get minutes of
content that is expected to fall outside of the TV listings times.
The runtime recorder seconds facility should be available for
their intended use without affecting the schedule.

What concerns me here is that the option 3 takes the preroll
variable and forfeits it's intended use to fill a specific need
and makes it into a more confusing duplicate of the capability
that already exists with the start/end-offset. If people want to
force all rules to record extra time by default, then a better
way to do this would be to add an option for setting the default
startoffset and endoffset. This has been discussed before because
it seems that this is what many people think they are trying to
achieve by setting large leader seconds values.

Option 0 is a must. This is the way it's supposed to work for
good reasons.

Option 1 and 2 could be made available for people who want them
but I won't recommend them and would ask that these be turned
off before answering any questions about odd scheduler behavior.
I usually have 3 (up to 5) tuners available. 1 and 2 are better
cards and have a higher input preference. Analog is available on
all five card but digital cable is only on card 2 (and 4 but it's
never needed). If back to back recordings are moved it may move an
analog show from 1 to 2 causing an overlap with a lower priority
digital show. Moving back to back recordings to other cards would
push things onto less preferred cards or would "L"ater shows for
a day or two. This for the sake of a few extra seconds that I
specifically intended to not be mandatory.

Option 3 just isn't the right thing to do. However, if there was
one wizard page that had widgets for both the default start/end-offset
minutes for new record rules used be the scheduler and widgets for
the leader time second used by the recorder at runtime, then the
help text could compare and contrast these features and help the
user understand what to expect. This could also have a widget of
options for the scheduler to work around the leader time and even
though I know I won't use these I'm sure others will.

--  bjm