[mythtv] [mythtv-commits] mythtv commit: r23012 - in trunk/mythtv by cpinkham
f-myth-users at media.mit.edu
f-myth-users at media.mit.edu
Mon Dec 28 09:06:05 UTC 2009
God damn.
This is fabulous. I'd occasionally opined that a generalized hook
system would be a Good Thing, but never thought anyone agreed with
me. Thanks, Chris!
("Recording started", for example, eliminates notice-new-files[-dispatcher]
in http://svn.mythtv.org/trac/ticket/6899, just as the first thing this makes
easier. Events are -always- nicer than polling, but the various bits of
automation I've written have always polled because I didn't want to have
to patch Myth directly and then take the risk that the patch would be
hard to roll forward to newer versions.)
Random feature suggestions---anyone else think these would be useful?
[If so, and if Chris doesn't beat me to 'em, I may implement them when
I've got a trunk devo system.]
(a) "Mythfilldatabase started". You've got "ran", but I also arrange
for some of my automation to avoid running when mfdb is kicked
off, to minimize system thrashing---even though the DB is on a
separate spindle, it can be a problem. By having a "started"
event as well as a "ran" event, you can know for sure when you're
in the middle of mdfb.
(b) "Scheduling started". I monitor scheduler starts/stops (via
watching the logfile) so I know when to trust what the scheduler
is telling me (e.g., a query in the middle of a scheduler run can
show "nothing scheduled"). Also, while I assume this isn't the
case in trunk, I see races that can lead to MBE crashes if I ask
at -just- the wrong time during scheduling, so I make sure I don't.
(This is also analagous to the "ran" event already present.)
(c) "Backend predicted to be idle for at least N minutes", where N is
chosen by the user. Right now, I extract this info by waiting
until nothing has been written to the recording filesystem for a
certain period, waiting until the scheduler is known idle (thus
no races & crashes), and then parsing the result of port 6544 for
the various strings that indicate when the soonest recording will
commence. Having this built-in "non-event" would make things that
need this functionality much more straightforward (e.g., backups
that might thrash the disk and glitch recordings---which I also
arrange to miss mfdb runs). [I say "predicted" because all you
can do is to go by what the scheduler is telling you; if some user
suddenly schedules something by hand to record right now, you're
sunk, but that's rare.] This is somewhat like what mythwakeup
needs to know, but not quite.
Thanks again!
More information about the mythtv-dev
mailing list