[mythtv-users] MythTV core structure.

[Joseph A. Caputo]

Comments inline.

> -----Original Message-----
> From: mythtv-users-bounces at mythtv.org
> [mailto:mythtv-users-bounces at mythtv.org]On Behalf Of Steele Price
> Sent: Thursday, August 14, 2003 1:41 PM
> To: Discussion about mythtv
> Subject: [mythtv-users] MythTV core structure.
>
>
> I am trying to understand why MythTV is laid out in such a way that it
> requires a capture card to function at all.

No, it doesn't.  While it's true you currently need the V4L headers to be
able to build Myth, you certainly don't need a capture card to run it if you
don't need the TV capabilities.

> For example, what if I wanted to use Myth for just accessing all the media
> files on a frontend without any TV at all.  Currently I don't see
> any way to
> do this without just having a broken TV portion.

Just edit the 'TV' button out of your mainmenu.xml file.

> Shouldn't TV be a module as well instead of the root of the entire system?

Not a bad idea, but delicate work (like separating Siamese twins)... are you
offering to do this?

> I would expect that the master backend would just be an administrative
> interface to the database and the file structure that could be applied to
> any frontend.

Yes, well, it works this way for management & playback of recorded TV.
Eventually, I think the goal is to have the other media types integrated in
the same way.

> I am trying to use MythTV to organize gigantic libraries of media files
> which include music, pictures, and video, but really don't need
> the live TV
> portion, or would not actually use it on all frontends.
>
> Ideally, I would see modules being the focus of the "master
> backend" and not
> capturing, while capturing may be important to most users, it certainly
> isn't to everyone.  It would also make more sense for a frontend
> to just get
> all it's configuration information (file directories, database
> information,
> and common system capabilities) my installing the frontend and just asking
> for an appropriate backend to connect to.

It already pretty much works this way... the only thing lacking is a
'self-discovery' mechanism (a la Rendezvous; there's been recent talk about
this).  Right now the only way a frontend knows where the master backend is
located is by querying the database, the location of which is defined in the
'mysql.txt' file.  Simple (mostly settings/options) queries are done
directly to the database, while more complex things are done through a
protocol with the backend.  Most/many tables in the database have a
'hostname' field, so settings can be host-specific.

>
> Is this scenario possible or am I trying to go down the wrong path?
> Unfortunately, the way I am starting to see how things are
> architected they
> just don't make alot of sense unless I have completely missed
> something.  I
> first became interested in MythTV because it appeared to be the furthest
> along in development, but maybe because it started as "just a
> pvr" it's core
> was already set and it was too late to back it out into the
> scenario I just
> described.
>
> Should I take this to the dev list or is no one else interested
> in this type
> of system?
>
> What I had envisioned was a central file server for the whole house/office
> that any frontend could connect to, different frontends could
> have different
> capabilities based on the settings in the backend.  Scenario: I
> could have a
> viewing frontend in the kids room that could only get certain
> channels/videos/music, the frontend in the living room gets other channels
> and can act as an administration point, the frontend in the
> parents bedroom
> could do the same, but also gets web access where the other don't, then
> there is another TV server that just handles all the recording and
> transports the files to the master/file server.
>
> Myth has done all the heavy lifting getting the functionality
> there, but it
> appears not to be able to be distributed in this fashion, nor can it get a
> set of network accessible files without mapping all those files in the
> frontend with autofs/nfs/nis configurations that can challenge even a
> seasoned user.  Myth needs a frontend that can just be installed without
> alot of fuss for viewing and attach to a distributed network of
> components.

Yes, right now if you want distributed access to media other than Myth
recordings, you need to deal with setting up network mounts.  But patience,
grasshopper! :-) Good things come to those who wait.  Eventually other media
types will be served by the backend.  That day may come even sooner if you
care to contribute...


-JAC