Tuesday, March 26, 2013

CGWatcher - A GUI/monitor for CGMiner and BFGMiner

Current version: 1.3.6 (ReadMe)
Current version release: March 22, 2014

*includes only version 1.3.1 or newer

The CGWatcher page has moved!
It is now located at http://www.coinmyne.com/cgwatcher
Please use that link or the 'Check for Update' button on the About tab when checking for new versions. This page may not be updated for future versions.

Description
CGWatcher is a GUI for bitcoin miners CGMiner and BFGMiner (32-bit and 64-bit). Along with giving a graphical interface to the miner, it has several options to monitor the miner and correct problems when they are detected, minimizing downtime. It is not affiliated with CGMiner or BFGMiner, it just helps to ensure they stay running while providing something a little easier to look at.
It works via the miner's API, which was created for this purpose - to allow other software to communicate with the miner. While there are several web applications to allow remote monitoring of these miners, that is not the purpose of CGWatcher. It is designed to run on the same computer as the miner, and will watch for the conditions you set to determine if the miner is working properly. If it is not, CGWatcher takes the appropriate actions to correct the problem. The idea is to create a program that does the monitoring for you, so you don't have to use those web applications to constantly check on your miners.
CGWatcher is a small and portable .NET application. It will run as a 64-bit application in 64-bit Windows, and a 32-bit application in 32-bit Windows. It can be run inside sandbox environments like Sandboxie if you don't trust it, however settings and profiles may not be saved. The application includes a few libraries (see credits below) and creates its own config file (CGWatcher.exe.ini), log (cgwatcher.log), log for mining events (miner.log) and data files for profiles and named config files (profiles.dat, config.dat).

*Screenshots are as of version 1.2.0.0 and do not include the About tab.

Features

Monitor mining - Set an interval (in seconds) for checking mining status. This is how often CGWatcher will update mining data. This must be enabled to use the checking features, including:

■ Restarting the miner or computer when a sick or dead GPU is detected.
■ Restart the miner if the total hashrate falls below a specified number for a specified number of seconds.
■ Restart the miner if it had full API access but now only has read-only (in the same miner process), or if the API access was enabled but was lost completely.
■ Restart the miner if accepted or total shares do not increase for X number of minutes.
■ Restart the miner after X hours of continuous mining to cover any problems that other checks may have missed. That ensures that if a problem arises, at worst the downtime will be limited to the number of hours you set here.
■ Ensure miner stays running option makes sure that mining never stops unless you stop it using CGWatcher (by clicking the Pause Mining or Stop buttons.)

Statistics - These miners provide a lot of information. CGWatcher attempts to present it in an easier-to-read interface, using tabs to separate information. Basic mining stats can be found on the Status tab. Device-specific stats can be found on the Devices tab, and pool-specific on the Pools tab. More detailed information on the miner and CGWatcher can be found in the Report tab.

Control - You can easily change miner settings while it is running. Change GPU core, memory, voltage, or intensity. Re-prioritize and enable/disable pools. A large Pause/Start Mining button allows you to easily stop and resume mining. Another button opens the miner's configuration file in the Config File Editor. I've tried to add buttons to open files or directories wherever you may want to so you can do it all from inside the program.

Overheat Protection - CGMiner provides overheat protection for AMD cards. Using the temp-target, temp-overheat, and temp-cutoff settings, it can adjust fan and clock speeds to maintain a target temperature and disable devices that get too hot (if auto-fan and auto-gpu are enabled.) CGWatcher now also provides similar protection for Nvidia cards by adjusting intensity to maintain the target temperature and disabling GPUs that get too hot. It will enable and/or slowly raise intensity back to their original values once temperatures cool down back into the target range. I'm not sure if anyone mines with Intel HD integrated graphics since modern CPUs have better OpenCL support. Currently CGWatcher does not support overheat protection for Intel devices, but I will be doing some tests to see whether the CPU temperatures it is now capable of getting are enough to provide similar support for these devices. You can see if the miner or CGWatcher is providing overheat protection for a GPU in the GPU tab next to the temperature.

For GPUs that miner is providing overheat protection for (AMD), CGWatcher takes a hands-off approach except for when the miner disables them for exceeding temp-cutoff. Although the miner is supposed to re-enable them once they return to target temperatures, this does not seem to happen so CGWatcher will restart the GPU once it has returned to temp-target temperature.

