[mythtv] [mythtv-commits] mythtv commit: r23012 - in trunk/mythtv by cpinkham

[f-myth-users at media.mit.edu]

    > Date: Tue, 29 Dec 2009 17:43:56 -0500
    > From: Chris Pinkham <cpinkham at bc2va.org>

    > > (a) "Mythfilldatabase started".  You've got "ran", but I also arrange

    > > (b) "Scheduling started".  I monitor scheduler starts/stops (via

    > These are trivial to do.  I might consider changing the current 'ran'
    > versions to 'finished' to be more consistent in naming.

That's certainly what I was thinking, but I was starting simple. :)

[My basic thinking is, "Anything that takes perceptable time should
have an entry hook and an exit hook."  So keystrokes only generate
an event (god help us if somebody has a plausible use case for
KeyRelease events on the remote), but things that span nontrivial
amounts of time (recordings, playback, mfdb runs, scheduling runs)
have separate entry & exit events.  I kinda figured that it'd be
trivial to add them wherever needed once the framework existed.
Both Emacs's foo-entry/foo-exit hooks, and Common Lisp's before/
after/around advice, are invaluable for this sort of thing.]

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

    > I wanted the settings screen for this to be very very simplistic.  I

I also assumed that; figured I'd mention it even though (c) is a very
different kind of thing and potentially much more involved.

    > do have another patch for making the settings screen a little more
    > user-friendly, but that is waiting on another MythUI patch I'm working
    > on.

    > I didn't want events that the user had much control over because that
    > complicates settings.  I could see adding an event for each backend
    > after each scheduler run that said "Backend ABC's next recording is
    > in X minutes".  This would get sent for each connected backend.

[I assume this is already easy to compute because you have to figure
it out to know when it's safe to sleep a backend?]

Hm.  Certainly a user app could subscribe to 'em all and take the min
of them to guess when the MBE was next likely to be completely free.
(I'm thinking here of (a) backups, (b) mfdb, and (c) reboot-MBE-when-
convenient [pick up new kernel, deal with memory leaks, whatever].
Basic idea is, "When is it guaranteed safe to do this disk-intensive
thing where it can't possibly glitch a recording?"  Obviously, a user
who intends to do (c) might also want to monitor whether any frontends
are in use doing playback; it could subscribe to events ot just query
the inuseprogram table or whatever it's called.)

The solution I use works for me; I'm just brainstorming ways of making
it really easy for other pieces of Myth (backups & mfdb) to run when
minimally disruptive, since plenty of people can't let them run at
arbitrary times without having issues.  (In other words, my solution
is simple but not ready for prime time for everybody, but some
solution that is could simplify backup & mfdb non-interference
and hence I could abandon my tools once that functionality existed
in Myth itself.)

    > I also made a note to modify the 'Recording Pending' event to include
    > the hostname of the backend that the recording will be starting on.

    > Events should be simple, always sent when situation X occurs.  I don't
    > want to get into the settings nightmare that could be if the user
    > can start specifying when events fire.  The event should always fire
    > when the situation happens, it is up to the user script whether to
    > act on the event.  In this (c) case, the user script could act if the
    > backend was going to be idle for 2 hours, but not if the backend would
    > only be idle for 30 minutes.

Yes, I agree.  Someone could then write a fairly simple piece of code
that synthesizes the "MBE idle for -this- long" guess based on min of
all relevant events, and that could be used by a variety of callers.
It would hopefully be more general and more robust than the three-step
check I make (which also depends on the format of the "hours|minutes|
within one minute|soon|now" stuff emitted on port 6544 never changing
(and only works in one language) and hence is fragile and only usable
for my own hacks & not by everyone).  I mean, sure, one can also parse
the output of --printsched to the same end, but...

Another idea would be (and maybe this exists already in one of the
Perl or Python bindings?) simply some way of querying the scheduler
for the same information, instead of parsing out the status output.
But that's inferior because you'd have to poll every so often to get
it, as opposed to keeping tracks of events as they're spit out.

Anyway, thanks again!