I am using DNN 4.8.1 and I'm continuing to see this issue, most noticably with Evotiva.BackupNative PRO edition vers. 3.0.2.43031

I have the schedule  mode set to 'Timer', and had Evotiva.BackupNative scheduled to run once a day.  However it started running every few minutes, and I had to disable it.

I have similar issues with all of the other scheduled items, but it's most  glaring for Evotiva's backup module.

Looking further into this, it looks like other scheduled items are also running much more frequently than they should be...for instance, I have Purge Users Online set to run every 5 minutes.  But when when I run this SQL query, I should only see one 'future' task, but this is what is displayed:

select * from ScheduleHistory where nextstart >= getdate() and ScheduleID = 1 order by ScheduleID

While the 4.8.1 fix to GetScheduleNextTask did change the logic to return only one item, the problem with it is that it will return another one on the next call...in other words, if running the scheduled task creates ScheduleHistory entry 1419 and 1420, then GetScheduleNextTask will return 1420, and then 1419.  What needs to happen is that ScheduleHistoryID 1420 never should be created, since these items are obviously not 5 minutes apart.

Since I'm not a DNN developer (just a "benefactor"), I will ask that someone please put this back into the issue tracker...Please let me know if I can help troubleshoot this further, and if you need any more information. 

At our site we are running DNN v4.8.0 and have noticed this problem with the scheduler running multiple times for each "instance" of DNN.  We have a setup which is (I suppose) more like a web farm, in that a couple of the portals really run as separate instances.  I think this is due to a previous requirement brought on by needing to offer HTTPS, therefore a separate DNS name and IP and a separate DNN website in IIS.

Anyway, regardless of the reasons, when we turn on the Search Indexer task, it starts running multiple times.  This eventually catches up with our SQL server, which then goes to 100% utilisation.  Our interim fix has been to disable the search indexing task and only run it manually once/day, but I'm getting a bit tired of this manual intervention.

We tried some of the suggestions earlier in this thread, which involved modifications to the underlying SQL stored procedures, but this did not resolve the issue.

So now I am wondering whether this scheduler "bug" is likely to be fully addressed in any future release, in a way that is compatible with an environment like ours.