Hi - hadn't forgotten you.... just been busy and I realised that probably what I have to do is run through all the various caching options, taking screenshots and explaining in detail in order for you to understand... slow work... This is in progress on the plugin homesite.
Very briefly I suspect the problem is that either you are not giving the cache a chance to run for the later reports and/or some of your data is not stored in wp user meta table.
PLugin does cache
1)on update or schedule (depending on settings). It kicks off a single cron job. Being cron it needs action on the website page refresh etc to run around/after it's scheduled time.
2) This single cron job then sets up a cron job for EACH report, a few minutes apart, THus you think "oh only the first one is updating"... It is just that they do not run concurrently... but one after another. Each cron needs some activity on the web site AFTER it's scheduled time for it to run. If you look at the report BEFORE the scheduled time, it will look un updated. A cron manager plugin would show the job scheduled though.
ALSO if low activity on site and you go inspect the report before doing another page refresh it may appear not to have updated.
The plugin has logic not to have caches clash with each other. So if you then run a manual re cache, the cron one may say 'ok' it's happening already and not run it's self. So it may not appear in the log then.
To make it more complicated/efficient, there is html caching too - for first page of user list only on front end only. THis uses wp transients so not running db queries all the time if people just view the user list. If in debug mode, it does flag when it is showing transient cached data. However that may add to confusion about whether it is updating.... wait a few minutes and then retry and the transient should time out and so new transient html made. That is why sometimes there is message about no existing transient - the recache process blows away the saved transient cached html.
Custom fields - where storec??
Another reason (which is why I ask about which fields and how fields are generated...) is that if
1) you set the cache on user update only.
2) you are using a plugin that does NOT use wp user meta table, then the wp user update action probably will not fire, so cacheing on user update will appear to work sometimes (on normal wp data) but NOT on extra non-wp data.
HENCE important to
1) understand the source data and know WHERE the cutsom fields are stored.
2) understand the cron process, have a good cron manager where you can see the jobs scheduled, and/or check the plugins cache log provided at each step - the cron log is actually very detailed and well even tell if it was a plain user update or a user meta update that trigged a re-cache (depending of course on settings and your data). It doesn't keep a LOT of history though, so one should check it at each step. Also NO ajax update, so to recheck, the cache log page must be refreshed.
Basically one must patiently step through all aspects:
1) make the update,
2) check the log, see single job scheduled,
3) cause cron to run after job's scheduled time or force job to run immediately, then
4) see jobs scheduled for each list on cron manager
5) wait for scheduled time or force immediate run (you can do this with my cron manager), and do at least one page fresh so cron will run.
6) check the cache log to see if cache started
7) view the report - transient html saved should have been blown away and new one created.
ONLY then change settings to try something else.
hopefully that's clear enough for now, check back at http://wpusersplugin.com/ later for screen shots etc.