[Tfug] Radio/TV cards?

[John Gruenenfelder]

Don,

On Sat, Sep 29, 2012 at 3:33 PM, Bexley Hall <bexley401 at yahoo.com> wrote:
>
> Let me step back and go into the thoughts behind my criteria...
>
> There's just two of us.  And, we tend NOT to be big TV consumers.
> Radio tends to see some regular use.  And, sometimes we're both
> watching TV but different programs.  Or, some of the content we
> are listening to/viewing is "canned", etc.
>
> So, more than two "content sources" seems wasteful.  Yes, it's
> possible that you might want to record one thing while watching
> (listening) another.  But, do you allow *both* of us to record
> while viewing?
>
> And, what about things like PiP?  Should I be able to watch
> something, see something else PiP *and* record something else
> at the same time?

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

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.

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

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.

> With this in mind, SD is acceptable to us, currently.  But, would
> probably NOT be "desirable" to someone else undertaking a similar
> effort after me.  I.e., like you, if I had SD kit already, I
> probably wouldn't discard it just to have the latest and greatest;
> but, starting from scratch, it seems like there's not much to
> gain ($?) in going that route vs. the HD (dunno).

Yes, that makes sense.  I mostly mention the SD Hauppauge products
because they ought to be very cheap now.  Being analog, Hauppauge
doesn't make them anymore, but they were very popular and I'm sure you
can find the whole spectrum online for a good range of prices.

>> I've been using Hauppauge products for a long time now.  Their SD
>> products were always top notch, however I cannot say much about their
>> HDTV products as I haven't used any.
>
> I know they used to make TV tuners prior to the DTV devolution
> but don't know what their offerings are, currently.

They still make TV products, including HDTV receivers.  Many of them
now (from most vendors, it seems) are USB devices, though there are
still expansion card products, too.  Since HDTV is already in a
compressed digital format, most of the products from Hauppauge and
other vendors just receive the bits and software either displays them
or dumps them into a file.

>> I am using a Hauppauge WinTV PVR-250 which can take SD input from
>> S-video, RCA, or coax and output an MPEG-2 stream of configurable
>> quality.
>
> OK, so it's essentially a "capture card" with MPEG encoder?  I had
> thought of tying the DTV STB's that I have to such a capture card
> as an interim measure (the STB's have an external serial port
> which can be used to control them).  But, I'm thinking that might
> be more work that I will eventually have to "do over" (I'm getting
> too old to be queuing that many projects!  :> ).

Correct.  It can receive SD signals in a number of ways, runs the data
through the MPEG encoder, and then the user does something with it.
The software takes care of almost all of the work both coming and
going, so it tends to be a very simple task for the user.

> 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.

>> You mentioned two broadcast channels and multiple cards, so
>> I'm guessing you want to receive/record both simultaneously.
>
> 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.
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.

> 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.

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.

HD, though... that's another matter.  In one respect, it's the very
same concept only with larger video files.  That will certainly tax
the CPU, the storage subsystem, and possibly the network much more
than SD does.  For a modern machine, however, I think it should be
able to handle it quite well.  The element that is taxed the most is
likely the CPU when it is decoding HD video for playback since it must
do it fast enough to not skip.  Decoding for other purposes, like
commercial detection, can be much more leisurely about time required.

The other issue that is new with HD (even though it is in no way
caused by HD) is the manner in which the HD data is received.  These
devices were very uncommon in the SD days, but now USB
tuners/encoders/recorders are extremely common and available from many
vendors.  The hardware required inside one of those USB dongles is not
that complex.  Some sort of ATSC tuner and... not much more?  The
signals are already digital and MPEG encoded, so they just need to be
fed into the computer and used.

I have actually used one of these (I forgot earlier), very briefly.
It works, yes, but they generate a *lot* of data and suck up most of
the bandwidth available on a USB 2 connection.  I also found that
devices can severely tax the system.  Whereas a SD PCI encoder card
causes a very small change in the system load, running "top" and then
using one of these USB HD recorders, I could see that the percentage
of the CPU time spent doing "sys" tasks changed from say, 2-8%, all
the way up to a fairly constant 45% sys usage.  That's *big* and has a
huge effect on how much other work the computer can do.

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.

>> Its inputs are a bit odd... it has two coax input connectors,
>> one for TV and one for FM radio.
>
> Separate tuners?

Oh, no.  Just separate antenna connectors.  Essentially two full
PVR-150 devices on a single card.  The radio antenna coax connector is
routed to the radio device on tuner #1, I believe.  Most likely there
is radio hardware on tuner #2, but there is no way to access it.


--John Gruenenfelder    Systems Manager, MKS Imaging Technology, LLC.
Try Weasel Reader for Palm OS  --  http://weaselreader.org
"This is the most fun I've had without being drenched in the blood
of my enemies!"
        --Sam of Sam & Max