@chris_of_arabia did you check that the file /cron/cron_exec.php is being called by a cron job in a regular basis, as is instructed in this page: http://b2evolution.net/man/scheduler?

Regarding your second question, maybe Auto prunning is set to "On every page" in your site (which is the default value), so you should change this to "With a scheduled job". You can find more information in this page: http://b2evolution.net/man/hit-logging

OK thanks. Looks like I have reading to do, as CRON jobs currently escape me

Well I've set something up in cPanel which looked straightforward enough. We'll see in a couple of hours whether I did it correctly.

Just coming back to this one, with the help of my host, I got what appears to be a correctly configured CRON job set up. The host has confirmed today that the job ran as scheduled from their perspective and had no issues reaching /cron/cron_exec.php , however, as I look at my b2evo scheduler page, there is no sign that any of the scheduled jobs are any different to the screenshot above - in fact I'd say they were identical aside from the two errors, which I deleted days ago.

Would I be right in thinking that my scheduler page should now be showing new dates if the job had run as expected last night?

Can you post a screenshot from the cron job you have configured in cPanel? How often does it run? (Ideally it should run every minute)

The timing frequency may be where I'm going wrong. CRON jobs are something I've not really looked at previously, so I've currently got it set to once every 24 hours. Here's the screenshot though.

You definitely want to run it every minute or 5 minutes if you want to be conservative.

Otherwise, b2evolution will execute only ONE action from it's scheduled tasks list, every 24 hours.

OK, I'll modify the job later and see what happens overnight.

I didn't need to wait until overnight, as they've now all run and are scheduled for some time in the future.

It does seem that once a minute is a bit of an overkill - do hosts not have to concern themselves with CPU time being sucked up with that?

It takes less CPU to do a "shall we process some cron job now? oh, nothing in the queue right now, quit immediately" than to process a spam post by a spam bot (which also seem to happen every minute)

I guess we're a few days on now, and I've just taken a look at the Scheduler page to see that the job ID has reached 499. During the time running, I've only have one email notification to say a job had timed out without running; it worked fine the next time ot was scheduled. So far then, all is well.

Dont know if there's any difference but I am adding my cron checks as follows:
wget -q -O - http://domain.com/cron/cron_exec.php >/dev/null 2>&1

I can't say I understand the one I've got, I needed my host to sort that out - CRON jobs are not something I have my head around yet, and I can't honestly see me changing this now - it took me 10 years to get this one set up.

Calling /usr/bin/php is more efficient than calling wget because it directly executes the corn handler script instead of going through a web request that calls the corn handler script.

Both will work though.