While a thin MythTV frontend may be the justification for the MiniMyth project, I can see the merits of small Myth-focused distributions, both frontend and backend, regardless of whether they boot from non-traditional media (e.g. over the net or from a USB disk).
This is not to say that being able to run a diskless, flashless, "nothing but RAM and net" mythfrontend isn't usefull, but I think it is but one part of the picture.
When focusing on the thin, diskless, fanless, quiet mythfrontend, we probably tend to imaging a huge, hulking, noisy mythbackend somewhere, with tons of tuners and disk space. But, this is forgetting the distributed nature of MythTV.
Instead of a large mythbacked, imagine a number of small slave mythbackends, each with capture, or tuner cards (PVR 350s, pcHDTV 5500s, etc.). They can either have local recording storage, or record over nfs to a large server (or, for the brave, be part of a cluster, each enbd-exporting a disk partition back to a master backend which RAID5s them and nfs-exports them back to the cluster). Each slave could possibly also run mythfrontend, just to rip the odd CD or DVD, or play it back locally.
Of course, the minute you add hard disks to a mythbackend, it is questionable whether it should boot over the net, or from a local disk.
Multiple slave mythbackends have an additional benefit: they can distribute the capture processing load (though some of this benefit is lost if they all save over NFS).
Finally, if one has several HDTVs in the home connected to satellite or cable STBs, one might find that one can only capture some content via a reduced-resolution composite or svidio "analog-hole" output. Might be good enough for viewing on a different monitor, or recording for later. The point is, while it might be possible to stack several STBs in a rack, connected to multiple capture cards in a large mythbackend, with the intend to distribute the content over IP to mythfrontends everywhere in the home, DTCP/5C-protected programming would be inaccessible in it's highest resolution this way: gotta have those STBs by the TVs (and snake a damn thick coax cable to them).
So, I see the need for several small software footprint MythTv front- and backends (with a single master backend), that can work together as a MythCluster. If they run MiniMyth, the result is a MimiMythCluster (MMC). They should be in one of a few small "standard" configurations, to make integration of the individual units into a cluster relatively easy.
As I get more familiar with MiniMyth, I'd like to extend the idea to (a) booting MiniMyth from a local disk, (b) running it from local disk without a ram disk, (c) using the MiniMyth model (and GAR) to make a MiniMyth backend (master or slave, which is really what justifies running from a disk), (d) supporting backend slaves with nothing but net, RAM, and tuners or capture cards (or course, local disk should be supported by them too).
Looking at the Serener GA-L01 case, I see a few options for a "universal" myth box:
1) Add hard disk to make a master backend, with mysqld, tftpd, and dhcpd that can boot frontends and slave backends, or for that matter, NAS boxes exporting disk storage.
2) Make a similar frontend or slave backend that either boots from a local disk, or from the master backend. Of course, I suppose one could run both the frontend and backend on a single box.
3) Support local tuners or capture cards (one or two) in a backend unit.
4) To avoid the need for a router to interconnect all the devices, one could put one or two multiport ethernet cards in the master backend instead of tuners.
5) The master backend could serve as dns and ntp proxies for the slaves and front end.
There are obviously lots of ways such devices could be internetworked -- the challenge is to try to come up with a few generic scenarios to simplify configuration.
However, I am happy to help you in understanding MiniMyth's directory structure, init scripts and modified GAR build system.
I originally thought the same thing: a full-blown FC (or other distro) install running as a backend (and indeed, that's how my system is currently set up), with real thin front-end clients served from it.
But, I realized that there were lots of scenarios where (a) one's backend and frontend were the same, and in the family room, and (b) one might want to accomodate more tuners than a combined "small" (if not thin) backend/frontend could handle. So, that's where the idea of a distributed mythcluster came to mind.
I do think, with H/W MPEG2 encoders or receivers (PVR-250/350 and pcHDTV 3000 or 5500), it should be possible to make a fanless backend that is silent, except for drive noise when recording or playing back.
Unfortunately, right now I'm dealing with a hard disk failure in my main home firewall/email server, and that takes priority.
Ouch.rhollan wrote:Unfortunately, right now I'm dealing with a hard disk failure in my main home firewall/email server, and that takes priority.
I have rather detailed, if not complex, iptables rules that I had to apply. The firewall also does "poor man's" traffic shaping: it has two "inside" ethernet ports, with one reserved for VoIP, and the other going into a router for the home LAN. Finally, it has storage, and serves as my SMTP mail sink (along with an anti-relaying sendmail.cf file). I really should add a third ethernet port for a DMZ -- ain't no way my employer's Windows(r)(tm) boxes are gonnna find their way inside my home LAN.
So, it was important to get the firewall up, if only to not lose my flat rate long distance service. (LOL: I'd forgotton to code echo "1" > /proc/sys/net/ipv4/ip_forward into a system start up file once --- try explaining to a non-tech wife how and why that is necessary "to make the phone work" after recovery from a power failure). I do keep a POTS line as well (Verizon's dry pair ADSL costs more than their hot ADSL pair -- go figure), but mostly just for "real" 911 service.
It was also an excuse to do something I'd been planning for a while: replace the 40 GB drive in the firewall/smtp server with a 400 GB drive from which I could serve ripped content to my home LAN.
Of course, as luck would have it, my one and only DVD+/-RW drive died around the same time, so installing the bits of FC4 I use on it proved to be, er, less easy than I'd hoped.
I suppose it serves me right for using a $200 Fry's (my kids understand that Fry's is the "Daddy Store") special for a firewall/mail/etc. server.
To have as my frontend, an LCD monitor connected with cat5/6 attached with a vga/monitor plug (that fits most monitors), and also a ir sensor. The cat5/6 cable to run 60 metres away, where the motherboard is kept, in a room with cooling and and is easy to get to, being still a part of the myth diskless frontend.
It is possible to use a coax cable for the signal and use the cat5/6 cable for the remote and/or keyboard, included with the above setup?
I have a room dedicated for computers, where I can put the frontends and backends together, just having the monitor over a distance, with its controller (the remote control).
I have a coax cable and two cat5/6 cables going to a few rooms. One cat cable will be for a telephone and the other for computer access or a keyboard/remote control combination, and the coax sending the video signal feed.
Is/Are there existing setups that use something similar I wonder, or maybe any proof of concepts that need actualising. Main considerations are price, and ease of setup I guess. I can use a soldering iron to create the cables, and edit .conf files, that kind of thing.