Scheduling - Scheduled actions give you complete control over what your miner does and when. Actions include start mining, stop mining, restart mining, restart computer, change intensity, switch profile, etc. Along with creating actions to run at specified times, you can create actions that run at set intervals.

You can create profiles for each coin you mine, then set CGWatcher to switch to whatever is most profitable at the times or intervals you specify.

You can also set CGWatcher to increase GPU intensities when the computer is idle, and it will return them to their original values once you start using the computer again. You set the intensity, you set how long the computer must be idle before intensities are changed.

Profiles

CGWatcher allows you to create mining profiles using different miners, config files, and/or arguments. When you first use it, it will create a default profile and try to locate a miner if one is running or one is located in the same directory or subdirectories of CGWatcher. If it cannot find a miner, you will have to manually specify where it is located and (optionally) a config file and/or arguments you want to use. You can do this by clicking the 'Manage Profiles...' button in the Settings tab. You can create as many profiles as you'd like for the different crypto-currencies you mine. You can also rename the default profile if you'd like, it just names the first one Default because I had to name it something.

When you switch to a new profile ("activate" a profile), CGWatcher will use that profile's settings any time it starts or restarts the miner. However, if you switch profiles while a miner is running, you will obviously need to restart the miner in order for the new profile to be used. You can see which profile a currently running miner is using on the Status tab. Ideally it would always be the same as the active profile you've set... but if you changed profiles while mining and chose not to restart the miner when prompted, keep in mind that the miner will still be running on the previous profile until it is restarted (or stopped and started).

Coin Profitability

Coin profitability is updated continuously at regular intervals to show which coins are most profitable at the moment. This information is also used when you create scheduled actions to automatically switch to your most profitable profile.

Config File Editor

The Config File Editor attempts to make editing your miner's configuration easier. To start, it displays the config file in a grid allowing you to see all available settings and a description of each. Settings that can only be enabled or disabled will have a true or false option. Settings that allow numbers only (not including lists of numbers) will only allow numbers. The 'Validate' button attempts to check your settings for errors that may prevent the miner from starting or working correctly. Some things to know about the Config File Editor:

Settings that are set to default values are not written to the config file upon saving. They are also not converted to arguments, because they are set to default values and don't need to be explicitly set.

To add, edit, or remove pools, locate Pools in the config file grid. (There may be a Pools category heading as well in Category view mode), but you want the Pools that says '(Collection)' in the cell next to it. Click on the word '(Collection)' and a small [...] button will appear in the cell. Click on this [...] button to open the pool window. If you've ever used a property grid in Microsoft or similar software, you will recognize this type of grid and the accompanying collection editor.

When editing pools, you can create names for them as well so they are more easily identifiable when editing them later on. Pool names are saved inside the config file, but will not cause a problem with the miner. To change pool priorities, use the up and down arrows in the pools window to move pools up and down the list. The top of the list is the first priority, the bottom of the list is last priority.

'Name #' textbox - You can name your config files so when you're using them in profiles they will be easier to access. Enter a name for the config file in the Name textbox. Then when managing your profiles, you can select a Named config file from the Config File textbox drop-down instead of needing to browse your computer for it. After clicking out of the Config File textbox, it will be converted to the config file path automatically.

Ensure API is enabled upon saving' : If enabled, the API access needed by CGWatcher will always be enabled when saving the config file, regardless if these settings were enabled in the grid. It will not affect other groups/IP address in the api-allow setting, it only makes sure api-listen is enabled and that 127.0.0.1 is included in the W: group of api-allow.

The Config File Editor Menu

■ File -> New - Create a new config file. ■ File -> Open - Open an existing config file. ■ File -> Save (As) - Save the current config file. ■ File -> Close - Close the Config File Editor. ■ Tools -> Import Settings -> From Config File... - select an existing config file to import settings from. The current settings will be overwritten, but will not be permanent until you save the config file. ■ Tools -> Import Settings -> From Named Config File -> <select> - if you've set names for config files using the Name textbox in Config File Editor, these config files can be loaded quickly by just this name, both in Config File Editor and in the Mining Profiles window. This is the same as the previous menu item, but quicker and easier. ■ Tools -> Import Settings -> From Arguments - enter or paste miner arguments to have them converted to a config file. If you have a config file open, you will be asked if you want to overwrite only the settings listed in the arguments, or if you want to create a new config file using only the settings listed in the arguments. ■ Tools -> Export Settings -> To Arguments - converts the current config file to miner arguments. ■ Tools -> Open this Config File in Notepad - opens config file in Notepad. There is also a button next to the config file's Path to open in Notepad. ■ Tools -> Validate this Config File - checks the config file for errors in the settings' formats or values.

