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

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

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

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.

NICE!  Just sent over a small donation for ya!

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.

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.

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.

Thank you very much, keep up the great work.

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.

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.

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!

Hi,

A suggestion:

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

Thanks!

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?

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.

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.

Hello, milone. In version 1.3 doesn't work properly manage pools. I work on many pools and if I want a pool of priority, for example, 5 to make a 1, then before I just moved into place 1 and maintained. Now in version 1.3 saves move pools. I have to edit the conf file and manually specify the appropriate priority.
The problems of others has not yet figured out how the results will be, I will .
And one last question on the website http://coinchoose.com there are two calculating profitability relative to BTC profitability and LTC profitability. What is the scheme of switching in the program?

Are you able to run a device test in CGWatcher and email me the results? There is a button to do this in each tab, FPGA and ASIC. I'm not sure offhand why this would happen but admittedly there is still quite a bit of work to do in CGRemote, so this is probably something that just hadn't been completely finished. If you can also create a debug report in CGWatcher while the miner is running (go to Tests tab, click 'Create Debug Report') that will also have information helpful on troubleshooting this.

Also, have you customized these devices in CGWatcher (e.g. corrected an ASIC that was being reported as FPGA by the miner so it now shows as ASIC)?

Edit: Also, how many devices do you have?

hi,

Ive been testing cgremote and I have a bit of a problem.  Cgwatcher is working perfect and showing all my asics but cgremote shows me only my jaly and no bitburners. Any idea what may be wrong?

Are you able to start cgminer outside of CGWatcher with those settings?

If not, then we have to figure out what is causing the problem in cgminer. The best way to do this is to start it from an already open command prompt and add the -T argument so it will tell you what the problem is.

If so, then the problem is in the way CGWatcher is starting cgminer. The best way to troubleshoot this is to start the miner (or try to anyway), and after getting the message that it failed, go to the Tests tab and click Create Debug Report. Then email me the results. You can also click the 'Miner Start' button in the Tests tab to see the exact settings used to start the miner (this is included in the debug report), which may show if an argument or format is getting messed up.

There are certain arguments the .NET Framework does not like. The 2>log.txt option is one of them, and requires that the miner be started using a batch file. There hasn't been any reports of others, but you could try creating a batch file to launch the miner, then point the profile to the batch file instead of cgminer.exe. The arguments will be loaded from the batch file automatically, and if you change any arguments in Profile Manager it will save them back into the batch file.

It keeps getting stuck on waiting for cgminer api to start!  I'm stuck and dunno what i'm doing wrong.  I'm running as admin as suggested.


Any ideas?