Moodle

From non non (nbhansen at midway.uchicago.edu) Friday, 30 June 2006, 09:08 PM:

I should add that the only table that shows any activity since I set this up is the daily table which now has nearly 8 million records all of which have as their timestamp the exact date and time I think I first launched my Moodle site (but earlier than I am trying to create stats for). It shows the last activity being 4:30 this morning, which makes little sense because that isn't even the time it should be running. All other stats tables remain empty.

From non non (nbhansen at midway.uchicago.edu) Friday, 30 June 2006, 09:09 PM:

I should change what I said, I did set it to do stats back to when I started, which isn't necessary, because I only want stats to when I released it to the public. But 8 million records for the moment I started? Makes no sense.

From Petr Skoda (skodak at centrum.cz) Friday, 30 June 2006, 09:10 PM:

assigning to MartinL...

From (penny at catalyst.net.nz) Saturday, 1 July 2006, 06:44 AM:

did you upgrade to an early 1.6? there was a known bug in stats that could have caused this in an early 1.6

From non non (nbhansen at midway.uchicago.edu) Saturday, 1 July 2006, 06:22 PM:

I upgraded to Moodle 1.6 stable. When was the problem fixed?

Is there any possibility for the stats package to work?
I'm using a site updated to Moodle 1.6.2 and when statistics is enabled to the minimum of 1 week and it is always giving the following message:

Statistics is currently in catchup mode. So far 0 day(s) have been processed and 7 are pending. Check back soon!

I encountered this issue also with the original 1.6 stable (2006050506) and my mdl_stats_daily table is huge (12G) on a site that is only have about a dozen test courses, and the cron process never moves things in to the other stats tables.

I want to upgrade to .1.6.3 – should I clean up the table first before the upgrade ? Can simply I drop the table and recreate it okay ? Or it is better to delete all the records with a query ? Will the upgrade fix this table ? If it doesn't, the upgrade will likely fail the table is so huge.

This is a test instance getting prepped as a pilot, so I have some room to experiment.

TIA - Randy

You should probably normally post a question like this in the forums but I was able to simply purge the contents of the table without any problems. That's probably better than deleting the table itself.

Randy, Nicole - while it is clearly happening in your installs, we have not been able to repro it over here. I have the suspicion that it may have to do with timezone settings. Does your moodle install have a specific timezone set?

N – Thanks for the advice and the very quick reply – I had to first repair the table, and then truncated it. Seems to be fine. I will run the cron tonight to see what happens to it. I now know what to do before upgrading.

Martin – Yes, I have a time zone set: GMT-8. The server is running Red Hat 8 and it is also set to that time zone.

Other config info: PHP 5.0.5; MySQL 5.0.15; Apache 2.0.55.

My apologies for not know the etiquette of tracker quite yet. I found this exact bug here when searching, so I posted here. I presume I should comment back here? as email replies didn't work. Please let me know which you prefer.

Randy

Hi Randy - what happens if you tell moodle to use the server's timezone instead of GMT-8? It should be equivalent, and I am interested in hearing whether stats changes behaviour in that case...

Martin,

Thanks for the suggestion. I cleaned out the stats_daily table, then set Moodle to use the server time zone, and let it sit over the weekend.

It had about 440K of stuff in it today, so I just ran the cron script, but it doesn't seem the cron job actually moved any thing from the stats_daily to stats_user_daily. And I still am getting the "Statistics is currently in catchup mode " message in Admin> Reports.

Randy

We are also always 2 days behind... Have been so for about 1,5 months. As a side effect the weekly stats are haven't been processed at all for that time, as apparently we run out of time while processing the daily stats. We are using a quite recent 1.6.3+. We get a moderate amount of traffic (3M pageviews per month), so this could just be a normal case of catch-up. I'll post more info if I get a chance to play around with the stats code.

I had an issue on this line in statslib.php - stats_cron_daily

require_once($CFG->dirroot.'/mod/'.$mod->name.'/lib.php');

turns out that I ended up having the excercise mod "installed" as a module, but must have deleted the files incorrectly, as the mod/excercise folder had been removed even though it was still listed as a module.!

maybe a check around the require_once should be made to see if the lib.php file exists first? - not sure if this is everyone elses issue!

(deleting the excercise mod on the admin/modules page fixed it for me...,..)

Dan

Is there a fix for this when Moodle is set to a specific time zone?

No we haven't been able to reproduce it and understand where the prob is yet. Need help with more diagnostics...

see my comment above - it might not be a timezone issue - but an issue with the require_once

Dan

MDL-7983 has a patch (or rather, a proposed change in the code) by Anthony Borrow for this. In my reading, it makes sense (or at least it's not obviously wrong).

If you are seeing this problem in your system, can you try his change and report back on this bug?

Martin,

I had to upgrade my system last month to 1.6.3 last month, so the problem has disappeared for me, so I can't reproduce or test this bug any more.

Randy

I disagree that this is a duplicate of MDL-7983. While similar in the impact (i.e. it causes statistics to get behind), the reason for the similar lag in gathering the statistics is very different. One has to do with extra files, the other has to do with a code fix. I think they are 2 separate but related issues.

In addition, I have suggested a patch to /course/report/stats/graph.php to make the dates consistent between the table and the graph.

58c58
< $graph->x_data[] = userdate($stat->timeend,get_string('strftimedate'),$CFG->timezone);
—
> $graph->x_data[] = userdate($stat->timeend-(60*60*24),get_string('strftimedate'),$CFG->timezone);

I believe that if we apply the above patch to /course/report/stats/graph.php and the following patch to /lib/statslib.php :

67c67
< $midnight = stats_getmidnight(time());
—
> $midnight = stats_get_next_dayend(time());

then we could close MDL-7983 as a separate bug report.

All the issues mentioned here (except the graphic) have been resolved under different bug numbers.

• Stats processing was dying if a module was missing - fixed as MDL-7385
• TZ mismatch between OS and Moodle would mess up the process - fixed as MDL-6795

Marking as resolved on 17_STABLE, 18_STABLE and HEAD, but really interested in feedback from affected users.

The suggested patch for the graph is – I think – a coverup for problems in time/date handling that should be fixed by the changes related to MDL-6795.

Thanks to Mike Churchward for the analysis.