Mailing List Archive

Mark Chou wrote:
...
> Perhaps in the myth TV documentation there can be brief mention of this,
> and perhaps suggest to folks that they ought to put the largest storage on
> the master backend?

Maybe somewhere in Section 9 it could mention that the first
input connection is always used first, the order in which
slaves are setup matters, and the master will need more disk
space for having the first input.

> Also, what's the recording storage logic if the master runs (or is about to
> run) out of room? Is there then "failover" to put the recorded file on the
> second/slave mythtv box?

This is the vast unexplored territory. Last time I let a disk
run out of space the backend simply died when the write failed
(that was a few months ago so it might behave better now).
AFAIK there is nothing that deletes old recordings if there
isn't enough space for new ones much less remove too many
episodes of a certain show which several people have asked for.
There would also need to be a way to mark old recordings that
should never be deleted. The Delete Recordings screen shows
the total disk usage but doesn't tell you if one disk is
nearly full. So, currently it's up to the users to monitor
their space.

If there were a task to manage space, one thing it could do
might be to transfer files if one disk is below minfree and
others are above lotsfree and only remove files when all
disks are nearly full. Another thought is the scheduler could
choose the encoder with the most freespace. However, I like
your failover idea. If less than minfree, check to see if
another available encoder has lotsfree.

>
> Also another question while I'm on this topic. What peer
> "autodiscovery/reconnect" mechanism does the backend use, if any? If I
> reboot/restart my master backend it seems that my slave backends get
> orphaned, and doesn't seem to want to reconnect to the
> rebooted/restarted master. In which case I need to restart mythbackend
> on my slave machines to completely restore the myth "virtual cluster."

Something's not right then. Isaac did a great job with the
backend reconnections and I've never had a problem with
backend peers. If you stop the master, the slave should
print these messages every second:

2003-05-07 13:57:34 - Connecting to master server: 192.168.0.35:6543
2003-05-07 13:57:34 - Could not connect to master server.
2003-05-07 13:57:35 - Connecting to master server: 192.168.0.35:6543
2003-05-07 13:57:35 - Could not connect to master server.
2003-05-07 13:57:36 - Connecting to master server: 192.168.0.35:6543
2003-05-07 13:57:36 - Connected.

When the master restarts, or if a slave is started while
the master is running, you should see a message like this
from the master:

2003-05-07 13:57:36 adding: slavehost as a slave backend server

-- bjm