> > On 04/20/2006 03:17 PM, Tony Lill wrote:
> >>f-myth-users@medi... writes:
> >>AFAIK, mythfilldatabase sets this flag based on the dates. You could
> >>go in there and change 14 to 21 or 28.
> >>>P.S. I suppose I could ...
> >>If you don't want to change mythfilldatabase,
> > mythfilldatabase --nomark-repeats
> > Mike
> Throwing out the baby with the bathwater...
The problem here is that it's insidious---after all, -most- programs,
even on the problematic PBS channels, have correct airdates, and even
most episodes of the series I'm looking at right now---but apparently
the new season they're airing has all the "original airdates" 3 weeks
in the past, and I'd never have picked up on this if my TiVo hadn't
been doing it -right- (causing me to notice that Myth was getting it
wrong). [And why am I still using a TiVo at all? As an error-check
on Myth's behavior until I'm convinced Myth is reliable enough. At
the moment, that error checking just paid off.]
Assuming that you're recording either all new episodes or all episodes
of any age, the only difference in the behavior is the transient
behavior as you accumulate new recordings. I'd argue that making this
transient (say) a month instead of a week is just conservative design,
because it's -much- safer to notice an "extra" recording and cancel it
than failing to record something at all! That will probably -never-
be noticed and thus one could miss an entire season of something (as,
indeed, I would have w/this series if I hadn't had the TiVo around
to point the finger). Sure, with vastly-hyped season premieres, you
might hear by word of mouth, but this was an obscure little PBS
documentary series with no buzz at all and a very irregular
season-starting time. (And why a month? Because I've never seen a
genuinely new episode with an original airdate more than a month in
the past, but I've -frequently- seen them with airdates more than 10
days in the past.)
Arguing that I should write a Power Search rule with a delta between
two dates is also missing the point---I'll probably do that in this
case just to get this series recording correctly, but you can't expect
someone to do that with -every single program- they're trying to
record, and yet by definition you'll never know when the broadcaster
might pull a fast one on you and air a "new" ep with a 10-day-old
original airdate unless you simply monitor everything, which removes
the advantage of having the Myth do it for you.
The whole point of the original airdate, as I understand it, is to
prevent getting -last- season's (or last decade's) episodes in this
season. But nobody has seasons only one month long, much less one
week long. So why make this slop factor only a week? It would still
accomplish the same thing if it was a month, -and- it would be far
safer in the face of these weird broadcaster behaviors.
If I haven't been sufficiently convincing here and there's still
widespread disagreement about this slop factor, how about making it
read from the database instead of compiled into mythfilldatabase?
At least -that- way individual users could fix the behavior when they
run into it without having to recompile---which is particularly
annoying when many users get their Myth via a packager and the -last-
thing they should be doing is compiling their own versions of
individual programs---they'll likely get out of sync, or get the
dependencies wrong, or do other things that will increase the load on
these very lists because users are forced to compile when otherwise
they could have left their fingers out of the dough.
If I submitted a patch against SVN to fix this, would it be accepted?
Does anyone else feel like they might like to do this? (If so, your
patch will arrive sooner than mine, since I can't get to this for a