[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