Pages:
Author

Topic: CGWatcher 1.4.0, the GUI/monitor for CGMiner and BFGMiner to prevent downtime - page 16. (Read 180386 times)

sr. member
Activity: 434
Merit: 251
CGWatcher & CGRemote
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.
newbie
Activity: 4
Merit: 0
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!
sr. member
Activity: 336
Merit: 250
Looks awesome - definately going to check this out
member
Activity: 103
Merit: 10
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.  Smiley
sr. member
Activity: 434
Merit: 251
CGWatcher & CGRemote
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.
member
Activity: 103
Merit: 10
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.

legendary
Activity: 1820
Merit: 1001
How to make config files for usb eruprots to mine with I tried to detect with test however says nothing found?
sr. member
Activity: 434
Merit: 251
CGWatcher & CGRemote
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.
member
Activity: 103
Merit: 10
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.
sr. member
Activity: 434
Merit: 251
CGWatcher & CGRemote
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.
full member
Activity: 127
Merit: 100
milone, thanks for your job and full answer from my question. Good luck!
sr. member
Activity: 434
Merit: 251
CGWatcher & CGRemote
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.
sr. member
Activity: 840
Merit: 255
SportsIcon - Connect With Your Sports Heroes
Please create an option to select the CPU priority of the miner. Thank you!
full member
Activity: 127
Merit: 100
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.
sr. member
Activity: 280
Merit: 250
Sometimes man, just sometimes.....
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://bitcointalksearch.org/topic/bfgminer-and-usb-block-erupter-problem-help-needed-user-privilegescom1-269249 (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.
sr. member
Activity: 434
Merit: 251
CGWatcher & CGRemote
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://bitcointalksearch.org/topic/bfgminer-and-usb-block-erupter-problem-help-needed-user-privilegescom1-269249 (which goes on to discuss other problems, but this was the OP's issue).
sr. member
Activity: 280
Merit: 250
Sometimes man, just sometimes.....
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.
sr. member
Activity: 434
Merit: 251
CGWatcher & CGRemote
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.
sr. member
Activity: 280
Merit: 250
Sometimes man, just sometimes.....
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.
sr. member
Activity: 434
Merit: 251
CGWatcher & CGRemote
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.
Pages:
Jump to: