CGWatcher is designed to run on the same computer as the miner in order for it to have complete control over the miner process. For self-contained mining devices like KnC miners, you can use CGRemote (http://minerremote.com) to manage them, along with any other miners you have.




CGWatcher 1.3.4 is almost finished, should be available tomorrow if tests tonight go according to plan.

The 'scan' setting is what is causing the error. There is no support specifically for the scan setting in CGWatcher, and normally it would be able to handle unsupported settings by putting them into a "Miscellaneous" collection... but in this case it's the json it is having problems with. I would suggest changing it to


and see if that works. If not you can remove the 'scan' setting from the config file and set it in arguments instead. In the arguments textbox in Profile Manager, you'd enter:


or I believe the short version is -S, so


should mean the same thing.

I'll have to work out how to handle this because I know there may be more than one 'scan' setting. The easy workaround is to pass these as arguments for now.

Taxidermista:  Please email me again because my inbox has been flooded over the past few weeks. There are around 200 people in the beta and of the few that reported issues connecting, it has always been a firewall issue or a port-forwarding issue. You look to have port-forwarding done correctly, so my guess would be a firewall issue. When you email me, include the bug report created by clicking 'Report Bug' in the toolbar.


Einewton:  Yes, a web application and Android app are planned, but not until the desktop application is released. The web application will be located at http://MinerRemote.com. I've received some offers for help on these, so development should be pretty quick.

krich:  There are some issues with CoinWarz that have been corrected in the update I'm working on. Not only does it reduce api calls, but if you use CGRemote you can have CGRemote send the profitability data to all of your miners running CGWatcher, saving even more api calls.


financial_analyst: Nothing in the config you posted looks as if it would cause this. The 'API running in IP access mode on port 4028' is normal. I'm not sure if it displays when the miner starts (if api access is enabled) or the first time something connects to it, but it should not be causing an issue. What do you mean by 'activate miner'? I'm assuming you have cgminer running, then open CGWatcher, then click on the cgminer window? Have you tried starting the miner with CGWatcher and does it cause the same problem? If you're using a batch file to launch cgminer, you can just point CGWatcher to the batch file instead of the executable when you're creating a profile. It will import all config settings from the batch file, and if you change any in Profile Manager it will save them back to the batch file.


yuh:  I believe the problem is that the 'start miner' timeout was not working properly, so the first attempt to start the miner lasted indefinitely, or until that prompt. In the next update I've added a setting where you can tell it how long it should wait for the miner to start before killing it and trying again. The prompt you're seeing will only appear if the miner has been started by the user (clicked Start button) and was only supposed to prompt the user if the first attempt failed, but this may not have happened. I removed the prompt in the next update as well, as you can just click the Cancel button if you want it to stop trying.


lucky7:  For FPGA and ASIC devices, CGWatcher gets their info directly from the miner. So if cgminer is detecting the device, CGWatcher should be also. CGWatcher does not try to detect devices on its own because there is no need to - if the miner can't find it it won't be mining. If you send me a debug report, I can look for a problem that would prevent CGWatcher from displaying the Jalapeno correctly. I have a Jalapeno and use cgminer and it displayed correctly for me, so it is not specific to the device.

If you are mining two separate instances of cgminer (one for the Jalapeno and one for the GPU), then you need to set each instance to use a different api port and then set CGWatcher to use the port of the instance you want it to connect to. You can find more information on running two instances here: https://bitcointalk.org/index.php?topic=159267.msg3853830#msg3853830

chopsbit:

My reply was for kimpeck. Good to hear you got your issue resolved.

kimpeck:

You do not need two profiles for this. Just create one profile and add both pools to it. Enable failover in your config settings and cgminer/bfgminer will switch to the second pool if the first one goes down, and then check occasionally to see if the first pool comes back up. If it does, it switches back to the first pool.

chickenthr33:


I'm still working out the best way to handle this to ensure it always works... although Windows is making that difficult. I'm working on an update right now and will try to get it straightened out.

You're killing me.


chopsbit:


Run two instances of CGWatcher - one for each miner: https://bitcointalk.org/index.php?topic=159267.msg3853830#msg3853830

I started writing a post explaining how to do this, but then I started changing a bunch of stuff in this update and now my post is outdated so I'll try to update and publish it after this next update.

Taxidermista:  Please email me when it is related to CGRemote until I create a forum post for it (which I'll do closer to release). Also, include the bug report (click Report Bug in toolbar) when reporting problems. If you have ports forwarded correctly, it is 99% likely a firewall issue. Make sure CGWatcher and CGRemote have access through their respective firewalls. If you're using Windows Firewall, you may need to create an additional 'Allow' rule for the port on each miner. I ran into this problem, but the computer was also running Windows Firewall Control, so that may have been the cause. For incoming firewall rules on the miners (for CGWatcher), enable "Allow edge traversal" in the Advanced tab of the rule's properties (using Windows Firewall with Advanced Security). If you're using different firewall software, let me know what it is and I can try to help.


I'm still hoping to have the CGWatcher update out this weekend, although my time estimates are almost always wrong.

You first need to get the miner stable, then you can try tweaking config settings. Run

cgminer.exe --scrypt --thread-concurrency 8192 --gpu-engine 1100 --gpu-memclock 1250 --gpu-powertune 20 -I 13

Don't forget pools. Obviously I'd recommend using CGWatcher to make all of this easier.

If that is able to handle changes and restarts, then you can try adding another argument. I've never seen lookup-gap set to 0. Try it set to 2 (or leave out altogether).

I think your config is what is causing you problems. Regardless, I'm making changes in the next CGWatcher update that should really improve stability between restarts and profile switching.

When you change voltage in CGWatcher it is actually just sending a command to cgminer/bfgminer telling it to change voltage.

Are all three cards identical? Your options here would be to:

a) Use another program to verify that the third GPU voltage hasn't changed. CGWatcher (and cgminer) get the voltage from AMD ADL, but other software like GPU-z or Sapphire Trixx may use a different method?

b) Try changing the voltage of the third card with another program like Sapphire Trixx or MSI Afterburner and see if it still does not change.

