GETTING THIS RUNNING

The toplevel, user-callable script is notice-new-files.  It's
recommended that this be started up by whatever starts up your
backend(s).

Note that using this in a system using storage groups or multiple
directories will require running one instance of notice-new-files
per directory.  It's also recommended that this run locally, e.g.,
that you not pull files to be checked from a network file system,
since the vast majority of those bits are immediately thrown away
by mplayer canonicalizing the audio.  Since it takes 1% or less
of the CPU to run mplayer in real time (at least with SD inputs)
and to do the detection, it shouldn't be an issue even on lowpower
backends.

Also, since this is designed to run in real time on recordings
in progress, it's likely that it will be reading bits from your
filesystem cache, since those same bits were just written to disk a
fraction of a second before.  This means it shouldn't cause your disk
heads to thrash, even if you have mulitple streams going.

Everything in the EAS directory must be installed somewhere in your
search path on each backend; /usr/local/bin/ would be a good choice.
Note that you'll have to at least change the first line ("alerter")
in scan-and-notify-on-eas so alerts will go to the right machine.

Everything in the Alerter directory must be installed on whichever
machine runs X and has a head that someone looks at with some
regularity; this should be the host named in scan-and-notify-on-eas.
You should run fake-zephyr-eas on that machine.

The stuff in the Debugging directory is optional and can be installed
anywhere.  It's never called by the stuff above and exists only to be
called by hand.  It was designed to generate -just- the canonicalized
audio for a very large corpus of existing recordings, so I could
rapidly debug and tune both the EAS and silence detectors.  (Because
the vast majority of both the runtime and disk I/O required is for
mplayer to yank out and reduce the audio from a recording, I
pregenerated a 60G corpus from a thousand recordings or so over a span
of a couple of days, and could then scan everything in that corpus in
an hour.  I then finished the tuning by scanning a small number of
false positives or false negatives in seconds.)  (And why's the stuff
in Debugging written in tcsh?  Because I figured that, as long as I
was slumming by writing in C and shell scripts instead of my native
Lisp, I might as well make everyone else feel my pain as well... :)
Note that the Debugging scripts may mention directories you won't
have, since they were were I was putting stuff during testing; just
change these to suit your tastes.  (In particular, there are "-niced"
versions that stop working while a different piece of automation I run
does its thing; you probably won't need these versions, but whatever.)

If you'd like to scan everything you've already recorded, just to see
what you'll find, you have some choices:
 o  Do something like (untested!)
      find SOMEWHERE -print0 | xargs -r0 -n 1 scan-and-notify-on-eas
 o  Start up notice-new-files and then "touch *" in the directory
    you aimed it at (but this will probably bog your system down in
    zillions of parallel processes)
 o  Pregenerate and scan a corpus using the stuff in the Debugging
    directory

CUSTOMIZING YOUR SETUP

Both EAS detection and silence detection are handled in eas-detect.c.

The EAS detector is hardwired to detect only what look like valid EAS
tonebursts.  There are lots of comments in the code about how you
might change this if you're trying to detect something else.  Note
that it doesn't look for a perfectly-formed EAS---just enough of one
that I don't see false positives.  This makes the code simpler and
less likely to have a false -negative-, which would miss an alert.

The silence detector has lots of various knobs you can twiddle, and
one of the scripts (pcm-tail-follow) shows how you can use regexps
based on the filename to twiddle those knobs to account for how much
or how little dead air might indicate a problem, depending on whether
you're recording a highly-processed no-dead-air-at-all-costs station,
or a movie channel that might show a totally silent credit roll for
minutes.  The actual regexp in the version of pcm-tail-follow included
here is almost certain to be wrong for you unless your lineup is
identical to mine; changing it to something that can't appear in
a filename will disable changing that knob entirely and will use
defaults that should be reasonable for everything but artsy movie channels.

Note that eas-detect.c has a very large number of comments in it about
how the silence detector works and what values you want to use to tune
it to your particular sources.

Notifications are done using a really cheesy protocol that uses netcat
to talk to a receiver process somewhere else on your network, which
allows running things that might generate notification on headless
backends.  The receiver just calls xmessage to pop up a message.
Obviously, there are less-hackish ways to do this, but this worked
for me.

FUTURE WORK

The next obvious step, of course, is to use whatever bindings are
available in some Myth version to ask the scheduler to autoreschedule,
in case a problem is detected when no one's around to see it.  This
probably requires code support in Myth proper, and also various policy
decisions, such as what to do when an autoreschedule would move
another recording---or, worse yet, cause a conflict.  I would be
overjoyed if someone were to take this on.