Requirements
CGWatcher runs on Windows and requires the .NET framework 4.0. It should work with the latest versions of CGMiner and BFGMiner, although changes to those miners may require changes to CGWatcher.

In order for CGWatcher to work correctly, it needs full access to the miner's API. While previous versions required that you ensure this is enabled manually, version 1.1.5.0 now does this automatically when the miner is started using CGWatcher. Regardless of whether the api-listen and api-allow options are set correctly, CGWatcher will make sure they are enabled before starting the miner without altering your config file or arguments.

While you no longer need to manually ensure these options are set, the following is how you would set these options via arguments or a config file:

CGRemote
I am working on a program called CGRemote which will create a dashboard to monitor and control your miners remotely. It will communicate with CGWatcher or the miner directly (for non-Windows miners). It is currently in beta, more information available at:

Support
You can send bugs or feature requests to the email address in the ReadMe or post in a comment here. You can check #cgwatcher on Freenode for live support. Donations are greatly appreciated as they motivate me and allow me to spend more time on this project. After all, the program's goal is to help you make more money. Feature requests from those who donate get priority.

Donation addresses:
BTC: 19msnBddmcaHnbTTQgFgzPDuy6PqfBgFJhLTC: LM6Un6hZvPzLBggJWiAVG6E6w2GfaHukXYNMC: NJjD4rP5xy2mgSK8gXXsZwFkdknbvtvy3q
More donation options are available in the About tab.

66 comments:

Looks good. Is there any way to make it not bring up cgminer in a dos window where it runs in the background? I think that would be a cool feature. Also a scheduler could be a neat feature. Just tossing some ideas out there. Program runs good. Good work. Wish I could do something like that.

Yep, thanks for the suggestion. I've been working on an update with a basic scheduling feature (for now) and minor bug fixes, so I added an option for running cgminer normal, hidden, or minimized as well. I have to do some more testing then the update should be up tomorrow on this same post.

I don't know why, but when I set it to restart if the hash rate falls below 10MH/s, it restarts constantly. If I turn off that setting, CGMiner appears to mine at full speed non-stop. Maybe add a configurable time threshold for that setting? For example, it could be set to restart if the total current hash rate falls below 10 MH/s for more than 5 seconds.

I'm trying to use this to monitor a remote headless miner. I've put in the ip:port in the settings tab and enabled monitoring. The log tab confirms the remote cgminer was found and that monitoring has started. Ican use manual commands on the tests tab successfully, but it says "cgminer is not running" at the bottom and no other info is shown. Is this something that could be fixed?

There are some fixes I need to make to support monitoring networked miners. At the time I wrote it, it wasn't a priority so I didn't spend too much time on it. I understand what the problem is with the situation you've described so it shouldn't be too difficult to fix. I plan on uploading an update in the next day or two.

There are some things I want to clean up before I upload the source. I was in a hurry to just get something working and even today (now that I can fully test it on my computer since my AMD cards arrived) I am finding issues that need fixed. One is that the GPU restart command often fails to restart GPUs... so I've changed it to restart CGMiner completely. This can sometimes cause CGMiner to close, which I have to watch for and re-open if necessary. Things like this that I can only find through testing. Once I feel confident that everything is working correctly (I need to fix network monitoring, for example) I'd be happy to upload the source even though it might be ugly and unfinished. I'll also do more commenting. Doing it this way may take a little longer but will make it easier to follow once you get it.

Also, I thought about adding options for temp monitoring but since CGMiner has this ability already I didn't consider it a priority. But I understand the desire to customize it to your setup. I'd say give me a week or so and I'll be able to give you something a little more solid to work with.

