Mailing List Archive: MythTV: Users

Encoder (slave) "currently not connected" or "currently asleep"?

Index | Next | Previous | View Threaded

derliebegott at gmail

Nov 2, 2009, 4:07 AM

Post #1 of 9 (274 views)
Permalink

Encoder (slave) "currently not connected" or "currently asleep"?

Hi,

One hour ago when my slave backend (mythbox) was shutdown Mythweb
backend status page was showing something like this:
# Encoder 1 is remote on mythbox (currently not connected).

And because of this status ("currently not connected") mythweb was not
showing future recordings which should be recorded over this encoder.

I started mythbox and shut it down again. Now mythbackend is showing
the following at the moment:
# Encoder 1 is remote on mythbox (currently asleep).

Slave was shutdown in both cases. Why is this tunes/encoder sometimes
"currently asleep" and sometimes "currently not connected"?
Is there a way to prevent it being "currently not connected" because
that hides future recordings in mythweb (and propably all frontends)?

Thanks.
_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

cpinkham at bc2va

Nov 2, 2009, 10:18 AM

Post #2 of 9 (250 views)
Permalink

Re: Encoder (slave) "currently not connected" or "currently asleep"? [In reply to]

* On Mon Nov 02, 2009 at 01:07:53PM +0100, Ma Begaj wrote:
> One hour ago when my slave backend (mythbox) was shutdown Mythweb
> backend status page was showing something like this:
> # Encoder 1 is remote on mythbox (currently not connected).

> # Encoder 1 is remote on mythbox (currently asleep).

"currently not connected", means that you (or someting other than the master
mythbackend process) shut down the slave and the master does not know that
it can wake the slave up again to record something, so it does not schedule
recordings on the disconnected slave.

"currently asleep" means that the master backend told the slave backend to
go to sleep and the slave backend did so and is currently disconnected. In
the case, the master knows that it shoudl be able to wakeup the slave
(because the slave had its sleep and wakeup commands configured), so the
master will schedule recordings to be recorded on the slave and these
will show up in the status webpage.

In essence, if you use the on-demand wakup/shutdown functionality for slave
backends, don't shut them down yourself, you need to let the master backend
tell the slave to shutdown.

--
Chris
_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

derliebegott at gmail

Nov 2, 2009, 11:02 PM

Post #3 of 9 (230 views)
Permalink

Re: Encoder (slave) "currently not connected" or "currently asleep"? [In reply to]

2009/11/2 Chris Pinkham <cpinkham[at]bc2va.org>:
> * On Mon Nov 02, 2009 at 01:07:53PM +0100, Ma Begaj wrote:
>> One hour ago when my slave backend (mythbox) was shutdown Mythweb
>> backend status page was showing something like this:
>> # Encoder 1 is remote on mythbox (currently not connected).
>
>> # Encoder 1 is remote on mythbox (currently asleep).
>
> "currently not connected", means that you (or someting other than the master
> mythbackend process) shut down the slave and the master does not know that
> it can wake the slave up again to record something, so it does not schedule
> recordings on the disconnected slave.
>
> "currently asleep" means that the master backend told the slave backend to
> go to sleep and the slave backend did so and is currently disconnected. In
> the case, the master knows that it shoudl be able to wakeup the slave
> (because the slave had its sleep and wakeup commands configured), so the
> master will schedule recordings to be recorded on the slave and these
> will show up in the status webpage.
>
> In essence, if you use the on-demand wakup/shutdown functionality for slave
> backends, don't shut them down yourself, you need to let the master backend
> tell the slave to shutdown.
>

Thanks. Helpful as always.
_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

cpinkham at bc2va

Nov 3, 2009, 10:20 AM

Post #4 of 9 (214 views)
Permalink

Re: Encoder (slave) "currently not connected" or "currently asleep"? [In reply to]

* On Tue Nov 03, 2009 at 08:02:40AM +0100, Ma Begaj wrote:
> > In essence, if you use the on-demand wakup/shutdown functionality for slave
> > backends, don't shut them down yourself, you need to let the master backend
> > tell the slave to shutdown.
> >
>
> Thanks. Helpful as always.

