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

[Zanatos666]

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).

Well I updated and seems to be running okay for now.  I do have the folder on the desktop.  I will have it moved and see if the behavior continues.

Thanks for the help.

[Loft]

Hello, milone!
Please tell me why in the table I see the empty space, how do I change that?


I found another bug. If you add 38 and more pools in the config file, the last pools are displayed incorrectly.

[Wipeout2097]

Please create an option to select the CPU priority of the miner. Thank you!

[milone]

Loft:

If the coin doesn't have values it was either not on CoinChoose when profitability data was last updated or an error occurred while updating the data. It was requested that coins that drop off CoinChoose just get set to zero rather than being removed (I can't remember the reasoning offhand), but if you would prefer coins not on CoinChoose to be removed you can open CGWatcher.exe.ini and change RemoveMissingCoins=False to RemoveMissingCoins=True. You can also go to the Settings tab, click the 'Other Tools...' button and select Coin Manager from the popup menu. This will allow you to remove coins individually (or add/edit coins).

The Pools not displaying correctly is because there are so many that cgminer's API data is being truncated (cut off). I'll look more into how I can correct this, I may be able to get a few more pools but there will always be a limit because all API data has a maximum size and anything beyond that is lost and ends up looking like those chinese characters. When there is this many pools, I can get the info for the truncated pools from the config, but I won't know of any changes to priority for truncated pools. For example, if pool 40 gets changed to priority 0 and pool 40 is truncated, cgminer will be unable to tell CGWatcher the new priority. So the url/username/password will be fixed, but the priorities for pools 38+ may be inaccurate or unknown (if they have changed from the priority set in the config).

Edit: I forgot there is a checkbox in Coin Manager you can use to enable/disable removing of pools not on CoinChoose, so manually editing CGWatcher.exe.ini isn't necessary.


Wipeout2097:

This will be in the next update, along with CPU affinity. You can set CPU affinity and priority for each profile.

[Loft]

milone, thanks for your job and full answer from my question. Good luck!

[milone]

New in version 1.3.2