There was a problem with restarting sick or dead GPUs using the 'gpurestart' command. CGMiner usually returns a message that it tried and failed. I've already switched this to just restart CGMiner altogether for sick or dead GPUs, as that is a more reliable way to fix the problem. It will be in the next update, hopefully uploaded in the next couple days..

I have to work out some issues on running remotely. There may have to be a small helper program running on the remote computer... otherwise there will be no way to launch CGMiner remotely (which is needed in some cases.) As I mentioned, networked monitoring was a low priority but I've setup a miner on my network for testing and will work these problems out.

Thanks. I considered something like this but CGMiner and BFGMiner already have abilities you may find more useful. You can set three temperatures in the miner's config file:

temp-target - Tells the miner the temperature you want to run at. The miner will adjust fan speed to try to maintain this temperature.

temp-overheat - If a GPU hits this temperature, the miner will reduce clock speed to try to cool it back down to your target temperature.

temp-cutoff - If a GPU hits this temperature, the miner will stop mining with it.

You can set these options for multiple GPUs by separating them with commas. For example, "temp-target" : "75,75" tells the miner to try to keep both GPUs at 75.

I will probably add more options like this at some point as a second line of defense, but right now I'm working on controlling networked miners so this won't happen soon but I put it on the list. I also plan on creating a form for modifying the miner config file easier, sort of a "config file wizard".

Thanks, it's good to hear others find it useful. The hashrate for scrypt mining is already fixed and will be in the next update. It will check if you're mining sha256 or scrypt and adjust automatically. The network support is coming along nicely and I'll upload the new version once it is finished (or at least ready for beta testing.)

Which cards are not showing hashrates? I get the hashrates from CGMiner and while I've seen CGMiner unable to detect some values for Nvidia cards, it should report a hashrate no matter which card you're using. Can you click on the Tests tab, select devs from the drop-down list, and click Submit. Then copy and paste the result message from the miner (large textbox) into a comment here or e-mail (my email address is in the ReadMe.txt.)

Like I said, I just get that data from CGMiner so I don't know that there is something I can do to fix it, but I'll give it a look.

have that same issue - on OS with comma(,) as decimal separator hashrates are not displayed by CGMiner, changing decimal separator to period (.) make CGMiner display data correctly. It would be grate to work with (,) :)

Specifically, "Also, make sure you don't use comma as your decimal point as some cultures do. Should you do that, JaSON will massacre the poor, unsuspecting cgminer and no mining will be done that day."

Does the hashrate display correctly in the CGMiner window? If so, the comma may be throwing off the JSON data coming out of it or it may be a CGWatcher bug. If the hashrate doesn't display correctly in CGMiner, it is a CGMiner bug and I'm not sure if anything I do in CGWatcher will fix it,... as it only displays the data CGMiner gives it. I will look into it, thanks for pointing it out and any more information you can provide.

thats my mistake :) I was thinking CGWatcher, but I wrote CGminer because I was looking at your comment few lines above...

To be clear - cgminer displays hashrate correctly, from 'summary' commands CGWatcher reads hashrate with like MHS av=537.14 but if I have in OS selected comma as decimal point CGWatcher do not displays hashrate in Status tab. Changing in OS decimal point as . makes CHwatcher displays hashrate correctly. If you like I can provide any logs/debug you think may help solve this issue.

I also just set Windows to use comma (,) as decimal separator and period (.) as group separator. However, CGMiner still sends me hashrates with periods (ex. 495.30 instead of 495,30). As soon as I convert the hashrate text that CGMiner sent me into a number (I store hashrates as single data types for anyone wondering), Windows assumes the period is a group separator and turns the number into 49530.0, which is obviously not what we want. Since that number is larger than 1000, it gets converted to Gh/s (divided by 1000), making it 49.530. However, since a decimal separator is a comma (,) it shows up as 49,530 Gh/s.

Although CGMiner should be passing values using the correct culture format set in Windows, I will work on handling this in CGWatcher and correcting it whether CGMiner gets fixed or not. I'll try to fix it by the next update, which should be up sometime this coming week depending on how much time I get to work on it.

Thanks again for the help. I might have gotten too technical with the answer for the average user, but I know there are some other dev guys using it and might find it interesting.

In my case I do not user period (.) as group seprator, but space ( ) and CGWatcher displays 0 Khas/s in this configuration - Only change I've done was setting (.) as decimal separator and CGWatchers started dispalying hashes correctly. cgminer in both cases was displaying speed as 467.33Mhash in cmd line and from Tests tab in CGWatcher.

