[mythtv-users] Battlestar Galactica 1978 on SciFi

f-myth-users at media.mit.edu f-myth-users at media.mit.edu
Sat Apr 15 06:39:32 UTC 2006


    > Date: Fri, 14 Apr 2006 17:24:35 -0700
    > From: Bruce Markey <bjm at lvcm.com>

    > f-myth-users at media.mit.edu wrote:
    > ...
    > > I -then- used Custom Record in mythfrontend to create this rule:
    > > 
    > > program.title = "Battlestar Galactica" AND
    > > program.originalairdate < 20050101
    > > 
    > > The "Test" button correctly shows that the 6 old episodes airing
    > > tonight will match, but they don't show up in the schedule recordings
    > > list, nor are they highlighted as recording in Mythweb's Search page
    > > (which claims, for any of the ones I click on, that it's a repeat and
    > > will not be recorded).  And yes, I -did- finish the procedure by
    > > hitting Record and setting "Record at any time on any channel"
    > > and then saving the settings.  (And also setting a pre- and post-pad
    > > of one minute, though I doubt that matters here.)
    > > 
    > > I suspect that having the two rules (New Episodes Only, -and- the
    > > Custom Record rule) are not being OR'ed together as I'd expect.

    > That's an odd assumption. Only one rule can control one showing. If

Well, I made it because it seemed logical & it's what my TiVo did.
(E.g., all rules were OR'ed together, and then some were overridden
if the tuner was going to be busy then---but rule A could -not- keep
rule B from firing unless it was because rule A busied out the tuner
and thus inhibited B from grabbing it for some part of when B wanted
to be recording.  Hence, just because I had a Wishlist or Season Pass
that specified new episodes only was no reason that a less-specific
one couldn't decide to record something anyway.)

    > more than one rule matches the same showing, the more specific record
    > type wins (Single or Override would beat Channel or All). In this case,

Aha!

    > two rule are both presumably All. The tie breaker goes to the older

Aha!

[I'll bet these are documented in the HOWTO, but it's been quite some
time since I reviewed it, since I -thought- I knew the mechanism here.]

    > (lower recordid) rule so that what you've always relied on beats the
    > mistake you just made. Your old "New episodes only" rule matches all
    > showings, wins control, and marks the old ones as "r". The new rule
    > controls none of the showings.

    > Shortly before 0.19 code was added so that a rule that would mark a
    > showing as Inactive or Repeat will lose to other rules. Therefore, in
    > 0.19 your new custom rule would have won control of all the repeats
    > from the old series.

Ah---so this would have sort of accomplished the logical OR that I was
expecting.  (And since my new rule specified old airdates, it would
not also have spuriously caused 2003-era repeats from being recorded;
presumably the "New Episodes Only" rule would win for those [but only
really for 2006-era episodes], if I'm understanding this correctly.)

    > > Presumably the way to fix this is to write a single rule that says
    > > 
    > > (program.title = "Battlestar Galactica") AND
    > > ((program.originalairdate < 20050101) OR 
    > >  (program.previouslyshown = 0))

    > That could work. If you wanted to have different attributes for the
    > two series (priority, recording profile, recording group, etc.) you
    > could use two rules.

    > Old:
    > program.title = "Battlestar Galactica" AND
    > program.originalairdate < 20050101

    > New:
    > program.title = "Battlestar Galactica" AND
    > program.previouslyshown = 0

    > The difference here is that with this rule, the repeats are not
    > a match for this rule. IOW rather than matching everything then
    > marking the old ones as "r"epeat, it only matches the new episode
    > in the first place.

Oh, interesting---without looking at the code produced by MythWeb's
"New Episodes Only" logic, I was assuming that setting that flag in
fact merely set "program.previouslyshown = 0" in the SQL query.  You
seem to be indicating that something else is going on there.  (And do
I take it that the "Old" and "New" above are listed that way because
there's an ordering dependency on when they're created?  If not, I'm
not sure why you labelled them as such.)

[It's not at all obvious to me where MythWeb is implementing this
functionality (perusal of program_detail.php was unrewarding) and
it's also not obvious to me which actual SQL table is being used
to store what I imagine are SQL queries, at least without reading
through the scheduler code; it's a bit late at night for me to try
doing that right now.]

    > > P.S.  It's really, really irritating that I'm typing on a keyboard yet
    > > mythfrontend uses cellular-keypad-speak when I type digits, e.g., I

    > 0.19 has a virtual keyboard. You can press Enter for it to popup and
    > cursor around to use it. However, while the keyboard is displayed,
    > you can type on the real keyboard including the numbers without the
    > cell-phone entry hack.

Nifty!


More information about the mythtv-users mailing list