CGWatcher 1.4.0, the GUI/monitor for CGMiner and BFGMiner to prevent downtime

[milone]

Are you referring to moving pools in the Config File Editor? This is probably the easiest way to change pool priorities, open the config file in Config File Editor and locate Pools in the list (it should be the first selected setting when you open Config File Editor. Next to Pools, click the word (collection) and a [...] button will appear. Click this button to open a window listing all of the pools in the config file, which you can then use the arrow buttons to move up or down in priority. When you are finished, click OK to close the Pools window then click Save to save the config file. This will save the pools in the order of priority that they were listed in the Pools window, and also set the "pool-priority" setting (specific to BFGMiner).

If this is what you're referring to and it isn't working correctly, let me know with as much information as possible about what you're trying to do vs. what it is doing.

Also, the profitability information from Coinchoose is based on BTC profitability. I've made several changes to profitability info in CGRemote, including gathering data from multiple sites, and those changes will also be added to CGWatcher eventually. While it's in beta, CGRemote is sort of a testing platform for new features, most of which will probably make it into CGWatcher at some point.

[Loft]

....locate Pools in the list (it should be the first selected setting when you open Config File Editor. Next to Pools, click the word (collection) and a [...] button will appear. Click this button to open a window listing all of the pools in the config file, which you can then use the arrow buttons to move up or down in priority. When you are finished, click OK to close the Pools window then click Save to save the config file. This will save the pools in the order of priority that they were listed in the Pools window, and also set the "pool-priority" setting (specific to BFGMiner).
....

Yes, the way I have tried. In version 1.2.4.1 everything worked, then I immediately switched to version 1.3
I can't confirm it screenshots, as I am far from the farm, but it does not work currently.

[milone]

Once the config file is saved after re-ordering the pools, which is incorrect?: the order in which the pools are listed in the config file, the "pool-priority" value, or both? It should be saving them with the correct "pool-priority" value (for bfgminer) as well as listing them in the correct order (for cgminer).

I don't think I've changed anything related to this since it was first implemented, or at least not in any recent versions. That's not to say there isn't a bug somewhere... I just need more info to find it because I've just tested on a config file containing 4 pools and it works as expected after switching them around several times inside and outside of config file editor and saving/re-opening and restarting the miner.

Perhaps you could email me your config file before and after re-ordering the pools, and list the changes you made to the order?

[shacky]

Hi,

A suggestion:

Maybe you can include your app top work with this APP API: MobileMinerApp

Thanks!

[fredeq]

Hello!

First of all thank you for this great application, saves a lot of maintenance time.

Secondly would it be possible to add event to scheduler called "when coin X becomes the most profitable profile". I can only hope that this is very easy to implement and wont take you much time. The reason behind this is when you solo mine any "fast" coin that is supported by multipool, all your blocks can become orphans when multi switches to it.
Having that kind of event I would just switch to multipool with the coin I usually solo mine.

Again thanks for the watcher!

[milone]

shacky: There are already plans to provide phone/tablet support with CGRemote, which allows remote control of miners with or without CGWatcher running on them. Anything that can be done in CGRemote you will also be able to do through the (coming soon) CGRemote website and/or phones/tablets. (http://minerremote.com)

fredeq: I've been spending most of my time on CGRemote, but I have started adding support for event-driven actions in CGWatcher. I hadn't yet thought them all out (most were miner-related), but I'll make sure your suggestion is added.

[lajz99]

What about an option to restart based on the number of devices?

Sometimes I'll have 1 or 2 devices that wont start properly and I'm looking for a way to ensure this doesn't happen when switching pools.

[fredeq]

shacky: There are already plans to provide phone/tablet support with CGRemote, which allows remote control of miners with or without CGWatcher running on them. Anything that can be done in CGRemote you will also be able to do through the (coming soon) CGRemote website and/or phones/tablets. (http://minerremote.com)

fredeq: I've been spending most of my time on CGRemote, but I have started adding support for event-driven actions in CGWatcher. I hadn't yet thought them all out (most were miner-related), but I'll make sure your suggestion is added.

Thank you very much, keep up the great work.

[milone]

What about an option to restart based on the number of devices?

Sometimes I'll have 1 or 2 devices that wont start properly and I'm looking for a way to ensure this doesn't happen when switching pools.

So a setting in the Monitor tab where you could set the minimum number of devices that must be mining after the miner's startup grace period (default 3 minutes I think) and if not, restart the miner again? The grace period can be changed in the INI file, but I think it's best not to reduce it too much or else the miner could spend more time restarting than mining if you have a lot of problematic devices.

If I'm understanding you correctly, this should be fairly trivial to add so I'll try to get it in the next update, which should be sometime this weekend.

[lajz99]

What about an option to restart based on the number of devices?

Sometimes I'll have 1 or 2 devices that wont start properly and I'm looking for a way to ensure this doesn't happen when switching pools.

So a setting in the Monitor tab where you could set the minimum number of devices that must be mining after the miner's startup grace period (default 3 minutes I think) and if not, restart the miner again? The grace period can be changed in the INI file, but I think it's best not to reduce it too much or else the miner could spend more time restarting than mining if you have a lot of problematic devices.

If I'm understanding you correctly, this should be fairly trivial to add so I'll try to get it in the next update, which should be sometime this weekend.

You got it!  Will send over a donation once it's released!

Also, one thing I'd like to see is the logging/data of times/amount of time spend mining in each pool without having to dig through logs.  Thanks, LOVING the program.

[milone]

A monitor option has been added to set a minimum number of devices that must be mining at the end of the start grace period, and if not the miner is restarted again. This number is for total devices, so GPUs + FPGAs + ASICs.

Also, the elapsed time shown for each pool is corrected to show only the time that pool was in use (+/- monitor interval seconds). The miner returns an "elapsed" value for each pool in the stats response, but it's the same for every pool... even pools added after the miner was started. So CGWatcher keeps track on this of its own now. I had noticed this before and it was on the to-do list, I just hadn't gotten around to it yet.

If the miner is running prior to CGWatcher, upon starting CGWatcher assigns all of the time the miner was running up to that point to the current pool since it doesn't know which pool got what time while it was closed.

You can view the pool elapsed time in the Pools tab (per pool) or the Report tab (all pools) in 1.3.1, which will be available tomorrow. I also added the percentage of mining time the pool has received.

[lajz99]

NICE!  Just sent over a small donation for ya!

[milone]

NICE!  Just sent over a small donation for ya!

Thanks, I appreciate it.

I should mention that an API-enabling bug has been fixed, which caused CGWatcher to change the api-allow option to only W:127.0.0.1 if it did not find that IP in the W: group of the profile's arguments... (even if it was in the api-allow in the config file).

A temporary workaround is to set the api-allow option in the profile's arguments and make sure 127.0.0.1 is in the W: group. CGWatcher 1.3.1 fixes this issue regardless of where or what you set the api-allow option to and better handles prefixes that include the localhost IP to reduce the need for it to modify the api-allow option only if necessary.

[milone]

New in version 1.3.1

• Add bitburner code/name to default mining devices.
• Improved automatic API enabling to fix issues with api-allow option being modified incorrectly and locking out other API monitoring applications.
• Thread sync locking on remote socket collection handling.
• Fix default profiles and variables file paths being saved to CGWatcher.exe.ini which caused profiles and variables to not save correctly if the CGWatcher folder was moved or copied to another location because the paths would still point to the original location. These are now left blank unless you change them manually to non-default paths.
• CGRemote file explorer commands expanded to allow full directory navigation, file copy, file info, and existing commands improved.
• CGRemote commands to add, modify, and delete profiles improved.
• Ads may be displayed occasionally (30 seconds per hour, can be closed by clicking X) on CGWatcher's main window with the exception of donation miners. If you want to advertise your latest pool/asic/alt-coin or ask that one bitcoin mining girl out, do it with a 468x60 banner in CGWatcher
• Update and version data backup sites added to (hopefully) get around the main site being blocked in certain countries.
• Pool elapsed time now recorded per pool, available in the Pools tab and Report tab. Also includes a percentage to see which pools were used and how much.
• Remote options window created to provide additional options for CGRemote in the future, and allow for setting a default miner path (which defaults to your most-used miner executable) to use with global profiles.
• Several other improvements (I lost track at some point).

[play]

Ads may be displayed occasionally (30 seconds per hour, can be closed by clicking X) on CGWatcher's main window with the exception of donation miners. If you want to advertise your latest pool/asic/alt-coin or ask that one bitcoin mining girl out, do it with a 468x60 banner in CGWatcher

What's the minimum donation time required for this not to happen?

[milone]

10 minutes (regardless of day/week/month), or if it is donation mining at the moment the ad is to display it is skipped. Right now it's set to show one per hour, and the default duration is 30 seconds though this can be set per ad.

My original intent was to be able to show when CGRemote was finished, and that may be the only thing that's ever promoted... but I made it so additional ads can be created. Ultimately the ads won't be shown for CGRemote users either.

[Zanatos666]

I keep having an pop up whenever CGWatcher restarts my miner.  It tells me that my miner that is running is not currently using a profile.  Would I like to create one?  Thing is, I have one created, and it is using it.

[milone]

Did you move or copy the CGWatcher folder? recently Check the ProfilesDataPath setting in CGWatcher.exe.ini, this points to your profiles.dat file which stores profiles. (Same with VariablesDataPath, which points to variables.ini where variables are stored.)

In the last version, I had mistakenly had it save the path even if it was the default location, so if you moved or copied the folder somewhere else it would continue to point to the old path unless you manually updated it. This is corrected in 1.3.1, but you may need to correct it initially. Alternatively, you can delete the CGWatcher.exe.ini file to have it re-create a new one upon starting, but you'll have to re-set some settings.

[Zanatos666]

Did you move or copy the CGWatcher folder? recently Check the ProfilesDataPath setting in CGWatcher.exe.ini, this points to your profiles.dat file which stores profiles. (Same with VariablesDataPath, which points to variables.ini where variables are stored.)

In the last version, I had mistakenly had it save the path even if it was the default location, so if you moved or copied the folder somewhere else it would continue to point to the old path unless you manually updated it. This is corrected in 1.3.1, but you may need to correct it initially. Alternatively, you can delete the CGWatcher.exe.ini file to have it re-create a new one upon starting, but you'll have to re-set some settings.

I am still running 1.2.8.1.

[milone]

I worded that poorly, setting the profiles.dat path in the INI file was added back in 1.2.8. I forgot to include it in the changelog, but it was the same update in which the variables.ini path was also added.

I'd suggest checking that the ProfilesDataPath and VariablesDataPath in cgwatcher.exe.ini are correct. I'd also recommend upgrading to 1.3.1.

Edit: Also, if you have your miner or CGWatcher folders on the desktop, I recommend moving them to another folder (e.g. C:\Mining, C:\Bitcoin, etc.) Somewhere where there is less likely to be permission issues. There are some quirky behaviors with how Windows treats the Desktop folder, especially when launching something in the Desktop folder by using its shortcut on the desktop, as an example: https://bitcointalk.org/index.php?topic=269249.0 (which goes on to discuss other problems, but this was the OP's issue).