[mythtv-users] Notification of conflicts

f-myth-users at media.mit.edu f-myth-users at media.mit.edu
Tue Sep 15 00:26:49 UTC 2009


    > Date: Mon, 14 Sep 2009 13:20:25 -0700
    > From: Jim Stichnoth <stichnot at gmail.com>

    > If you still have problems finding the perl script or getting it to
    > run, you could always try "mythbackend --printsched".  Conflicts will
    > be indicated by a "C" character in the column labeled "N".  Unless the
    > formatting of --printsched has changed, this command should work:

    >   mythbackend --printsched | awk '/^Title - Subtitle/||substr($0,70,1)=="C"{print}'

I do something similar---since I log fairly verbosely from my backend,
I have several different greps all glued to its output with tee, each
of which feeds into various notifiers if they trigger on something.

In other words, I have something like this:

  mythbackend [options] | tee >(scanner1) >(scanner2) ... | split [options] logfile

where, for conflicts, one of the scannerN entries is

  >(grep --line-buffered -E 'C   [0-9]+$' | notice-schedule-conflicts)

and notice-schedule-conflicts is a simple bash script that stores each
hit in a file; if it's already in the file, I've already been notified.
The file gets cleared before mfdb runs.  Thus, I only get notified
about any given conflict once a day, instead of every time the
scheduler runs---but since it's monitoring the backend log rather
than doing an explicit printsched every so often, I get notified the
instant the scheduler first creates the conflict. so I find out if it
magically -creates- a conflict right in the middle of primetime when
nothing's been edited and mfdb hasn't run [which it did once] and also
so I know the instant I add a scheduled recording whether it just
bumped something, rather than several hours later.  [It uses the same
cheesy xmessage popup strategy as trac #6899, which is realtime and
good enough for me.]

Note carefully that that grep pattern looks for whitespace and digits
at the end of the line, but does -not- include anything else---in
particular, minus signs.  That means it will -not- notify about a
conflict in something with negative priority.  That means something
I've explicitly said I don't care is dropped won't also spuriously
notify me, either.

[Why do I grep in the tee instead of in notice-schedule-conflicts?
Because n-s-s is a simple line-oriented bash script [it has to be,
so it can immediately add each hit to the don't-tell-me-again file,
unless I'd like to write it in a real language].  Not prefiltering
its input to only give it relevant lines raises its runtime many
thousandfold, to the point where it becomes a noticeable percentage
of the backend.]

Note also the --line-buffered; without it, you might never get the
notification at all, since the grep might not emit anything at all
until it's got a bufferful of output (which could be quite large)
or until its stdin is closed (which is presumably never).


More information about the mythtv-users mailing list