[mythtv-users] zap2it - rsync updates?

[Brad DerManouelian]

On Oct 19, 2006, at 10:55 AM, Michael T. Dean wrote:

> On 10/19/06 13:30, Brian J. Murrell wrote:
>
>> On Thu, 2006-19-10 at 13:23 -0400, Michael T. Dean wrote:
>>
>>
>>> And, in truth, it /is/ a waste to re-download the listings from 8  
>>> days
>>> from now in case of updates.  It just doesn't matter because Myth  
>>> will
>>> get the update /before/ it's required (Myth can't start recording  
>>> a show
>>> that airs 8 days from now until, well, 8 days from now).
>>>
>>>
>> Yes, but a change to what's showing in 8 days can affect scheduling
>> today.  Let assume for example that a show I want to record today  
>> (the
>> only showing of it) "foo" is being conflicted by a show "bar".   
>> The myth
>> scheduler decides to record "bar" due to the scores of the two shows.
>>
>> However yesterday, zap2it added to the schedule that in 8 days a
>> duplicate showing of "bar" will occur.  Now I lost the opportunity to
>> record "foo" and postpone "bar" for the next showing which would have
>> happened if I had fetched the entire zap2it schedule again.
>>
>
> So Myth is modified to waste TMS's resources, you get your update,  
> Myth
> sees "bar" in 8 days, you have "Reschedule Higher Priorities" enabled,
> so Myth records the lower-priority "foo" today because it now knows it
> can record the higher-priority "bar" in 8 days.  Whew!  It's a good
> thing we got that update.
>
> Then, 2 days later, TMS gets another update, and the timeslot for the
> "bar" rerun has again been chainged--this time to an old repeat of the
> terrible show "snafu".  So, now you miss "bar"--the show that  
> raises the
> "bar" for quality TV--all because of a "foo"lish reschedule by the
> networks.  Stupid Myth.  Why did it have to download that  
> update...  ;)
>
> Oh, and this happens--timeslots that get changed once are often  
> changed
> multiple times.  Generally, the network just puts fillers in and, in
> many cases, makes up their mind the day before or even the day of
> broadcast.  So, neither approach will fix all the scheduling issues.
> Instead, it's important for you to get involved in the scheduling
> (proirites, recording overrides, get more capture cards, etc.) when  
> it's
> really important.
>
> Of course, this doesn't discuss the 300 days per year (total WAG) when
> there are no updates...
>
> Mike

I believe it's best to make scheduling decisions based on the most up  
to date information available. Not making them because something  
might change in future doesn't make much sense to me. This is why  
myth downloads x days (14 I think) ahead, then the next day to  
accommodate scheduling changes.

I quite like the idea of using rsync to make sure the *entire*  
schedule is updated every day while using less bandwidth than it's  
using currently for 2 full days of data. You'll be downloading 1 full  
day, then just changes to every day which likely amounts to very  
little compared to what's already stored. This is how my company  
delivers changes to large databases to its customers. We haven't seen  
any issues in several years and our bandwidth is very reasonable.

And if we're worried about load on user's machines, mythfilldatabase  
ties up a whole core on my processor and doesn't like letting go  
until it's done. When I had a single core processor, this resulted in  
missing data in programs being recorded so I don't think we'll change  
much using rsync.

Maybe off topic, but another nice addition to scheduling download  
times would be to take the suggested time from zap2it and perform the  
download at the closest time to that, but wait for the backend to be  
idle for x seconds (like EIT scanning does). If it doesn't become  
idle within x minutes, run it anyway. I guess we'd take the suggested  
time and queue mythfilldatabase at that time to run when the backend  
becomes idle.

-Brad