[mythtv] [mythtv-commits] Ticket #866: Record in LiveTV doesn't work if you leave LiveTV.

[Bruce Markey]

As always, my objective is to have the best DVR possible. What
I'm pondering here isn't which point of view would get more
points in a debate but what leads to the most reasonable behavior.

Daniel Kristjansson wrote:
> On Mon, 2006-01-09 at 17:46 -0800, Bruce Markey wrote:
>> MythTV wrote:
>> Kudos for making it promote to a scheduled recording at the time
>> of exiting the live player. However, unless there is some issue
>> that requires that it must be delayed, this should probably happen
>> ASAP at the time of TOGGLERECORD. This card and input will be busy
>> and this should be reflected on the conflicts page of another
>> frontend, "Preview schedule changes", --printsched, etc.
> 
>> Update: Enter live TV and press "R". Start another mythfrontend
>> or mythweb session. Go to the EPG. Single record any other show
>> in progress. At this point, the card/input have not been reserved
>> yet by the scheduler. Things are confused and not worth describing.
>> I guess it has to update when R is pressed.

See: http://cvs.mythtv.org/trac/ticket/1014

> The main reason was to avoid having to delete the rule and
> reschedule if the user toggles the recording bit an even number

The rule shouldn't be deleted. As with any other single record
that was stopped (or ran to completion for that matter) mfdb
will clear it in the morning. Even a partial record should be
allowed to have post comm flagging or automatic transcoding.
There will be a record table entry for this show eventually.
If the entry is created first and the recording is started,
stopped then restarted, GetScheduledRecording() ought to find
the same recordid for this chanid/startts.

Also, if the backend crashed between the time that the user
pressed R and before they exited, the recording would not restart
when the backend restarted. Also, there would be no record entry
to match the 'recorded' entry and file. I believe the recordid
should be created at (about) the same time as recorded.recgroup
is updated from LiveTV to Default and the scheduler informed of
the new reality.

> of times during the recording. But delaying also allows us to
> show the 'the scheduler wants to record X' dialog while we
> are in this LiveTV record mode; the reasoning being that if
> this conflicts with something important like your SO's Survivor
> episode then you'll be duly notified.

If the scheduler knows that the tuner will be busy, it can move
the upcoming recording to another card or later showing. This, I
believe is the chief benefit of marking a live show to record.

The possibility that recording the current show could cause an
unresolvable conflict is an interesting case but I'd never though
of this nor have I ever seen this mentioned in four years. This is
possible but a bit obscure.

- The live show marked to record has to extend beyond the start
of the next scheduled recording. This would be an hour show with
a recording starting on the half hour or a two hour movie with a
show starting on the next hour.

- The user is unaware of the upcoming recording. For me, I doubt
I ever go into live without knowing when my next recording is but
I can't speak for those who still think they are supposed to
channel surf.

- There is only one card available with inputs for the sources
of the live show and the upcoming scheduled show (more on this
later =).

- Live is using the same card as the scheduled show. With more
than one card, this may not be the case. I could have card 2 when
I press R and then next show is slated for 1. 1 would be the
first input choice if the scheduler started the current in progress
(this had been the case in the past) but since 2 is recording it
now, 2 is the busy card.

- If the same card is in conflict, the scheduled show doesn't have
a later showing that can be chosen.

[Also, even in the case of a single tuner, the upcoming recording
may have a later showing and would record just fine if the used
chose to 'continue watching' from the menu. The user wouldn't know
this just from seeing the pop up.]

- Finally, if the same card is in conflict and there is no alternative,
the upcoming scheduled show is preferred over the in progress show.
50-50 shot here ;-)

While the idea that the user could see the warning menu if all
these conditions come about, promoting the TOGGLERECORD to a
scheduled recording right away can actually resolve the conflict
altogether.

Let's say there is a myth system with two or more cards. Someone
in the household has scheduled "The Ladies of Dancing with the
Stars: A Barbra Walters Special" on Lifetime at 9:00 pm and has
dropped subtle hints over the past few weeks that this must record.
At 8:15, someone else is laying on the sofa (in peril of sleeping
there for the night) stumbles across "Ultimate Fighting Champion's
Muscle Cars that Rule The Galaxy" from 8-10 on SpikeTV. He (or she?)
hits "R".

As it stands at about 8:59:30 a menu pops up asking if the recording
should be canceled to continue watching, return to the menu or
watch the new show as it records (choose wisely). At 9:00, card
1 will be recording one or the other.

However, If the scheduler was informed of the UFC recordings right
away, it would schedule Baba Wawa for card 2 and record both with
no manual intervention or partial file and would keep domestic
bliss in tact.

While I've never heard of a case where "R" caused a conflict with
an scheduled recording which then never had an opportunity to record,
moving a scheduled recording to card 2 when watching card 1 has
been mentioned well over a hundred times. I've always thought
that this was the key advantage of recording from live. Make the
commitment so that the scheduler knows what is happening and can
adjust accordingly. Putting this commitment off until later doesn't
seem to me to be useful and could be the source of more awkward
problems.

The idea of having an OSD warning before committing does sound like
a good idea even though I suspect it would rarely if ever come up.
This could be done with Hal Burch's speculative scheduler used for
the "Preview schedule changes". Run a specsched with the new single
and see if a new rsConflict comes up.

When this is implemented, the reschedule should be committed as soon
as the user confirms that they do want to record. This also suggests
to me that we should build no top of code that commits the reschedule
right away in the meantime rather than working out bugs with the
commitment delayed then tearing it out later. 

--  bjm