[mythtv] mythfilldatabase refresh defaults for Schedules Direct (was Re: mythtv commit: r16471 by kormoc)

[Michael T. Dean]

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.
>   

OK, so:
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 
7:00am.

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 
sprang:  
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 
they want.

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 
MythTV devs.

Mike