[Tfug] Radio/TV cards?

[Bexley Hall]

Hi John,

--- On Sun, 9/30/12, John Gruenenfelder <jetpackjohn at gmail.com> wrote:

> Ah, now I have a better idea of what you're looking to
> create...

Well, perhaps *better* but still not The Whole Picture  <grin>
(see below)
 
> Have you given any thought to using MythTV?  It should, honestly,
> solve *all* of the issues you have mentioned so far. Multiple source
> streams, multiple output streams, PiP, television scheduling and
> recording, even multiple servers.  After ten years, I've managed to
> use most of these features at one point or another.
> 
> There seems to be a bit of a cottage industry on the Net devoted to
> complaining and whining about MythTV, its age, and the speed of its
> development.  They like to instead heap praise upon projects like
> XBMC.  There's nothing wrong with XBMC or any of the other major
> programs, but they focus almost solely on playback of recorded media.
> MythTV still receives a lot of development effort, and a good amount
> of that effort is put into the TV scheduling and recording abilities.
> Obviously, if that isn't something you actually need then an
> alternative to MythTV may be better, but I definitely appreciate the
> effort.

I'm always amused at how much grumbling comes from folks who
are doing little (usually) to "advance a project"!  <grin>

> MythTV has an excellent network architecture and it is relatively easy
> to make use of the parts you need/want and ignore the others.  Plus,
> MythTV is also to figure out quite a bit on its own just by having you
> inform it which machine is the primary backend, secondary backend,
> frontend only, combined backend-frontend, and so forth.  My normal
> configuration is to just have a combined backend-frontend machine,
> though in the past I've also had an additional secondary
> backend-frontend machine.  A backend machine is any computer that has
> a TV capture card (of some sort) and runs the mythtv-backend process.
> By allowing you to have multiple backends you can distribute your
> capture abilities among more than one machine and thus share the load.
> Storage for all your forms of media (recordings, video, music, etc.)
> can similarly be spread among the backend machines

I will probably *play* with MythTV but don't think it will fit my
needs, ultimately (again, see below).
 
> Personally, I like to put a lot of services on one machine rather than
> spread it out on a lot of less powerful machines.  I think, overall,
> this is the more efficient approach, and it also means fewer computers
> to maintain.  If you're looking to have HD playback capabilities then
> you're going to need a decent CPU.  Couple that with a decent amount
> of memory and storage and this computer will be able to handle quite a
> lot.  Along with MythTV, my machine also is also a file server and
> infrequent torrent downloader.  In the past, however, it has also
> served email, had a few other infrequent users with shell accounts who
> played with PHP, and handled my telephone via Asterisk. And maybe some
> other tasks, too.  I've never had any issues "overloading" this
> machine.  Handling HD would certainly tax it a lot more than it is
> currently, but I think it's up to it.

You're thinking more in terms of "computers" whereas I'm thinking
more in terms of *appliances*.

E.g., I've got all the "services" stashed away, out of sight.
All I want to deal with are "user interfaces" -- whatever those
might be!

I don't want to have to worry about "rebooting" something.  Or
"routine maintenance", etc.

I don't want to hear any fans (there are none in my current ad hoc
implementation).

If I want to listen to music/watch a video, I don't want to have to
wait for something to boot before the service becomes available.
Nor do I want machines burning power when they aren't "servicing
my needs".

And, I want a more "integrated" solution.  Here's a "typical"
example of what I want to be able to do:

