[mythtv] Waking slaves with an always-on master

Russ W. Knize rknize at yahoo.com
Sun May 27 17:19:22 UTC 2007


On Mon, 2007-05-14 at 22:35 -0500, Russ W. Knize wrote:
> I asked this on mythtv-users, but no one seemed to know (some one else
> is also asking about it).  I also searched the archives back a couple of
> years, but did not find anything.
> 
> When discussing shutdown/wake with respect to slave backends, the
> documentation states that slaves will shutdown when the master shuts
> down, if configured to do so.  It does not address whether the master
> backend is smart enough to wake slaves only when their tuner is required
> to resolve a conflict and shut them down when they are done (or let the
> slaves shut themselves down if they are going to be idle).
> 
> My master backend has a lot of other duties and is always on.  It has a
> PVR-500 in it.  I also have two slave backends on the network (which
> happen to be frontends as well, but I'll deal with that later), one with
> a PVR-250 and another with a pair of pcHDTV HD-3000 cards.  This is due
> to lack of PCI slots in the master and for other logistical reasons.
> 
> Does Myth have the necessary logic to do this?  If not, can someone give
> me a nudge in the right direction to enhance this functionality?

The lack of response tells me that know one knows or that no one cares.
I did some experiments and I can't find a way to get a slave to want to
shut itself down if it is idle while clients are connected to the
master.  There appears to be some association that needs to be broken.
Another thing that seems suboptimal is that there is no way to tell the
system that the slaves are sharing the same file system as the master.
There is the "master override", but this doesn't prevent clients from
contacting slaves about their recordings, even when it would be more
efficient for the network for the master to stream the data.

I'll start hacking up the code to see what I can do.  Any guidance would
be appreciated.

Russ




More information about the mythtv-dev mailing list