• Desktop folder added to protected directories list to notify user that CGWatcher, miner, and config files should not be stored there.
• Advanced Profile options to set CPU affinity and priority for miner process. Additional options to come in future versions.
• Profile matching relaxed during miner launch to reduce risk of miner being ignored (rare).
• Fixed ads only reloading after restarting CGWatcher.
• Button added to Tests tab to list all installed .NET updates for troubleshooting purposes.
• Option to restart computer if CGWatcher is unable to close or kill miner processes. Although rare, this indicates a more serious problem (Task Manager is also unable to kill the processes) and usually leads to a BSOD (crash). The only way to resolve this is to restart the computer.
• Pools truncated from miner's API response (~Pool 35+) will get info from config to avoid chinese-looking characters being shown for url/username/password. No stats are available for these pools though because the data is cutoff from the miner's response, which has a fixed maximum length.
• Fixed pools set in arguments being added twice to temp config file before miner starts.
• Added scheduled action to send specified API command(s) to miner.
• Settings tab added to Coin Manager, 'Remove coins no longer on CoinChoose' option moved to Settings tab of Coin Manager.
• Coin profitability data refresh interval setting now in Settings tab of Coin Manager.
• Setting created to base coin profitability on bitcoin or litecoin, located in Settings tab of Coin Manager.
• New coin notification option moved to Settings tab of Coin Manager.
• Scheduled action frequency added - 'When event occurs...' allowing you to select from a list of events that will trigger the action being run. Events currently consist of miner events, profile events, and coin profitability events. More events will be added in future updates.
• Create your own profitability formula in a custom coin field that can be used when creating scheduled actions that switch profile based on profitability. Instead of using an existing field (profitability, difficulty, etc) you can create your own mathematical expression using all existing fields and mathematical functions.
• Fixed CGWatcher not trying to start the miner indefinitely when the 'Keep trying indefinitely' failure option was selected. (It will try up to 2147843647 times.)
• Miner process not added to checked process list until it has been running for 60+ seconds to prevent incorrectly ignoring it.
• Added 'Send email' scheduled action. You can specify an email address for each action, the last used will be filled in automatically. Emails are currently limited to 25 per computer per day, but this may increase or decrease over time depending on usage. Counter is reset at midnight EST/EDT (U.S. Eastern). Emails will be coming from @cgwatcher.com, and you will need to ensure you can access http://minerremote.com for email to work correctly.
• More scheduled action events will be added, with additional options like 'when hashrate drops below/%', 'when miner restart fails X consecutive times, etc. I figured I'd add them in groups instead of trying to do it all at once.
• If CGWatcher is set to try starting the miner indefinitely (and it keeps failing), it will wait one second per 10 attempts in between attempts over 10, up to 60 seconds. So after 600 attempts it will wait one minute between each attempt.
• CGWatcher restarting GPUs that cgminer has disabled due to overheat no longer requires CGWatcher's overheat protection to be enabled. It will do this for all GPUs since the miner usually fails at re-enabling them.
• Before restarting computer, CGWatcher will temporarily set itself to start with Windows and launch miner at startup if these options are not enabled. It will reset the options back to their original settings the next time CGWatcher is started.
• Restart computer prompt changed to always use CGWatcher's prompt only, which provides a cancel option, rather than the Windows notification that the computer is restarting. This was already how scheduled computer restarts were handled, but is now done for all computer restarts.
• Profitability-based scheduled actions (switch profile based on profitability) will update coin data before selecting a profile unless it had been updated within the past minute instead of within the past 5 minutes.
• Added average time per share to Monitor tab to help in setting appropriate number of minutes without share increase for this monitoring option.
• Added "% of Avg" to Hashrate Cutoff monitoring option, which will restart the miner if the current hashrate drops below the specified percentage of the current average hashrate. This is in addition to being able to set actual hashrate values.
• Elapsed mining time added to Stats tab.
• In Pools tab, pool drop-down will default to current pool and revert to current pool if user has not selected a different pool to view within the last 5 minutes.
• Added support for pool quota option in CGMiner 3.4.3+
• Added config file and argument options up through CGMiner 3.5.0 and BFGMiner 3.2.1.
• Select a different value to display on the Status tab in place of Efficiency, or create your own value using existing values and mathematical functions to create a custom expression.

[Makitaki]

It seems version 1.3.2 has a bug with a "-g 2" argument: cgminer ALWAYS runs only one thread instead of two. If I start a cgminer batch file with the same parameters outside of CGWatcher, everything works OK. Also, when I downgrade to 1.3.1, everything starts working correctly again. Please check this out.

[milone]

Thanks, looking into this now. If you can start the miner with CGWatcher (to reproduce the problem) then go to the Tests tab in CGWatcher and click the 'Miner Start' button, it will display info about the config/arguments used to launch the miner. If you can email this to me (address at top of readme) it should make it much quicker to find the problem.


Edit: This is fixed, and version 1.3.2.2 is available. The problem was CGWatcher leaving this option out since it was set to its default value (2) which means the miner should have used 2... but I also saw that if left out it only used 1. Changes I had made to config file/arguments used at miner launch in version 1.3.2 is why this wasn't a problem before. Because of this unexpected behavior, it will always save the gpu-threads value to the config file, even if it's the default value. And if you're using arguments, it should be corrected now also. Thanks for making me aware of this, and let me know if you still experience any problems with it.

[crazyearner]

How to make config files for usb eruprots to mine with I tried to detect with test however says nothing found?

[Makitaki]

