[mythtv-users] another scheduling strangeness/question

[Brian J. Murrell]

On Tue, 2010-08-31 at 09:52 -0500, David Engel wrote: 
> 
> Shouldn't the implicit "--refresh-tomorrow" eventually take care of
> that?

That seems to be the case.  These situations are typically days out,
rather than occurring within the next 18h or so.

But in the intervening 12 days, scheduling decisions are being made
around recording this showing that will, in the 24h leading up to it end
up changing.

While I can't come up with a use-case where such a situation could end
up in something not being recorded (i.e. a conflict) because the
scheduler thinks only until the upcoming 24h that it was going to record
something, it also doesn't seem like it would be a bad thing for missing
data at the time of fetching on one channel to be filled in by data
present for another channel with the exact same xmlid number.

But even without multiple sources and multiple channels with the same
xmlids, if it's typical for the data on day +13 to have (lots of?)
"generic episode" data just because details have not yet been made
available from TMS, but then fetching that same data the next day, when
it's +12 fills in missing bits[1], would it be so bad to do a
"--refresh-day-before-last" on each daily mythfilldatabase run?

> Brian, when was your last mythfilldatabase run and which Oprah is
> scheduled for the following day?

Yeah, per the above, typically the data within 24h is better.  Although
at the moment it's not for tomorrow, but I am also 26h since my last
mythfilldatabase.  I tend to expect the next fill should be shortly.

b.

[1] Even back when we were all getting data from TMS for free, I oftent
thought (and think even suggested to TMS) some sort of "delta" protocol
would be hugely useful for fetching this data.  If the data were added
to the (schedules direct) database in a "log" format, when one wanted an
update one could just say (to schedules direct) "give me all of the data
changes since log entry $n" and that would include both changes/updates
to programs/timeslots that you have already fetched as well as programs
which are new (i.e. +13 days' new data).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://mythtv.org/pipermail/mythtv-users/attachments/20100831/1b597097/attachment.pgp>