all the version i have used detect khps when litecoin mining as a matter of that is all i have used this program for its still buggy sometimes it freezes or stops responding but I was using version 1-1.1.1

Justin - Great software I have already donated twice to help you out via litecoin. Definitely am liking the interface. Can you work on getting email notifications like akbash uses at some point? Although I would prefer to be able to set the SMTP server and the to address.

Also when are you going to be releasing the source code so others can help add features and bug fixes via github? If you plan to leave it closed source thats cool to just was curious.

Thanks, I will look into email notifications. I've downloaded akbash but haven't had a chance to look at it yet. I released a CGWatcher update today, and will be working more on a program called CGRemote that will allow you to remotely monitor CGWatcher miners. I already have quite a bit done but no ETA yet.

As I've been fixing and adding things, I've been making some big improvements to the source code as I have time. Also commenting to explain why I did things, etc. When I get something presentable I will release it.

Good work on this software, very useful. I think an option to restart cgminer if it crashes would be a useful addition. Sometimes I return to my rig and cgminer has crashed and cgwatcher doesn't currently do anything about it.

I believe this is caused by CGWatcher sending the restart command, which I've learned can cause CGMiner to close unexpectedly instead of restarting. This is handled in the update I released today so I recommend updating and see if the problem still exists. If it does, I will look more into adding this.

I have found that the program doesn't fix what I thought it would. CGMiner seems to hang - the GPU is still doing 99%, but the interface is not responsive. Nothing updates on the interface or my mining pool, but your program still has a hashrate displayed from last time it talked to CGMiner.

Don't you try to restart CGMiner if you don't get a response over the API? I noticed that hitting the restart button doesn't work, as the API is not working, so you would have to find the process and kill it the same way task manager does (unless you can find the window handle and send it a close event, as the red X on the window still works).

The problem you've described is not something I've experienced, so I depend on users to report them and I will work on getting them fixed (until it is on GitHub, then hopefully other users can provide fixes as well.) I had created an option to restart the miner if API access goes from full to read-only, because that is a problem I was having on one of my miners. I hadn't seen it lose API access completely, so I didn't watch for that. Currently it doesn't restart if API data is not returned because I wanted it to be unintrusive, and I assumed if API was disabled the user didn't want CGWatcher messing with it. I will modify it to restart if no API data is returned for X checks in a process that did have API access at one point. Restarting if the API is dead is not a problem I already have process info and kill the process when the API becomes read-only in order to restart.

The option 'Restart miner if total shares stop increasing for X minutes' was an attempt at catching problems like the one you described, where something happens that causes these numbers (accepted, rejected, stale, discarded) to not change. Admittedly, I am still learning exactly how CGMiner works (I only started mining 5 weeks ago) so this option may need to be modified if it does not work the way I thought it would. I assumed that CGMiner needed a response from the pool/bitcoind to determine which of these values to increase, so if it hangs or the pool isn't responding, these numbers would not change in CGWatcher, triggering a restart. If you find that one or more does keep increasing, please let me know. For example, maybe the discarded count increases even though the miner stops working properly.

In regards to your previous comment, I'm not sure if you mean how many times the option was checked, or how many times the check failed and the miner was restarted. All enabled checks are checked each time data is refreshed, so it depends on your monitor interval. A 10 second interval means all enabled checks are performed every 10 seconds. I will add a counter to the Report tab if that will be helpful. As for how many times a check failed and the miner was restarted, this is displayed in the log (which I am continually improving its readability.) The Log tab only shows the log from when CGWatcher was last opened, but you can open the log in Notepad to see the entire log.

Also keep in mind that the miner gets a grace period after starting, where it will not be restarted even if a check fails. The default is 180 seconds but can be changed by modifying the RestartGracePeriod value in CGWatcher.exe.ini. The option 'Restart if current total hashrate falls below X' won't be triggered unless it happens 3 checks in a row. This number can also be changed by modifying the HashRateCounter value in CGWatcher.exe.ini.

When it goes dead, it still shows "full control", so the read only check never triggers.

The 'Restart miner if total shares stop increasing for X minutes' option doesn't trigger it in my case. I'm not sure if it is noticing and trying to kill it, or not noticing at all, but nothing shows up in the log.