Edit: This is fixed, and version 1.3.2.2 is available. The problem was CGWatcher leaving this option out since it was set to its default value (2) which means the miner should have used 2... but I also saw that if left out it only used 1. Changes I had made to config file/arguments used at miner launch in version 1.3.2 is why this wasn't a problem before. Because of this unexpected behavior, it will always save the gpu-threads value to the config file, even if it's the default value. And if you're using arguments, it should be corrected now also. Thanks for making me aware of this, and let me know if you still experience any problems with it.

Yes, you're totally correct, cgminer always ignores this argument though it should use it as a default value (as described in the cgminer readme). It uses it only when -g 2 is set manually. Thank you very much for your support and sorry, I was busy and couldn't send you the needed info.

Another suggestion. Would it be possible to add an option of a manual cgminer delay for more than 30 seconds with "ensure miner stays running unless paused" option enabled? I think 60-120 or even 60-300 seconds would be enough. I mean when an OS restarts, even if you have an SSD, sometimes it takes more than 30 seconds for all resident programs to run, and when CGWatcher starts at this interval increasing GPU load to 100% it could lead to a driver crash ("Display driver stopped responding and has successfully recovered"). For example, KIS needs a lot of time to load all its services, run an update, etc. For me personally, an ideal delay would be about 60 seconds though in some cases, especially with an old HDD, it could be better to delay cgminer even more.

And one more small bug (?). On my system, the coin profitability tab shows some columns incorrectly. I understand that it has to do something with regional settings. I for one use the English Windows with the Russian regional settings.

[milone]

crazyearner:

Did you get this working? If not, are you using cgminer or bfgminer, and which version? Each has its own method for detecting and using them.


Makitaki:

I'm hoping that always including gpu-threads in config files doesn't cause any unexpected behavior for anyone who had been mining with one gpu thread and didn't realize it. But the readme says the default is 2, so I think ensuring it uses 2 is the correct way to handle it, and if anyone wants to go back to 1 they just need to change the setting to 1.