c) Check for BIOS mods for your card that set the voltage lower. Only do this if you know what you're doing, as flashing the card's BIOS incorrectly may brick the card. There is a ton of information out there on doing this... read it all before trying it. I, nor anyone else giving you advice, is responsible for what you do with your card.

The cgminer & bfgminer devs are no longer supporting GPU mining so I'll save you the trouble - you won't get help from them.

Good luck!

You can create a scheduled action to switch profiles when the current pool goes down. Just select 'when event occurs... ' and then 'Miner - current pool goes down'. This is probably the closest you can get at the moment. I'm currently working with some multipools to get which coin they are mining, so in the future you would be able set it to switch to a profile of the same coin the multipool was mining should the multipool go down.

If that doesn't answer your question let me know and I'll try again.

reubes:

You can create a scheduled action to restart a specific GPU when certain events occur, but I have not yet added conditional events (e.g. when hashrate is below N). I'm working on an update for this weekend and will try to have at least this event added.


krich:

I'll check this, but to be clear you're trying to set it to CoinChoose and it's resetting to CoinWarz? It should treat CoinChoose as the default.

As far as the hashrate falling, there are some changes I'm going to make in the next update that may improve this... although I can't say for certain. At the very least they should improve stability when changing profiles. Beyond that it becomes more of a system or miner issue, as all CGWatcher is doing is stopping or starting the miner.


chickenthr33:

That's a new one. Do you have any antivirus software installed? It may be causing a problem with cgminer launching. Also, a quick Google search showed a lot of results related to fake spyware removal programs (the ones that tell you they found more viruses than you have files). I would suggest starting with a scan, I use Windows Defender and Malwarebytes Pro. Also make sure that you've white-listed cgminer since some antivirus software flags it since older versions were used in botnets.


