When you say "problem" here, exactly what do you mean by that?
Let me explain how the ISDroid thing works and SWGAide's internal updating to see if that shed some light over the entire issue. And I do it from a startup of SWGAide.
When you launch SWGAide and if the option to auto-update the main galaxy (Sunrunner in your case) is enabled, then SWGAide first checks the content of that small status file against the content of the same file at SWGCraft. If they are not equal SWGAide downloads the updated resource file from SWGCraft. There is no fuss or complex stuff with this.
Both of these operations of course take some time, determined by the distance between user and SWGCraft, but also the quality of and the contention at the Internet connection. New Zealand versus GB is of course not negligible but should not be a major issue. Obtaining the smaller status file should be well within half a second at any distance, and the larger resource file is still just about 25 kB so even with an old 28.8 modem it would take less than 10 seconds.
SWGAide unpacking the zipped file plus parsing the XML file takes anything from milliseconds to perhaps a few seconds, determined by the computer and if some Java classes have already been loaded once, or not. Only if there is a parallel action happening it could take a fraction longer, if that action is blocking the resource manager; the manager must be blocked so that one thread in SWGAide does not change something that another thread reverts a split second later.
OK, this far SWGAide is started and you see the list at Current Resources. In fact, this list is populated already before the download is finished, that is if you are really quick and browse to it before the download is finished. If there was something new, some seconds later you'd see the news show up topmost and at the same time you'd see a message at the status bar and perhaps hear an alert.
From now on SWGAide checks that little status file versus SWGCraft every 3
minutes, and if there is anything new it is downloaded and SWGAide scans the stuff for guards/monitors/idling-harvesters and notifies the GUI that it should update itself. Actually, because SWGCraft compiles the export files for all
galaxies, also those without anything changed, the download takes place every 30 minutes whatsoever. A waste of Internet bandwidth and computer cycles, but considering the hardly noticeable size of these files ...
After a successful download, but only at success, SWGAide updates the local status file to read the same value as at SWGCraft. But rather than one file, as at SWGCraft, there are one file per galaxy which supports the case that users sometimes but not regularly browse other galaxies in SWGAide. Only the main galaxy is auto-updated, any other galaxy is updated on demand and their status files can be days or even years old.
Now, what about ISDroids? SWGAide handles the reports in this manner. The mail reports are loaded individually. For the four different lists the reports are compared against what SWGCraft knows about the galaxy. This way it is possible to conclude which resources are depleted (known at SWGCraft but no trace of them in the reports), which resource are known at SWGCraft but not reported for all planets (the reports tell more planets than SWGCraft knows about), which resources are known but without stats (you guess how), and which resources are new (unknown at SWGCraft but told in the reports).
To ensure best possible result, before SWGAide starts comparing reports versus what SWGCraft knows, it checks that little status file versus SWGCraft once again. If there is a new resource file available it downloads it and wants to use that rather than the previous which is about 30 minutes old.
Only if you launched SWGAide and instantly went into the ISDroid folder the previous download is from the recent time you run SWGAide. But then SWGAide is already downloading, perhaps not yet finished but the initial download is going on, and the ISDroid panel shows that "counting-down" text at the status bar. Once the download is finished the panel can go on and begin its routine and populate the lists.
If SWGAide had been running for a while two thing can happen when you go to the ISDroid panel:
1) The status file equals the status at SWGCraft, the ISDroid panel populates right away.
2) The status file comparing denotes that there is an updated file available, and it is initiated and you see that "counting-down" at the status bar, which in your case somehow ended in a time-out after 60 seconds.
This second case may happen only if the most recent time the status file was automatically checked there was no update available, but you happen to go to the ISDroid panel when one is available. Yeah, this can happen, during the 3 minutes window and
you go to the ISDroid panel just after xx:15 or xx:45 when SWGCraft has compiled the new files.
What I looked most careful at was if there is a chance that the download and the count-down routine in some way blocked each other. Or if the count-down routine perhaps used a value cached in memory rather than an updated value once the download was finished. I doubt it. I have seen the count-down several times myself, but only for something like 5 to 10 seconds.
What makes this whole issue peculiar and weird is that the status file from your screen shot clearly shows a date that was 77+ hours back in time and SWGAide had been running meanwhile but failed to update it or download anything, but yet the files for Sunrunner had timestamps that displayed a fresh date/time (from the folder screen shot). And none of the files should even be touched by SWGAide unless their content had changed. The status file is only modified if a successful download is finished, otherwise SWGAide just bails out but logs an error. And you say that this was present at two different computers at the same time. Hence your conclusion makes sense, neither SWGAide nor the computers are the culprit but something outside these. If that is your router, the Internet provider, or what ... I cannot tell. If the screen shot of the status file had displayed a time difference of hours or less, then I'd blame you
Yes, I know Internet providers that have been testing file caching to cut down inter-continental transmission costs. That was about caching files that has equal URL and file size, however, it turned out that the costs for caching was way worse than let the transmission through. Only satellite, rare radio lines, or hot-spot routing under certain circumstances showed a net gain. I doubt New Zealand ISPs play around with this stuff these days. And if they do they have a flaw in the caching, it is not enough to compare URL and size, also a complex enough hash code (finger print) of the content must be identical to make sure everything works
Does your router/modem do caching? I have no idea, you could check its specifications. Over at my location there are no modem/routers for home/small-offices that does it.
I am sorry that I cannot get closer to an explanation.
What I can do is to remove the check for the ultimate freshness, which would remove the count-down, and only warn if the most recent download is more than 40 minutes or so. I mean, I cannot see a risk in using a download that is about 30 minutes old rather than one that is less than 5 minutes. Can you? But at least we get rid of this annoyance and a possible error pothole, what do you say? Or anybody else?