Are you still performing the checks if the API call fails?

In my previous comment, I was thinking of a count of how many times each check has restarted the miner.

I've updated the download files (same download link) that should resolve this. Now if it had API access (read-only or full) to a miner process and loses it, it should attempt to kill the process and re-launch the miner. I've tested this by monitoring a miner with API access, then changing the port to 4029 so CGWatcher essentially loses API access. It kills the process and re-opens it. This has been grouped with the other option that restarted if API access became read-only (I changed the text to reflect this.) Though this will still not happen if it is inside the miner's startup grace period (which is now displayed in the Report tab.) A restart counter is also now displayed in the Report tab.

When you say it is not triggering the 'Restart miner if total shares stop increasing...' option, do any of the values increase on the Status tab? I'm curious to know if CGMiner increases any of these values even though it has stopped submitting work or working correctly. I am still performing this check if API calls fail.

I was hoping to do more testing before uploading, but I found a scheduler bug and coincidentally so did someone else right as I was heading to bed. I did quite a bit of testing and I feel pretty confident I won't, but if I've introduced new bugs I will be available tomorrow to fix them. See if the updated files fix this issue.

I will leave the old version on for a bit to confirm, but I'm pretty sure the shares in CGWatcher and on the pool stopped increasing, even though the GPU is at 99% and is at normal running temperature according to GPU Caps Viewer.

I just checked, and the front end of CGMiner is dead. There are definitely no shares being reported to the pool, and the status tab in CGWatcher does not increase. Weirdly though, the pool is reporting changes in kilohash rate (both up and down, so it's not a falling average). I am using CGMiner 3.1.0 to mine litecoin (3.0.0 also had this problem on my rig)

I noticed that CGWatcher reports one more accepted share than CGMiner, if that helps.

I will try the new version now, and will keep a copy of the previous version in case you need something else testing.

You're right, I just found a bug that was likely causing the 'Restart miner if total shares stop increasing..." option to not work. It has been fixed and the files updated (a minute ago, MD5 is 7CF4C5A8472E540030795DF07A7BDAFB). It isn't concerned with hashrate, as CGMiner will continue to hash (or show a changing hashrate) even when it is not working correctly. All it watches for is accepted, rejected, stale, and discarded changes. If CGMiner is increasing one of these values even when it is not working (stale or discarded for example) then I will need to find which one and not include it in this check.

I've also made additional changes this morning that should ensure the miner is restarted if API access is lost.

Thanks again for the feedback. I am working on a better way to handle these small fixes that lets those who are having problems see a newer version is available without constantly notifying everyone else who isn't having problems that an update is available.

It's still doing it. This time CGWatcher has 2 more shares than CGMiner. Nothing shows up in the log.

I have the following checks set http://i.imgur.com/mcsXQNP.jpg as you can see, it is everything except the restart every x hours.

If I set the "every x hours" check, will it use the API to restart, or kill the process? I will use this as a last resort, but would like to get to the bottom of the problem.

Like yourself, I am new to bitcoin/litecoin. I have done bitcoin mining for a week, but have only got this problem while litecoin mining this week. I write software for a living, so can probably give you any detailed feedback you need finding this.

I got the latest version, and it is working. I must have missed the fix in the previous download.

From the log, it looks like it falls through into another check while the miner is restarting, but it turns out allright and access is picked up again.

Here is the log for around that time in case you are interested how it went:

[07/05/2013 23:25:05] Total shares have not changed for 10 minute(s), longer than the threshold of 10 minute(s). Attempting to restart...[07/05/2013 23:25:05] Restart command sent to CGMiner with full privilege API access.[07/05/2013 23:25:15] CGMiner was successfully restarted.[07/05/2013 23:25:26] I do not have API access to the currently running CGMiner process (3488)[07/05/2013 23:25:27] I lost API access to a process in which I had it for at least the past 13210 seconds. Attempting to restart CGMiner...[07/05/2013 23:25:29] I had no API access to CGMiner so I killed the process. I will now attempt to re-open it...[07/05/2013 23:25:39] CGMiner was successfully re-opened after killing its process.[07/05/2013 23:25:50] I do not have API access to the currently running CGMiner process (872)

I just thought - sometimes when I close CGMiner it goes through all the closing stuff and just hangs there, I don't know if you ever get that. It could have been this that caused it to trip out the second time and fall back the the kill process method.

Sorry for getting back to you late, I have been keeping up on your comments and trying to make sure they are corrected in v1.1.4.

A few things to mention:

- CGWatcher may show slightly different share counts than the miner because a)CGWatcher only refreshes every X seconds, where X is the monitor interval, and b) the miner only refreshes its display every X seconds, so the count it sends to CGWatcher may be between display updates and never shown in the miner. The Report tab will now show when the last time accepted, rejected, stale, and discarded counts have changed.

