[mythtv] mythfilldatabase refresh defaults for Schedules Direct (was Re: mythtv commit: r16471 by kormoc)
Michael T. Dean
mtdean at thirdcontact.com
Mon Mar 10 22:52:04 UTC 2008
On 03/10/2008 05:22 PM, Tony Lill wrote:
> "Michael T. Dean" <mtdean at thirdcontact.com> writes:
>> Though I'd make a case for also removing smartfill--as, rather than
>> simply running off-schedule (like the cron scripts do), it downloads 6
>> days of data from SD every day. True, it may be run through
>> mythbackend, so it would be on schedule, but grabbing 3x the data
>> whether it's needed or not...
> It's 5 days,
Unless it's 6 days--i.e. when it decides to do a --refresh-today (if it
runs sometime before 7:00am).
> and that's only on Mon-Wed when it refreshes the
> following weekend. The rest of the week it just adds a +7 day refresh.
Mon - Wed: 5 days (+1, +7, +13, and Sat/Sun)
Thur - Sun: 3 days (+1, +7, +13)
On any day, it will download one extra day (today/+0) if running before
I really didn't care to explain the details of the script. I admit I
was wrong to say, "Every day," though doing so was a lot easier than
explaining the details of the implementation (which are really not the
point of my post--see below). Perhaps I should have said, "up to 6 days
every day," though I really didn't spend a lot of time considering the
implications of all my word choices.
>> It's purpose was to allow users who felt they had too much "No Data" in
>> their guides to fix it a week out to allow for better scheduling. I'd
>> recommend that instead, we take the more responsible approach and just
>> keep a max of 13 days listings (doing +1 and +12) for SD even though +13
>> might have (at least some) data.
> The purpose was to get around the fact that the networks can't leave
> their shedules alone for 12 days!
OK, I was condensing the history based on my recollection of the thread
I believed to have been the one from which the idea to create the script
http://www.gossamer-threads.com/lists/mythtv/users/290226#290226 . And,
besides, I don't believe that the script serves the purpose you
mention. I'll concede that the schedules change. I don't think the
script gets around that fact.
> Programs that your were expecting to
> be able to record 12 days out vanish when the +1 update
> happens. Before smartfill, and the option change to mythfilldatabase
> that it demonstrates, the only option was to use --refresh-all, but if
> you prefer that ;-)
Why not? With the script we're already saying that the mythfilldatabase
behavior coded into Myth--using an algorithm that the devs involved
(many of whom were working with TMS/XMLTV)--felt was appropriate is not
actually appropriate. At that point, users might as well run whatever
Or, if what's in Myth is wrong, we could just fix it /in Myth/. Or,
even, the legacy built-in grabber in Myth could be removed, users could
use tv_grab_na_dd, and the behavior could be fixed in XMLTV.
And no one has done any measurements to see how likely the situation
is/how frequently issues occur. Sure, it seems like it's all important
and it happens all the time because you /only/ remember the cases where
the default behavior failed. But, most all of those downloads are
probably unnecessary when factored over time. There are periods when
there are few new shows airing (i.e. off season, writers' strike, ...).
There's also the likelihood of a particular change occurring, of that
change being to an airing of an episode that was rescheduled for later
recording. Those likelihoods differ depending on the number of capture
cards, the number of channels, the number of recording schedules, ... I
admit that I, too, have no hard data, but I really believe that most of
those re-downloads are unnecessary. Besides, who's to say that the new
data you downloaded is actually more accurate than the data you
had--i.e. the networks may change the schedule again.
There is (and has been for quite some time) a wonderful warning on the
/only/ setting in Myth that could make the constant re-download of data
in case of change useful:
Reschedule Higher Priorities
Move higher priority programs to other cards and showings when resolving
conflicts. This can be used to record lower priority programs that
would otherwise not be recorded, but risks missing a higher priority
program if the schedule changes.
For users who manually choose to defer a higher-priority recording 'til
later, the same warning applies.
And, the fact that to a user the name itself indicates that the script
is better than what's in Myth is, IMHO, annoying. Here "user" means
someone who doesn't care to read the script to see what it does, who
doesn't care to research the purpose of the script, who doesn't
understand the implications of the behaviors produced by the script--or,
for that matter, the problem the script attempts to solve, or who
doesn't understand the algorithm used by Myth--i.e. most anyone who just
wants to use Myth.
I really don't like encouraging users to use any --refresh arguments. I
really want Myth to just do the right thing.
Anyway, this is just my opinion and not the opinion of MythTV or the
More information about the mythtv-dev