If you set CGWatcher to launch the miner when it starts, you can change the delay by changing the AutoLaunchDelay setting in CGWatcher.exe.ini. The value is the number of seconds to delay on auto-launch, and the default is 10. If this auto-launch setting is enabled (it's in the Settings tab), it overrides the 'Ensure miner stays running' option at startup.

So when CGWatcher starts, it first looks to see if it is set to auto-launch the miner (Settings tab option). If it is, it will use the AutoLaunchDelay seconds and temporarily disable the 'Ensure miner stays running' option until after the miner is auto-launched. Once this initial miner launch occurs, then the 'Ensure miner stays running' option is re-enabled. If the auto-launch option is disabled, the 'Ensure miner stays running' option currently kicks in immediately after starting, as you're pointing out.

That said, I'll also put on the to-do list to add a similar delay setting to the 'Ensure miner stays running' option, but using the above should provide what you're looking for also. I'll also find somewhere in the UI for the auto-delay setting so you don't have to edit the INI file.

As for the number formats, that is odd regardless of culture settings. I don't have the code in front of me right now and I don't remember exactly the method I used to format these values, but when I get back home I'll look into this and get it corrected.

Thanks again for the feedback.

[Makitaki]

If you set CGWatcher to launch the miner when it starts, you can change the delay by changing the AutoLaunchDelay setting in CGWatcher.exe.ini. The value is the number of seconds to delay on auto-launch, and the default is 10. If this auto-launch setting is enabled (it's in the Settings tab), it overrides the 'Ensure miner stays running' option at startup.

Ah, thanks a lot, that's exactly what I need. And kudos to you for a thorough explanation because it wasn't totally clear for me what was the difference between 'run miner when started' in Settings and 'ensure miner stays running' in Monitor and I wondered why we had two similar options in CGWatcher. Anyway, UI implementation of this delay option would be really cool though for the time being ini editing is enough for me.  

[Zeek_W]

Looks awesome - definately going to check this out

[auth100488]

1st : Awesome job, like really, that thing is just SOOOO usefull with non friendly Asics that decides to stop responding after a bit of time.

2nd: Well there is ( 1 ) thing that bothers me a lot, after a few minutes (about 45) when using Refresh every 2 seconds, the Watcher stops responding, I'v tried leaving the refresh to 10 secs, i crashes after about 2.5 hours.... Is there a way to disable the status window but leave the watcher checking on my asics? (i've read many posts but haven't found one with my very problem)

It is running on windows 7 pro N 64bit
i've included a copy of my small cgminer config file!

Code:

{
"pools" : [
	{
		"name" : "us1.eclipsemc.com",
		"url" : "http://us1.eclipsemc.com:8337",
		"user" : "*****",
		"pass" : "*****",
		"pool-priority" : "0"
	},
	{
		"name" : "us2.eclipsemc.com",
		"url" : "http://us2.eclipsemc.com:8337",
		"user" : "*****",
		"pass" : "*****",
		"pool-priority" : "1"
	},
	{
		"name" : "us3.eclipsemc.com",
		"url" : "http://us3.eclipsemc.com:8337",
		"user" : "*****",
		"pass" : "*****",
		"pool-priority" : "2"
	}
],
"api-allow" : "W:127.0.0.1",
"api-listen" : true,
"api-mcast-port" : "4028",
"api-port" : "4028",
"balance" : true,
"expiry" : "120",
"hotplug" : "5",
"kernel-path" : "/usr/local/bin",
"log" : "5",
"queue" : "1",
"scan-time" : "10",
"shares" : "0",
"gpu-threads" : "2",
"no-pool-disable" : true
}

I do not expect an answer but i told myself hey why not signal this problem so maybe others that have it might leak a little info.
I understand that helping new people might sounds/feel like a pain in the butt, but i ensure you that i have done the proper research before crying for an answer!

Thank you very much for your time and hope to hear soon from that cgremote!

[milone]

Are you using the latest version? There was a bug several versions back that would cause CGWatcher to stop responding in certain circumstances, but it was fixed and this is the only report of it happening since then.

If you're familiar with Windows Event Viewer do you mind checking to see if there is any info reported when CGWatcher stops responding? Also, what are the computer specs (cpu, ram, etc)?

I don't see anything in the config that would affect this. It's possible there is a memory leak somewhere but I try to watch for things like this and aside from the previous bug (which was not due to a memory leak), like I said this is the first I've heard of this. Right now I have CGWatcher instances that have been running for 3+ weeks, also on Windows 7 x64.

Any additional info you can provide would be appreciated.

[roadsterreplica]

Here is my crazy bug. Maybe you can help me figure it out.

1) When running CGWatcher and then trying to run cudaminer, the cards won't hash. The only way I can get them to hash again is to delete the CGwatcher from my computer.
2) CGWatcher and scrypt, seems to be a bit porked. When CGWatcher is on the computer, the scrypt coins aren't showing any positive hash rates. Even running cgminer or bfgminer on its own is giving issues (lots of block found messages, no accepted share messages) Removing CGwatcher and the system starts working again.

Thanks for looking into this.

[auth100488]

Update:
Settings:
Restart Cgminer Every 1hours of running time
120 sec status refresh

Not a single crash in 24h... hmmm

As for the application log part,
There if nothing there aout cgwatcher, i'd have to make it crash and make sure the exact time, i might do that next weekend!

Thanks for your answer! you are awesome!

(yes i am familiar with it as i work as an It Specialist )

Thx again! keep on the good work!

[milone]

auth100488:  I'd suggest checking CGWatcher's memory usage in Task Manager when you start it, then checking after 24 or 48 hours, etc. to see if it continues growing at a rate that would cause problems with your system. Memory usage may grow a little over the first few hours it runs, but then level off. The fact you're having less problems at higher refresh intervals makes me thing this could be the problem, but like I said it hasn't been reported before and I have instances that have been running for several weeks. I wouldn't suggest going below 10 seconds on the refresh interval simply because it's not necessary and there is no need to bother the miner that often with requests for info. Setting a very low refresh interval would also increase the odds that cgminer and CGWatcher try to get ADL device info at the same time... which I'm not certain would cause a problem since CGWatcher is only reading it but it might... I'm not sure how ADL would handle this.


