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

[Mike Perkins]

Chris Pinkham wrote:
> * 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.
> 
That's exactly what I had in mind, but obviously without knowing how the various 
parties communicated and when I couldn't visualise the process you've outlined.

Thanks.

-- 

Mike Perkins