Quote from: Epoch on June 04, 2012, 12:04:29 AM

Quote from: Luke-Jr on June 03, 2012, 11:56:48 PM

Quote from: Epoch on June 03, 2012, 11:54:02 PM

Quote from: Luke-Jr on June 03, 2012, 10:46:11 PM

Quote from: Epoch on June 03, 2012, 04:10:30 PM

It also behaves differently when Singles go offline; 2.3.6 just exited (which was good) but 2.4.1 and 2.4.2 just mark them as 'OFF' and do not exit (bad).

This was requested, and seemed logical. Would it be more acceptable to you, if it automatically reenabled the devices when they're plugged back in?

Luke, one benefit of exiting is that cgminer can then be executed in a 'forever loop' script such as this, which is useful for automated and unattended error recovery (in lieu of something like akbash):

:loop
cgminer
waitfor xx seconds
goto loop

Because cgminer is re-run automatically by the scrpt, it re-enables all the Singles. This was the behavior with 2.3.6, and worked well.

If a Single is unplugged, it won't be detected when the new cgminer starts... so you get the same thing, minus the ability to enable it later. Is there something else going on here?

I understand that if a Single is not connected when cgminer is run, the ability to enable it later is lost. But in the case where the Single 'crashes' or experiences a temporary power failure (i.e. a 'power glitch' which caused the Single to reboot), a script like the above works well to recover from that. I'll be the first to admit that it is very primitive and will not address all possible issues, but having cgminer exit when a Single goes offline seems to be, IMHO, a more attractive option for automation purposes.

If your Single is crashing, you should probably use the warranty while you can to get it replaced with one that works...

I suppose I can look into automatic recovery for people with power glitches anyway tho Tongue