[mythtv-users] Record on Backend, Watch LiveTV on Frontend?

Bruce Markey bjm at lvcm.com
Fri Apr 11 05:22:31 EDT 2003


Chris Palmer wrote:
..
> would I be out-of-line to bring up the idea that the backends
> (and maybe the master-backend) be the only machines that talk
> to the database directly? I can guess that there would be a
> bit of work involved in making changes, so I'm not going to 
> push hard on this, unless I make time to help, but I'd like 
> the idea out there at any rate.

The first question you should ask yourself is 'what problem
am I trying to solve?' It may seem like the name "master
backend" implies that the frontends should be subservient to
to this master but that isn't what really is going on. The
majority of data in the database is used by the frontend,
some of it is needed by both and only the stuff about capture
cards is exclusive to the backend.

So, I could make the argument that maybe only the frontends
should be allowed to talk to the database and the backends
would have to get data relayed through the frontends. This,
of course, sounds silly but there would be less data that
would need to be relayed than the other way around =).

> I suppose one could argue about scaling issues with having all
> that data flow thru a single host, but the database is also a
> bottleneck for data flow, until multi-master cross-replication
> is released at some future point for MySQL (someday, I think).

I'm often surprised by the perception of database performance
in MythTV. So, every once in a while, a tidbit of data is
queried from the database. Then for an hour straight, 1.6GB of
video is mpeg encoded in real time and written out, followed
by an INSERT or something to mark that it's done. While things
should be done efficiently, I don't think preening the SQL
transaction needs to be the focus of performance tuning ;-).

> I think it would simplify frontend setup, so that it doesn't 
> directly have multiple dependencies, nor require database
> libraries.

The dependency of the data availability exists whether the
frontend gets it relayed from the backend or directly from
the DB. The extra dependency is the backend connection.

The database libraries already exist, are debugged and work.
The alternative is writing and debugging new code to relay
the information over the control socket. This already had
been the cause of several bugs between 0.7 and 0.8.


>  It might be nicer for security, too, especially 
> if Myth recognizes the concept of a "user" at some point, 
> which from the database structure, appears like it might 
> have been planned.

Security by only allowing local connections rather than net
connections is a valid argument. I could certainly go along
with any points there. However, as an argument for only
allowing backends to connect, it doesn't hold up. You can
have multiple frontends and multiple backends on different
hosts. For all I know, you may be running a master backend
on a different machine than the DB and may run a frontend
on the DB machine.

I think this is just a matter of assumptions and perceptions.
You could start from the premise that the frontend is the
'important' piece =) and the data belongs to the frontend.
Then the backend is stuck with the grunt work of recording only.
The master is stuck with the menial task of scheduling for
the other backends. The frontends should always get its info
from the DB and should only talk the the backends when it needs
a remote video file or such.

The backends serve recordings, the DB serves data. There really
is no point to forcing these services to behave any differently.

--  bjm






More information about the mythtv-users mailing list