I think Paul has put his finger on the critical issue. It's not just the simultaneous logins which are the real problem, but their timing. I don't think I can make the timing of DSLstats' sampling any more accurate than it is unless I somehow synchronise to the Windows scheduler, and I have no idea how to do that. In any event, it's probably not really practical to have two independent programs trying to sync together.
Maybe using Windows system time would work as that's what drives the Windows Task Schedules (and any other user defined schedules within HG612 Modem Stats).
So, as my programs run on the minute by default, perhaps DSLStats could always start sampling at say, 15 or 30 seconds past the minute at 1 minute intervals?
That should also allow for any additional time when HG612_current_stats occasionally harvests data on its few hourly schedule (the most user definable frequency is one hour).
The logging element of my programs CAN be delayed via user settings, to avoid clashes with anything else, but that depends on fixed timings for anything they wish to avoid.
The workaround of repeatedly trying the sh command until it gets a response may deal with the problem, but it would be much better if we can find a way of avoiding it before it happens. In general, DSLstats should handle situations where it can't log in for any reason - it should report the event in the event log and wait until the next sample is due. Perhaps what I should also do in this circumstance is delay the sampling by a few seconds so it doesn't get a succession of failed logins.
It does seem to do that:-
26 Aug 2013 12:08:03 Second stage login failed
I think that happened a couple of seconds into DSLStat's sampling period.
My programs, especially the current stats can be run on demand at any time a user chooses.
Retaining a workaround for those occasions is probably wise.
Although the total 'Sampling' period appears to be between 8 and 15 seconds, at least some of that time is in processing the data after logging out. For the purposes of what's being discussed here, only the telnet login - logout period matters. I should be able to raise some sort of flag during this period, which HG612-modem-stats could read and use to avoid a clash. The simplest flag would be a temporary file saved somewhere; we would need to agree on a suitable location for saving it, and also a protocol for dealing with the possibility that the temporary file doesn't get deleted at the end of sampling as a result of some unexpected event.
TBH, adding a slight delay to DSLStats if either of my programs are already running seems a simpler/tidier solution to me as users may have installed DSLStats in any folder of their choosing.
If, for whatever reason my programs still can't log into the modem, they now exit gracefully, freeing memory & closing open sockets etc.
Worst case scenario seems to be that 1 sample is missed, similar to how DSLStats handles a failed login.