[mythtv-users] Schedules Direct - Cliff's Notes?

[Gary Buhrmaster]

On Tue, Oct 7, 2014 at 10:53 PM, Kirk Bocek <t004 at kbocek.com> wrote:
>
> On 10/7/2014 1:08 PM, Ian Evans wrote:
>
> On Tue, Oct 7, 2014 at 3:09 PM, Thomas Mashos <thomas at mashos.com> wrote:
>>
>> On Tue, Oct 7, 2014 at 11:36 AM, Kirk Bocek <t004 at kbocek.com> wrote:
>> [snip]
>
>
>>
>> > Well now I'm confused. My crontab entry looks like:
>> >
>> > ... /usr/bin/mythfilldatabase --remove-new-channels --dd-grab-all
>> >
>> > So if that doesn't work with the DNS or /etc/hosts fix what is the
>> > answer?
>> >
>>
>> Yuck, why are you running that in cron and not letting the backend
>> take care of it?
>>
>>
>
> Can't speak for Kirk, but there was a thread a few months back where a few
> of us were having constant failures during the backend recommended time. It
> was suggested that we just create a cron entry to run at a time away from
> the recommended time. When we did, our schedule download issues disappeared.
>
>
>
> Yeah, Thomas, so there! That's why! Cron rules! :)

What I presume was an overloaded TMS-DD service (at a
particular time of the day) is likely no longer relevant when
one changes to the SD-DD service.  So the rules change
for you RSN, and any justification based on what happened
last week at a service far far away likely evaporates (Ok,
both TMS-DD and SD-DD are using Amazon EC2, but still,
they are different services, and they appear to even be in
different availability zones, although I have not traced all
the load balanced versions to be certain of that).

I have nothing against cron.  I use cron extensively (although
not for mythfilldatabase, since I preferred to have the BE
manage the logs and perform the randomness),  But if you
are going to use cron for things like downloading information,
the least you can do is to add in a random delay to avoid
everyone starting downloads at the same time with something
like (your cron service may vary) a 'sleep $(expr $RANDOM \% 3600) &&'
at the beginning of the command.  Everyone wins.