- Someone comes to the front door and "rings the bell"
- System figures out who is home (if anyone) and where
  they are and/or what they are doing -- or *likely*
  doing (e.g., if it is 5AM and I'm in my bedroom, chances
  are I'm *asleep*!  :> )
- If no one is home (or, the occupant(s) are "indisposed"
  or "not entertaining guests"), the system might turn
  on the front door camera (assuming it isn't already on
  for "surveillance") and record some footage of the
  visitor
- It might, instead, ask the visitor to identify himself
  "Who is it?" and record a voice sample before responding
  with, "We're sorry but we can't come to the door, currently"
- The above video/audio might get dispatched to the occupants
  (assuming we are someplace suitably connected) or simply
  recorded with a timestamp.
- Or, the video might be routed to a "network display" somewhere
  near where I am currently located (e.g., I might be making dinner
  so turn on the nearest display and let me see who is at the
  door)
- I might choose to talk to the person (e.g., a neighbor that I
  recognize... or, a guest that I am "expecting", etc.).  Or, I
  might not want to disclose that I am home and, instead, have
  the system interact with the visitor on my behalf ("Go away
  solicitor!!")
- I might have been watching TV when this sequence of events
  started.  So, the front door image might appear as PiP in
  my normal program material.  Or, perhaps whatever I am watching
  is "paused" so the display can be used by the front door
  camera.  Or, perhaps the audio from the front door gets
  routed to my earpiece while the TV program's audio continues
  to be routed to a network speaker.
- Or, I might have been consulting a recipe for some cookies that
  I'm baking.  In which case, the text can be swapped out for a
  view of the visitor.

I.e., it's no longer "TV" or "movies" but, rather, "a video subsystem"
that is just a component in a larger system.  Wanna watch TV while 
listening to the radio (TV muted)?  OK.  Wanna *listen* to TV without
watching it??  etc.

> > And, it would be of little use to anyone else trying to replicate
> > my efforts (do they even *sell* those boxes anymore?)
> 
> Yes, you can still find the digital TV converter boxes for older TVs.
> I had reason to check about ten months ago and even Best Buy had
> one... but only one.  If they still have them then I'm sure there are
> several to pick from online and probably a very healthy market for
> used converters.

<grin>  I actually *doubt* there are many used *operational*
converter boxes!  We use them, here (since we watch so little
TV, it has not been worth updating any of the TV's).  I have
to routinely service them as they fry themselves.  In however
long its been since the DTV debacle, I think I have repaired
a total of 6 instances of failures (on the two TVs we use...
*SELDOM*!  :> )  They seem like they are designed for a
relatively short lifespan.

(At World Care, I would see lots of these come in -- no doubt as
folks upgraded their TV's -- and a good many of them were toast.)

> > As above... mainly so two of us could watch different programs.
> > Of course, with more than one source, there are other
> > possibilities as well (PiP, record+watch, record+record).
> 
> As I wrote above, MythTV will be able to take care of all of this for
> you... the management and networking, anyway.  You'll still need to
> devices if you ever run across one of the situations you just
> mentioned where two streams must be recorded at the same time.
> 
> That said, if you end up making really good use of MythTV (or any
> other DVR) you will find that most of the time you only need one
> recorder.  Just schedule *everything*, even if you plan to watch it
> live sometimes.  You'll never miss a show and by watching it non-live,
> even by just 15 minutes, MythTV will be kind enough to remove all of
> the commercials for you and they can be automatically skipped over, if
> you like.
> 
> Personally, I *never* watch any TV live.  There are a handful of shows
> that I like and my MythTV installation has all of them scheduled.
> They all get recorded, they all have the commercials auto-marked, and
> then they wait until I decide I want to spend the time to watch them.

We tend to watch TV as a "side event" while doing something else.
For example, preparing a meal.  In those cases, we're already
"stuck" in a particular place performing a primary task (e.g.,
making that meal!).  So, "watching TV" doesn't cost us any "real
time" -- watching it at any *other* time would typically conflict
with something we would much rather be doing!  E.g., I can't
attend to the yard if I'm sitting in front of The Tube, etc.

> The machine has a lot of storage, so the shows can sit for a long
> time, but I also have them marked to auto-expire, so if the drives
> *do* get full, recordings start getting erased, oldest first.  And if
> I never get around to watching a particular episode, so be it.  It
> will eventually be rerun.

Understood.  We currently don't have much that we really *want* to 
watch.  Or, that we would "make SPECIAL time for".  Or, that is
so frequent that we would *need* to timeshift.

E.g., we can afford to set aside some time Wednesday for the
debate.  If, OTOH, this happened *every* night, we would have
a problem.

(Now that "Coupling" is over, I don't think there are any
"shows" that we make a point of watching.  And, "movies"/DVDs we
can watch and pause at will so there's no real win, there)

> > But, a single processor would have to handle all of the load?
> >
> > I've looked into a variety of different hardware architectures
> > as I've tinkered with this design.
> >
> > Early on, I dismissed the "single server" approach because it
> > required too much horsepower to handle "everything"... and,
> > only needed all that capacity in a few (rare?) circumstances.
> >
> > So, I have been gravitating towards multiple small, dedicated
> > "servers" that can be brought on line as needed.  As the
> > functionality that they provided was needed!
> >
> > With a single video source per server, then *replacing* that
> > with audio, instead, is a cake walk.  So, having a server
> > handle one audio *or* video service seems like it might be a
> > nice, scalable unit!  Want PiP?  Or, to be able to watch
> > TV while listening to the radio?  Add another server!
> 
> As I mentioned above, I think having fewer more powerful servers is a
> better way to handle this.  Less maintenance too.  But, to each his
> own.

But you can't stuff your server in a closet and forget about it!

Currently, each of my "servers" draws about 45W (some of this
purely wasted because they each have onboard video -- NONE of
which are used!)

If I'm "doing nothing", only the bastion host runs.  So, I can
power up a workstation in the office and get out to the 'net,
download files, etc.  If I want to interact with the system
(e.g., rearrange the irrigation schedule), the code to do
that can run on this box -- talking with a "control panel"
located elsewhere (the actual "irrigation controller" sits
out on the end of a network drop in the garage -- it never 
needs to talk to a person, just the irrigation valves!).

Likewise, if I want to change the temperature in the house
(or, tell the system that I'll be leaving for several hours
and that it need not keep the house "as comfortable" as when
it is occupied), then I can use a similar control panel
(or, a laptop plugged into any of the network drops, WiFi,
etc.) to tell the HVAC controller (*through* that bastion
host) about my desires.

If I want to listen to music, then that host powers up an
audio server (another one of these devices that happens
to have whatever peripheral hardware is necessary to
"serve up audio") and hands off the audio task to that
server.  If someone else wants to listen to some *other*
audio program, then the current audio server might handle
the load.  Or, require a *second* server to come online
(depends on how many MIPS I make available in each server).

When services are no longer needed, those servers are
powered down.

If three people decide they want to watch three different
video programs, then three video servers would be brought
online (assuming each is sized for one video load).

E.g., in the "visitor" scenario I outlined above, if there
is enough spare processing power available, currently, then
all the system has to do is power up the "door camera"
and route it to <wherever> (or, audio, etc.).  If there is
not enough spare resources available, then another
appropriate server is brought online.

(For example, when the house is unoccupied, one or more
servers might be brought online to watch over the various
camera feeds around the house -- watching for motion,
capturing video, etc.  At the same time, it is unlikely
that anyone inside the house is watching TV, etc.)
 
> In my experience, a single machine can handle a surprising
> amount of video and audio streaming.  With the Hauppauge SD PCI
> encoder cards, the actual load placed on the system is quite small. 
> I'd say the part taxed the most is the I/O bandwidth to the machine's
> storage subsystem, though, of course, the smaller you make the MPEG
> encoded files, the less data there is to either process or to
> store.  MythTV is also smart enough to not spawn a half dozen jobs,
> but will rather queue them and only run as many at once as you specify
> with the default being the number of cores you have.  In the case
> where you have multiple backends and distributed storage, MythTV can
> also be told to only run some jobs (like commercial detection or
> transcoding) on the machine where the file is actually stored so that
> it's not constantly sending huge amounts of data over the network.

But a single "server" means everything that it needs to push out
onto the network goes out through that one pipe.  With multiple
servers, I can move the load around to exploit surplus MIPS as
well as network bandwidth.  E.g., I can route the output of
each camera to a different server and have each server process
*just* that input -- instead of routing everything through *one*
server.  (the same analogy applies to video programs)

My goal is to make the servers smaller and more power efficient.
E.g., burning 45 watts *just* to be able to connect to the 'net
is wasteful.  Likewise, it shouldn't require that much power
*just* to move audio to "network speakers".  If you can specialize
what a processor has to do (even if you treat processors as
interchangeable processing units), then it can provide that
service more efficiently.  Especially when the services are
"durable" (i.e., not transient/short-lived).

[much elided]

> If you look online you can find HD PCI encoder/recorder cards.  They
> do the same task as the USB models, but by virtue of *not* being USB,
> I can certainly imagine that the machine load is greatly reduced.  I
> haven't seen one firsthand, mind you, but I doubt it's anywhere near
> as bad as the USB models.

Understood.  I *really* don't want to be in the hardware business.
(*Nor* the software business!  :> )  So, I want to find COTS
"modules" that I can just "talk to".  E.g., the Homerun gizmo is
a win because it doesn't sit *on* an internal bus.  As such,
the "API" has to be cleaner... no black box software that I have
to support (along with the prerequisites that *it* wants to
impose on me!).

I'd rather just crank out a hardware design and let someone else
manufacture it (e.g., sparkfun).  Then, see what other folks
(who probably don't have the hardware design capabilities and
would, otherwise, be stuck repurposing PC's) can do to enhance
the functionality.
 
I.e., move the state of the art a bit further down the field and
see where it goes from there...

Time to download the latest pkgsrc version and start rebuilding
my tools...

--don