[mythtv] mythfilldatabase refresh defaults for Schedules Direct

Tony Lill ajlill at ajlc.waterloo.on.ca
Wed Mar 12 21:05:28 UTC 2008


"Michael T. Dean" <mtdean at thirdcontact.com> writes:

> On 03/10/2008 05:22 PM, Tony Lill wrote:
>> The purpose was to get around the fact that the networks can't leave
>> their shedules alone for 12 days!
>>  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.

When myth was first written, it was a good policy, the networks were
much better behaved. Shows generally stuck to their timeslots, the
weekends weren't filled with repeat showings of weekday episodes, and
the networks weren't purposely trying to screw PVR owners by shifting
their shows by 1 minute. The world changed and mythfilldatabase didn't.

Given how networks behave now, and the existence of SD and the
possibility of them hosting the data themselves, would
mythfilldatabase be written the same way? I don't think so.

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

Without some change at SD, to provide schedule changes rather than
full day dumps of the data, I don't see how. XMLTV was designed to
scrape web pages, so the idiom was full day at a time. DD just gave us
a more efficient (at their end) way to do the same. Given these
contraints, mythfilldatabase did the best it could. If/when SD starts
hosting the data themselves, then perhaps we can fix this problem
properly.

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

I don't have any hard numbers either, but missing shows and having to
monitor the data and run mythfilldatabase --refresh-all by hand to fix
problems pissed me off enough that I took the time to re-write the
mytfilldatabase  refresh arguments and write that script. Since I
started using it, I've had a fewer problems, so anecdotal evidence
says it does what it's supposed to, and at a lesser cost than using
--refresh-all. Perhaps the algorithm could be smartened even more, by
restricting it's behaviour to fall preview and sweeps months, but then
again, the networks are saying fall preview is a thing of the past.

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

UNfortuantely, unless I buy more capture cards and pay my cable
company more to rent another STB, that setting is mandatory.

> 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 think any user savvy enough to even find the contrib directory will 
probably read the script, since that't the only way to find out how to
use it. I think that goes for most of the scripts there. 

> I really don't like encouraging users to use any --refresh arguments.  I 
> really want Myth to just do the right thing.

Me too. Shame it doesn't (yet).
--


More information about the mythtv-dev mailing list