- The 'restart if share counts stop increasing for X minutes' will now only watch accepted share counts. This is the only share count that matters so if it stops increasing, a restart is a good idea. The Utility field on the Status tab shows you accepted shares/minute, so it should help you estimate how many minutes to set for this option for your configuration.

- When stopping the miner... if CGWatcher has full API access, it sends the quit command to the miner. It will now watch for up to 10 seconds after that for the process to end. If it doesn't, it will spend up to an additional 10 seconds trying to kill the process. Likewise, if it doesn't have full API access it will now kill the process then spend up to 10 seconds trying to kill it (if needed) before giving up. This happens -any- time it tries to stop the miner, regardless of why it is stopping it.

- The Report tab will now display a ton of info, including some debug info at the button and the last 10 log entries. This should mean that just sending the text from the Report tab and a description of the problem should be enough to troubleshoot problems.

- I believe the API access checks should be fixed in 1.1.4. It may have been too aggressive on checking for this, so now it gives the miner more time to startup before checking.

- A new 'Ensure miner stays running' option that if enabled, will launch the miner any time it is not running. This is an option because it is impossible to determine why the miner is closed - if it closed because of a problem or the user closed it and doesn't want it re-launched. If the miner fails to start 3 consecutive times, it turns this option off and notifies the user.

- Some cool new stuff is in 1.1.4. Stuff to help beginners and users who mine different coins. Profiles so you can switch to different miners & configs very easily. I am hoping to have 1.1.4 up by this weekend. Thanks for the feedback, it is very helpful. Do you have .NET development experience?

I have done a couple of .NET projects at work to give a GUI for the embedded stuff we make. We used to use VS6, but all the new GUIs we make are in .NET. I do more C and assembler than .NET, and am used to writing software to run on bare metal. Operating systems are for the weak!

I have noticed a couple of times when stopping the miner, CGWatcher restarts it again. It doesn't do it very often, but I have seen it 2 or 3 times so far.

Having an issue getting the scheduler to start. I see the comment at the bottom indicating that I should use the required arguments else it won't work. What are these? I have got the "--api-listen --api-allow W:127.0.0.1" in my Miner Argument field. Is there something I'm missing? Other than this issue, it stops/starts and monitors the miners without any issues :)

Download again and see if it is fixed. Oddly enough, I had found a scheduler bug tonight and believe it should be fixed now. I was hoping to do more testing tomorrow, but I've uploaded the fixed version so the download link will now point to it. If any new bugs are introduced I will be available tomorrow to work those out.

Assuming you're doing this on different cards which would require two instances of cgminer, each would need its own CGWatcher instance to monitor it. Even then, CGWatcher will have unexpected results if the miners were ever started outside of CGWatcher (otherwise it wouldn't know which process you wanted it to monitor.) You would need to use different ports for each miner's API (e.g. 4028,4029). The CGWatchers would need to be in separate directories so each has their own ini file. This may also be necessary for cgminer. If you did all this and always started/stopped the miner with CGWatcher, it *should* work, although I haven't tested that so there may be unexpected results I'd have to work out. But monitoring two instances of cgminer from one instance of CGWatcher is not supported.

I'm trying to mine LTC, DODGE, and EAC shows that I'm getting 75 MH/s not sure if thats a real value since its just 1 r7 260 card. Not using Cgminer using the other miner it connects... any help would be appreciated.

Any chance of adding an option to cgwatcher that doesn't use normal key to exit cgminer, but rather uses a windows command to close the window. Radeon R9 290 multiple cards only seem to mine reliably on the .11 beta which BSODs on using the exit command key from cgminer, but closing the cgminer window by clicking the X at the top right works just fine.