P.S. In case it gets lost---the code of mine that I pointed at can be
used by anyone right now for any myth version; if someone would like
it to (say) talk to the Python bindings to tell myth to rerecord, or
to stick something in a DB field, it would be very easy to change the
custom-alerter line at the bottom of scan-and-notify-on-eas to talk
directly to the Python bindings (though you might also want to clean
up the direct reads on the DB and use a modern API to figure out the
program title, or just punt 'em entirely since the bindings really
only need starttime etc). That would be a nice little patch to
add to the ticket.
Also, if anyone wants to test their own thresholds for things like
silences, or test detection of non-EAS tones (perhaps other countries
do something similar?), the existing code in that ticket can be run
in a mode that just chugs full-speed over a large corpus of existing
recordings; that's how I did all my regression testing. (Actually, I
ran over the entire corpus once and yanked all the audio out using the
same mplayer args that get used in the realtime case, since mplayer is
90% of the computation, and then ran over -that- repeatedly---10% of
the CPU and 1% of the disk space, IIRC, so I could test thousands of
recordings very quickly after each tweak. That's another problem with
building something like this directly into myth.)