carly200:

It's good to know I'm not the only one who does this.


d-unknown:

http://manotechnology.blogspot.com/p/cgremote.html#joinbeta

Taxidermista:

I'm going to make changes that will kill the miner rather than shut it down during restarts, which should help with stability.. at least when restarting using the same profile or a profile using the same algorithm.

As far as how CGRemote works, the short answer: magic. The long answer: port forwarding. If there wasn't a way to reach your computer from the Internet you would not have been able to post that reply. Port forwarding tells your router that when data comes in on a specific port, forward it to a specific computer on the LAN. Each computer on your LAN would then use a unique port, each setup for the router to forward. If you want to use a dynamic IP hostname service like dyndns you can, or you can just update the IP address(es) when/if they change.



Goldshredder:

https://bitcointalk.org/index.php?topic=159267.msg3853830#msg3853830



frufru:

The reason I chose not to use the startup folder is because it seems to not work 100% of the time, so I'm not completely surprised that didn't work. I just got some Windows 8 PCs set up so I'll have to see what new unexpected behaviors are found with modifying the registry. CGWatcher should try to set itself to the HKLM/Software/Microsoft/Windows/CurrentVersion/Run key (all users), and if that fails it tries the HKCU/Software/Microsoft/Windows/CurrentVersion/Run key (current user only). However, if you're not running CGWatcher as Administrator, Windows virtualizes the HKLM hive so CGWatcher thinks it saved correctly but it was actually stored to some WOW6432Node key somewhere. I think what I need to do is just set CGWatcher to start with Windows on a per-user basis, so HKCU only. If you need it to start automatically for multiple users, just open it at least once in each user with the "start when Windows starts" option enabled.

This will be changed in the next update, which I'll try to have out this weekend.

Einewton:  I'm not sure why that would happen, but it's been a while since I've visited that part of the code so it's possible that I made changes recently that had unexpected affects on the monitor. I'll be looking into this the first chance I get. (Out of town for the next week or two and have to setup Visual Studio on my new notebook). The monitor has always been my first priority with CGWatcher, so if something is not working correctly on it I will make sure it gets fixed.


knowone:  If the miner has a lower hashrate after being started with CGWatcher, it is most likely due to the gpu-threads setting. In cgminer's readme it states that the default value for gpu-threads is 2. So if you do not explicitly set the gpu-threads setting in arguments or config file, it should use 2. But it doesn't, it uses 1. This is something a user pointed out a while back and I tested myself and confirmed. So I made CGWatcher set it to 2 by default, so it would produce the expected behavior one would expect after reading cgminer's readme. This means that starting cgminer outside of CGWatcher uses 1 gpu thread, and starting cgminer with CGWatcher uses 2 threads. Whenever someone has brought up seeing a lower hashrate when the miner is started by CGWatcher, it has been because of this 100% of the time.

In CGWatcher you don't have to point to the .exe when configuring the profile. If you already have a batch file you can point to that instead. CGWatcher will load any arguments from the batch file, and if you change them in Profile Manager it will save them back to the batch file. It will not affect the setx commands or any other commands in the batch file, those will remain in place. I've seen conflicting statements on how long the setx commands are applied for - some say you only need to run the commands once, others that the command will work until the next computer restart. I don't know which is true, and I never really took the time to find out. But if you would prefer running them before launching the miner - just in case - then I would recommend pointing the profile to the batch file instead of the executable.

Sorry, I  forgot to change the version number in the download link. It still pointed to 1.3.3.2, but the link text said 1.3.3.1. It should be fixed now.