roadsterreplica:  CGWatcher doesn't support cudaminer. The two should have nothing to do with each other except the possibility that cudaminer might also uses NVAPI to get Nvidia GPU info (temperature, fan speed, clock speeds, etc) which CGWatcher also does for Nvidia cards.

As far as scrypt mining, CGWatcher doesn't care which type of coin you are mining. It is merely providing a GUI for the miner, and monitoring things to ensure it is working properly. If you are using cgminer 3.6.6-1 or newer, there are known issues for scrypt mining: https://bitcointalk.org/index.php?topic=28402.msg3477780#msg3477780 If you are using a version newer than 3.6.6, you should downgrade to 3.6.6. or older. I'm currently using cgminer 3.5.0 for scrypt and there are no problems.

Even running cgminer or bfgminer on its own is giving issues (lots of block found messages, no accepted share messages) Removing CGwatcher and the system starts working again.

CGWatcher is a portable application. Removing it will change nothing other than deleting its folder and files. Whether you close CGWatcher or delete it, there would be no difference to what cgminer is doing. Here is essentially all CGWatcher does:

- Sends requests to cgminer for info, gets response back. Checks/displays the info.
- Sends commands to cgminer when the user tells it to, or restarts cgminer if a problem is found.
- Uses ADL (AMD) and NVAPI (Nvidia) to get GPU info (cgminer also uses ADL). These are APIs from the GPU manufacturers to help get GPU info.
- Uses OpenCL to get OpenCL device information because cgminer uses OpenCL. It only does this at startup.
- Launches or closes the miner if necessary or scheduled.
- Writes/reads from the files in the CGWatcher folder occasionally.

CGWatcher is only launching the miner for you using the config settings you provide. It doesn't do anything else to the miner while mining that would cause the problems you're describing. The problems you're having are more likely related to recent cgminer scrypt issues. If you can provide more information on specific problems, I'd be happy to help you troubleshoot them. I'm not implying CGWatcher is perfect or there isn't room for improvement... it's a constantly evolving project that interacts with two other projects in active development.. so there could be changes to cgminer's or bfgminer's API that need changed in CGWatcher, but I try to keep up with this. But the problems you're describing and the solutions you think you've found are technically unfeasible. It is much more likely to be coincidence that deleting CGWatcher had any effect whatsoever.

[Digicoiner]

I tried to update to version 1.3.2 but Kaspersky is detecting the 'false positive' on cgwatcher.exe.  I've played around with setting exclusions but no success.  Has anyone had success setting an exclusion and if so what were the settings or will this be reported as a false positive?

[milone]

I'm not sure which Kaspersky software you're using, but I did find a few guides:

PURE 2.0: http://support.kaspersky.com/7913

Internet Security 2013: http://support.kaspersky.com/us/8742#block2

I stopped submitting false positive reports because they would only whitelist the version I sent, meaning the false positive was back for the next version - no matter what or how little I changed. I'll submit a false-positive report again for the current version. They check it, whitelist it, update their definition file, then you have to make sure you update your definition file. This usually takes a day or two.

They were not able to tell me why it is being flagged, and it is a heuristic false-positive meaning no malicious code was found but it may share characteristics of some malware (what that is I have no idea). They also didn't respond to why they couldn't fix the false-positive for the program instead of only each version as Symantec was able to do a few months back when something triggered a heuristic false-positive with Norton. It may be the language barrier with Kaspersky support, but they aren't very helpful. At any rate, the program has been manually checked out by Symantec and Kaspersky (several times)... and the false-positive has been confirmed and fixed each time... so hopefully that attests that it is doing nothing malicious.