[mythtv-users] everyday i have to make sure myth worked the day before

f-myth-users at media.mit.edu f-myth-users at media.mit.edu
Sun Apr 3 21:47:31 UTC 2011


I like the idea of using generic power recording rules to reschedule
failures, -but- it's incomplete for my use case.

One thing that could definitely help, even given power rules, is an
additional column somewhere in the schema that user-supplied code
could set to indicate how happy it is with the recording.  It needs
to be in a row that's available -during- a recording, not just after.
Ideally, it'd be available in both cases, so decisions could be made
now but they could be reviewed for any recording forever after.

Then, things like my EAS scanner could do one of two things:
(a) the old way, where it or a user would manually force a rerecord
(b) the new way, where a bit gets set in the DB to indicate that some
    user-supplied, contributed script decided for whatever reason that
    the program doesn't meet its criteria.

If that bit existed, the EAS scanner could set the DB field instantly,
while the recording was in progress, and then presumably use something
in the python bindings (I hope this wouldn't require speaking myth
protocol directly) to kick off a reschedule.  (The reschedule must
happen immediately because sometimes the only repeat of a program is
immediately after the first airing, with no gap, and if you're using
pre- and post-rolls to ensure you get the whole thing, if there was no
other reschedule during the first showing, the scheduler wouldn't know
to rerecord until several minutes into the second showing.)

I'm a big believer in user-definable hooks.  Many programs gets
-enormous- flexibility from before/after/around advice (e.g., Lisp
functions) or hook functions (Emacs major and minor modes), etc.
The nice thing about a "your data here" column is that users could
basically use it as a generic placeholder---if it's a string and not
just a number, they could use external monitors to indicate -why-
something failed in a way that would be reviewable later, and power
search rules could similarly use that data in making their decisions.
(I do exactly this, but I use an ancillary table, keyed by the same
keys normal recordings do, so I don't affect Myth's own tables.  It'd
be cleaner, if we want users to do this, to provide a column in an
existing table and not make user code first have to define one and get
things entered into it, etc---it'd encourage code reuse across such
extensions.)

P.S.  Some of the things my code wants to store, and that rules might
want to use, include things like "EAS alert", "excessive silence",
"poor video quality", "closed-captioning garbled or missing", "started
recording late", "crashed in the middle" etc, and each of those might
be recoverable in a different way or with a different priority.  Only
the last two are discoverable just by looking at when the DB things
recordings started or finished.


More information about the mythtv-users mailing list