One other thing I didn't mention. It is on my TODO list to add a way to allow
a slave backend to tell the master that it is going to sleep, so you could
shutdown the slave and have the master wake it back up again. This is
primarily for combination FE/SBE machines, so the user can shutdown the
machine when done use the FE and have the master wake the slave back up if
necessary to record something new.

--
Chris
_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

derliebegott at gmail

Nov 3, 2009, 11:28 AM

Post #5 of 9 (214 views)
Permalink

Re: Encoder (slave) "currently not connected" or "currently asleep"? [In reply to]

2009/11/3 Chris Pinkham <cpinkham[at]bc2va.org>:
> * On Tue Nov 03, 2009 at 08:02:40AM +0100, Ma Begaj wrote:
>> > In essence, if you use the on-demand wakup/shutdown functionality for slave
>> > backends, don't shut them down yourself, you need to let the master backend
>> > tell the slave to shutdown.
>> >
>>
>> Thanks. Helpful as always.
>
> One other thing I didn't mention. It is on my TODO list to add a way to allow
> a slave backend to tell the master that it is going to sleep, so you could
> shutdown the slave and have the master wake it back up again. This is
> primarily for combination FE/SBE machines, so the user can shutdown the
> machine when done use the FE and have the master wake the slave back up if
> necessary to record something new.
>
>

That would useful because I am shutting down slave backend manually
because this box is also a frontend.
_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

mikep at randomtraveller

Nov 4, 2009, 3:26 AM

Post #6 of 9 (194 views)
Permalink

Re: Encoder (slave) "currently not connected" or "currently asleep"? [In reply to]

Chris Pinkham wrote:
> * On Tue Nov 03, 2009 at 08:02:40AM +0100, Ma Begaj wrote:
>>> In essence, if you use the on-demand wakup/shutdown functionality for slave
>>> backends, don't shut them down yourself, you need to let the master backend
>>> tell the slave to shutdown.
>>>
>> Thanks. Helpful as always.
>
> One other thing I didn't mention. It is on my TODO list to add a way to allow
> a slave backend to tell the master that it is going to sleep, so you could
> shutdown the slave and have the master wake it back up again. This is
> primarily for combination FE/SBE machines, so the user can shutdown the
> machine when done use the FE and have the master wake the slave back up if
> necessary to record something new.
>
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.
2. SBE invoked by master, recording and shut down afterwards.
3. Powered down by me, but available if MBE requires it (woken up by WOL code).

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?

--

Mike Perkins

_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

derliebegott at gmail

Nov 4, 2009, 5:51 AM

Post #7 of 9 (190 views)
Permalink

Re: Encoder (slave) "currently not connected" or "currently asleep"? [In reply to]

2009/11/4 Mike Perkins <mikep[at]randomtraveller.org.uk>:
> Chris Pinkham wrote:
>>
>> * On Tue Nov 03, 2009 at 08:02:40AM +0100, Ma Begaj wrote:
>>>>
>>>> In essence, if you use the on-demand wakup/shutdown functionality for
>>>> slave
>>>> backends, don't shut them down yourself, you need to let the master
>>>> backend
>>>> tell the slave to shutdown.
>>>>
>>> Thanks. Helpful as always.
>>
>> One other thing I didn't mention. It is on my TODO list to add a way to
>> allow
>> a slave backend to tell the master that it is going to sleep, so you could
>> shutdown the slave and have the master wake it back up again. This is
>> primarily for combination FE/SBE machines, so the user can shutdown the
>> machine when done use the FE and have the master wake the slave back up if
>> necessary to record something new.
>>
> 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.
> 2. SBE invoked by master, recording and shut down afterwards.
> 3. Powered down by me, but available if MBE requires it (woken up by WOL
> code).
>
> 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?
>

I solved this temporary by setting wakeup time on slave backend
before shutdown.

Slave will wake up independently without Master and it will connect to
Master after starting itself. No recordings will be missed.
_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

cpinkham at bc2va

Nov 4, 2009, 11:10 AM

Post #8 of 9 (185 views)
Permalink

Re: Encoder (slave) "currently not connected" or "currently asleep"? [In reply to]

* 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
_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

mikep at randomtraveller

Nov 5, 2009, 2:39 AM

Post #9 of 9 (170 views)
Permalink

Re: Encoder (slave) "currently not connected" or "currently asleep"? [In reply to]

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

_______________________________________________
mythtv-users mailing list
mythtv-users[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com