[mythtv-users] Encoder (slave) "currently not connected" or "currently asleep"?

[Chris Pinkham]

* On Wed Nov 04, 2009 at 11:26:48AM +0000, Mike Perkins wrote:
> I was wondering about that. I have a workstation which I would contemplate 
> putting a back end in if I knew the MBE would understand the various states 
> it could be in.
> 
> 1. Me working and SBE available, manually started and stopped.

This is understood now, it's the old default state of connected/not-connected.
Technically in the code, the slave's status is sStatus_Undefined (sleep status
undefined) since it can't be put to sleep or woken up.

> 2. SBE invoked by master, recording and shut down afterwards.

This is the new sleeping capability, the master knows it can wakeup/shutdown
the slave so it's status is one of:

sStatus_Awake         - slave is awake and available for recording
sStatus_Asleep        - slave is asleep and can be awakened for recording
sStatus_FallingAsleep - slave was awake and was told to go to sleep
sStatus_Waking        - slave was asleep and the master ran the wakeup command

> 3. Powered down by me, but available if MBE requires it (woken up by WOL 
> code).

This is the new TODO item.  I want to add a way, from the command line, to
tell the master that a slave (that can be awakened) is being put to sleep.
My current implementation idea for this is to add an option to mythbackend
that causes mythbackend on the slave to connect to the master and tell it
to tell the slave mythbackend to go to sleep.  Something like this on the
slave:

	mythbackend --gotosleep

Then the master would tell the slave backend to go to sleep just like the #2
case above.  The master can never truly know if it can wakeup a slave unless
it shutdown the slave (barring any unforseen power issues).  So, the
shutdown in #3 would have to be 'run by' the master so he knows that the
slave can be awakened.  The master can't just assume that when the slave
disconnected that he can still wakeup that slave.  What if you shutdown the
slave for maintenance and don't want it powered on or it can't be powered
on.  The master can't assume it can be turned on for scheduling purposes, so
it has to assume it can't.

> Obviously, there could be times when I went to shut it down while it was 
> recording, where it would need to remain awake until the recording+optional 
> processing had finished, then shut itself down. Presumably this could be 
> achieved by the use of a cunning script. Thoughts?

One other TODO item is to better integrate with the JobQueue, allowing
slaves to optionally be woken up to process jobs inside their job window,
etc..  Right now the master won't tell the slave to go to sleep if the
slave is busy with a mythtranscode or mythcommflag job.  This is checked
via the inuseprograms table.

--
Chris