[mythtv] in progress recordings and new scheduler

[Bruce Markey]

David Engel wrote:
> On Sun, Mar 14, 2004 at 06:35:16PM -0800, Bruce Markey wrote:
> 
>>recordings. However, if a slave restarts, the master does
>>nothing to check to see if the slave should be recording.
> 
> 
> The new ability to reactivate recordings should make this easier to
> handle.

I really like the reactivate button and have tested and used
it. However it doesn't come into play here for a couple reasons.
If the master is up'n'nunnin' but the slave crashes and is
restarted, the scheduler is run when the slave reconnects but
it makes no attempt to restart the recording. Instead, it simply
continues to show that the state is Recording for the cardid of
the slave's card and therefore there is no reactivate button.
However, the slave has not been told to record since the restart
and is not recording.

The next idea would be to select "Stop recording" so that it
could be reactivated. But after hitting "Stop recording" there
is no recording to stop so the state remains as "Recording".
I still have to restart the master to get the slave recordings
started again.


>   If the slave should be doing something when it connects the
> master can reactivate the recording and have the slave record the
> remaining part of the program.  That still leaves some boundary cases
> to consider, though.  How and how soon does the master know when a
> slave goes away abnormally?  Should partial recordings be counted when
> checking for duplicates?

Opps, you snuck in a different state change. What to do when
a slave disconnects is a different question than what to do
when a slave connects.

When a slave disconnects it might be a crash or it might be a
network outage and the slave may be merrily recording away.
It might be possible to have the master reassign the recording
for the missing slave to another available card but this is
full of pitfalls, messy and, believe it or not, I don't care 8-).

If a slave was there when a recording started, it's up to that
slave to finish the job, IMHO. If the slave backend fails and
is restarted manually or automatically, it announces to the
master that it has connected and the master re-runs the scheduler
to account for the current number of cards. At this point,
recordings that should be in progress but aren't should be
restarted.

>>The master marks the state as "B". It might be slick if the slaves
>>could report not only that they're busy but what SCI/channel they
>>are recording so that the master can verify that it is recording
>>what it's supposed to.
> 
> 
> I think the slaves can already do that.  The master just has to ask.

I think it would be a good idea. It would allow the master
to discover the state of uninterrupted slaves when the master
restarts and would be more useful that the unknown Busy state.

A related issue is that if the master restarts, the current
scheduler run may not match previous assignments. For example,
say a 6:00-6:30 show beats NBA Basketball from 6:00-8:30. If
the master restarts at 7:15, NBA may win card 1 from now through
8:30. However, the uninterrupted slave for card 2 will still be
recording bball but the scheduler will not know this and start
recording NBA on card 1 also.

I just did a quick test and verified that this does happen. 

So the master should probably ask each slave what it's up to
each time a slave connects (when the master starts, there is a
two second interval for the slaves to check-in before the first
scheduler run). The scheduler could then account for recordings
in progress while scheduling then restart anything that should
be recording but isn't.

--  bjm