[mythtv-users] new Schedules Direct not random?

Joseph Fry joe at thefrys.com
Fri Nov 7 21:14:55 UTC 2014


>
> Would it be so hard to return no data and assign a new time some random
>> number of minutes later? Only do this when the load is high... but that way
>> you never need to worry about spikes.
>>
>
> Not all apps use the Suggested Time call.  Those that do, aren't the
> problem.
>
> You're suggesting if they download during a busy time they just get empty
> results?  Most of those folks wouldn't retry until the next day (same time).
> Eventually they'll be without data and notice.  Sure that's one way to
> handle it, but it's a little drastic, IMHO.
>
> I can also not size the server to handle the spikes and let folks randomly
> fail.  I'd rather not do that either.
>
> At SD we try to minimize support issues.. we all have day jobs.... and
> support takes a lot of time.


I guess I am just looking at it from the Mythtv perspective.

If I run mythfilldatabase at 5pm ET via cron, and you were to return no
data, but did set the suggested time call to 5:18... then mythfilldatabase
would run again at 5:18... and I have no issue with that at all.

If you have other products who are using your service, but not respecting
the suggested time call feature, perhaps this would serve to encourage them
to do so?  SD can certainly tell their customers that in order to use their
service they must implement that feature... especially because it keeps
costs down for everyone.

The only real issue I see is what if someone is troubleshooting and running
their job manually and this happens... Perhaps the request could contain a
flag to say "do not defer to a later time", and mythfilldatabase could use
a switch to set that flag.

And perhaps I am way off base here.. just seemed logical to me.

Another possibility would be to queue requests and process them in the
order queued.  However it may be more difficult to implement since the
client software would need to know to sit there idle waiting its turn.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20141107/5961a54a/attachment.html>


More information about the mythtv-users mailing list