[mythtv-users] (SOLVED) Mythfilldatabase returns incomplete schedule data (Patched)

[Michael T. Dean]

On 01/20/2013 01:50 AM, Raymond Boettcher wrote:
> So they should redesign the code a little.  Make it do a full pull every 5 days and pull just tomorrow to refresh TBA, etc once a night.

As Raymond said, if you're doing a "small pull" (of just tomorrow), it's 
as much server resource usage as doing a full pull of all 2 weeks of 
data.  Since bandwidth isn't a problem for them, you might as well--as 
long as you're pulling data--pull all 14 days of data and get the full 
benefit of having the most-up-to-date listings data possible.  And, 
Schedules Direct is paying for the listings data, TMS isn't trying to 
get us to reduce bandwidth usage.  (As a matter of fact, I wouldn't be 
surprised if Windows MCE and TiVo are pulling data in a similar 
way--getting everything in a single pull--and possibly even using TMS 
bandwidth (versus TMS giving Microsoft and TiVo a copy of their database).)

>    The 5th day will also count for the next day refresh since that data is included in the full pull still creating only 1 request for the night.  So it would run a little differently but still result in 1 request a night while conserving a little bandwidth.

Keeping a full 14 days of listings data (rather than letting that 
dwindle down to just over a week) is actually very useful for scheduling 
recordings on systems with insufficient tuners (i.e. most users' 
systems).  Therefore, the default run mode for mythfilldatabase is to 
pull tomorrow and +13.  Because this is actually more work for TMS than 
if we pull only once, but get everything (all 14 days of listings), and 
because getting all 14 days of listings gets all the updates (which is 
even better for scheduling recordings on systems with insufficient 
tuners), we actually recommend that users

The only reason --dd-grab-all is not the default for Schedules Direct 
users is because users with underpowered systems (either backend or 
database server systems) will encounter serious problems if they use 
--dd-grab-all.  Therefore, users with sufficiently powerful systems 
should use --dd-grab-all, and be happy that a) they have the best 
listings data possible and b) they're actually using fewer resources to 
get that great data than they would use with the default "works on 
underpowered systems" configuration for Schedules Direct.

That said, there's a very good chance that your concern that the 
built-in code for pulling data from Schedules Direct isn't good enough 
will not be a concern for long--as some of us are pushing to remove all 
of that code and use code created (and maintained) by a project 
specifically for pulling listings data, XMLTV.

Mike