[mythtv-users] Multiple HDHomeruns

[Jim Stichnoth]

On Fri, Aug 7, 2009 at 5:31 PM, Fraser, Douglas<dfraser at king5.com> wrote:
> I have 3 HDHomerun tuners that will sit on a subnet with a Master Frontend /
> Backend and a Slave Backend.  The master will have two nics so the frontend
> can interact with the main network.  My question is, do the tuners in the
> HDHomeruns (six tuners total) have to be hard assigned to either the master
> or slave? Or can the boxes be set to just pick an unused one?  And if I have
> to assign them is it better to split them up, say something like all tuner
> 0’s to the master and all tuner 1’s to the slave, or both tuners in a single
> HDHomerun to master or slave?  Thanks for any help.

To answer your specific questions, each of the 6 tuners has to be
"owned" by a single backend.  This assignment is set in mythtv-setup
and is not dynamic.  The master backend will try to spread the load
among the backends.  And it shouldn't matter whether the pair of
tuners in a single HDHR is owned by the same backend or split between
two backends.

That said, I have some suggestions.  First, it doesn't seem necessary
to set up a separate subnet, assuming you're just trying to isolate
the HDHR network traffic from the rest of the network.  Isolating all
backends and HDHRs behind a simple network switch will do just fine.

Second, it may not be necessary to have a slave backend.  If all of
your hard drives will fit in the master backend, then it should be
sufficient for recording.  I have 2 HDHRs and an HD-PVR (5 tuners
total) on a single backend, and it works just fine.  The important
thing is to make sure you have enough disk bandwidth, which means
having enough physical disks.  There will be many opinions on this,
but in your position I would be sure to have 3 hard drives.  The two
drives in my backend work fine, but I have to take some extra care:
enable slow deletes for the ext3 file system, don't let
mythfilldatabase run during heavy recording periods since its DB
behavior thrashes the disk (instead, force it to run during the wee
hours), and avoid other DB-intensive activity during heavy recording
(such as performing searches or looking at the backend status).  If
you have the luxury of putting the DB on its own drive, all the
better.

Jim