How are you closing cgminer when you do it outside of CGWatcher? Clicking the X?  CGWatcher sends the 'quit' command when it stops the miner, which is different than clicking the X because the miner shuts down and returns clock and fan speeds back to their original values. This is the same as using the menu in cgminer to quit. Either way, I think I will make some changes to how CGWatcher performs restarts so there is no chance  it will restore clock and fan speeds just to have to bring them back up a few seconds later. That will be in the next update, and may provide better stability. But for stopping the miner, all CGWatcher does is send the 'quit' command to the miner and the miner closes itself after restoring clock speeds and cleaning up. When you click the X it never gets chance to do these things.

I recently added the ability to display banner ads in CGWatcher, a free GUI and monitor for cgminer and bfgminer (most popular mining software), in order to advertise my new project, CGRemote. Being a GUI, CGWatcher is something that is watched or checked often throughout the day by most miners, and as of this post it is running on over 14,000 28,000 computers (the count shown on www.cgwatcher.com is updated in real-time and only includes version 1.3.1 and newer when I began collecting usage stats). I designed the banner ad system so that I could add additional ads at any time, without requiring a software update. Ads are displayed in rotation, one per hour. The default duration is 30 seconds. Both the duration and frequency are customizable. Ads can be closed by the user by clicking an X in the corner, or can be clicked on to open the website of the product.

Along with CGWatcher's in-app ads, I can also display banner ads on the CGWatcher download page, which is currently getting 10,000+ 20,000 views per week (and climbing).

If there are any problems that prevent the ads from being displayed, I will refund the full amount. I would suggest setting up landing pages to determine its effectiveness since it will not be apparent in referrals. This way you can decide if the ad is bringing you visitors when it comes time to renew it.

If you don't have thousands of dollars to spend on a Bitcointalk ad, want to throw some pocket change into additional marketing, or just want to support CGWatcher and CGRemote development while giving some attention to your product, CGWatcher may be a good platform. I am only looking to help legitimate products or services.


You can find more information on CGWatcher at http://www.cgwatcher.com or its Bitcointalk posts:  https://bitcointalk.org/index.php?topic=185553.220 and https://bitcointalk.org/index.php?topic=159267.340 (newbies)

More information on advertising specifically and how stats are collected: http://manotechnology.blogspot.com/p/advertise.html



Updated stats: CGWatcher is now running on 28,000 computers, and its download page is getting around 20,000 views/week. These stats have doubled in two weeks. If you're looking to reach miners, feel free to PM me. I'd like to get some feedback and want to help good products get some attention. I can verify all statistics are accurate. The platform is already there... I might as well do something with it.

468x60 banner ad in rotation inside CGWatcher: 0.1 BTC/month

Text ad at top of www.cgwatcher.com: 0.2 BTC/month

Open to offers, especially if I think you have a great product or service.

For CGRemote support, please contact me via email until I create a post for CGRemote here (which I'll do closer to release date). When reporting a problem, please include the bug report created by clicking 'Report Bug' in the toolbar. Try to describe the problem with as much detail as possible, including the hardware you're using and whether you're accessing the miner(s) from the same LAN or over the Internet - there is no such thing as too much information when reporting a problem.

Ah ok... it was just sent. Once the transaction confirms I'll send you an email. Thanks... I hope you find CGRemote useful.

What is your email address? You can PM me or just tell me the first part (e.g. JohnSmith instead of JohnSmith@gmail.com). I've gotten a ton of them today and I think I am keeping caught up, but it's possible I may have missed one.

Eboman - when this happens (while it is stuck), can you please go to the Tests tab and click the 'Create Debug Report' button. Email the report to my email address at the top of Readme.txt. If you can also attach cgwatcher.log, that may be helpful.

Is cgminer running correctly when this occurs? Typically CGWatcher should wait approximately 30-60 seconds for the miner to start, depending on settings. The only time it will wait indefinitely is if you have not specified any pools, which means you type in your pool manually when prompted by cgminer.

The more info you can provide when this happens, the better.



codegnome - I'll try to get this into the next update. A field will be added in the 'Coins' tab of coin manager allowing you to adjust coins individually.