If they're on the same LAN it's almost definitely a firewall issue. Please consider posting this to http://coinmyne.proboards.com as I'm trying to build up help content there that other users can find if they have a problem. Otherwise email me and I'll get back to you shortly (I just woke up, so I have a backlog of emails to go through). Let me know what firewall software you're using.

Justin

"Bought out" isn't what I would call it. This wasn't really about just buying the software... it was about me joining the team and bringing the software with me. I'm now working full-time at CoinMyne as VP of Software Development, where I'll lead all software projects - including CGWatcher and CGRemote. This has come up several times today so I'll explain in a little more detail what happened and what users can expect.

CoinMyne has a growing mining operation, so they use and really liked CGWatcher and CGRemote. They contacted me and asked if I'd like to be able to work on them full-time and have whatever resources I needed (a software developer's dream). I am still in control of all software, though being users of the software themselves, the guys had some great ideas I'll be talking more about soon. Nothing was forced on me or the software - no fine print - no catches - no instant monetization plans. CGWatcher will still be free and will continue to be updated regularly for the foreseeable future. If updates stop it will be because we have something better to offer in its place. CGRemote will continue the path it has already been on... but should progress much faster once I move and get settled in LA (in the next few weeks).

So right now the only thing that changes is that I'll have more time, more resources, and more ideas. I've been approached in the past with similar proposals... but the motivation and vision these guys had really set them apart. In the coming months, I think the users will also be very happy with the decision. We have some very interesting plans for the future... some of which you will be hearing about soon.

I apologize for the late response... it's been a pretty busy month as some of you may have heard. I'm back home after a week in Miami for the Bitcoin Conference, and now I have a few weeks to pack everything and move to Los Angeles. We've created a new support forum at http://coinmyne.proboards.com so you may find posting there more helpful, as information will be better organized.


I would suggest trying to save a config file outside of the user folder, so somewhere like C:\Configs for example. I'm still learning what quirky behavior Windows 8/8.1 brings in terms of permissions.




Click on the link that says "Incorrect hashrate for this GPU?" to open the GPU Map window. Here you can map the ADL device to the OpenCL device. It should be fairly straight forward since you only have one GPU.




Yeah I believe they may conflict. I would suggest setting backup pools in your miner config rather than using the scheduler to handle backup pools. This feature is already built into cgminer/bfgminer, and by default will switch to a backup pool if the previous pool goes down. It will then check occasionally to see if that previous pool is back up, and if so, switch back to it.

Showing the coin at the top has not been removed. If CGWatcher is able to determine the coin being mined, it will display it. If you're referring to multi-coin pools, if the pool is not currently providing the information then CGWatcher can't display it. For example, the data hashco.ws provided me is down at the moment, so it cannot display the current hashco.ws coin. I've emailed them and hopefully it is something they can fix quickly.




If you haven't already, please download the latest version (1.3.5.2) as it should have some additional handling for a blank miner window.




Yeah, this is from CGWatcher. Specifically, from the OpenHardwareMonitor library CGWatcher uses to detect GPUs and get their stats (clock speeds, fan speeds, etc.) It is nothing to worry about, and the events do not take up any significant space even though there are a lot of them listed. I don't believe it is possible to disable the events being logged unless I find another method of getting this information. As for now it's a relatively easy way and there's a lot on the to-do list so it may be a while before I can look into alternative methods.

stef942, can you try it without the kernel-path setting? I do remember adding some additional escaping for some reason (can't remember exactly at the moment) and I wonder if this is tripping it up. If it works after removing this setting then I at least know what to fix. Thanks.

That is definitely it. In older versions of cgminer, the total current hashrate was not reported via API so CGWatcher & CGRemote calculated it by adding all of the device's hashrates together. I believe in recent versions of cgminer or bfgminer the total current hashrate is reported. The question is then which one to use. I'm thinking the device shows the actual hashrate, and the 5s total takes into account rejects and hardware errors? Or it's a bug. I guess I should change it to only use the device sum hashrate if the total hashrate isn't available (older versions of cgminer).

That's odd. If you can send me a bug report, I should be able to tell why this is happening. Click 'Report Bug' in the toolbar, then send me the report it creates.

There will be email notifications in CGRemote, and several users have asked for the ability to use their own server, so it is on the to-do list.


Can you email me your config file and/or arguments? Thanks..

Have you used older versions of cgwatcher with that version of bfgminer and did it work? I don't believe I changed anything recently related to starting the miner. It looks like the miner starts and then closes immediately... are you able to launch bfgminer outside of cgwatcher using the same config settings?

You can use the Config File Editor in CGWatcher to create config files. Go to the Settings tab, click the "Other Tools..." button and select Config File Editor.




It's most likely a firewall issue. Try creating rules for the ports. I know Windows prompts you to create a program rule, but this doesn't always seem to work as expected. If you need help doing this, email me and let me know whether you're connecting to miners on the same network or over the Internet, as an additional step is necessary if over the Internet.

I made changes in CGWatcher and CGRemote that should allow UNC paths. I'll release the CGWatcher update today, but since it's a minor update it won't trigger the auto-update (unless you use the "Include beta builds when checking for and auto-updating CGWatcher" option in the Settings -> Updates tab.)

I am trying to get a CGRemote update released before the Bitcoin conference in Miami (Jan 25-26).

I've just made changes that should fix any problems with UNC paths, so the next update should work correctly with these.

This is the main/official thread... I just created a newbie thread back when I was a newbie and kept it so anyone else new to the forum could get help.




If you can send me a debug report (go to Tests tab and click Create Debug Report button) and the file called cgwatcher.log from your CGWatcher folder I'll try to find what is going wrong.




I'm unable to reproduce this problem in Windows 7 and Windows 8.1. If you also can send me cgwatcher.log from your CGWatcher folder I may be able to find errors that occurred and caused this. I would normally say to make sure CGWatcher is able to write to the folder where the config file is located, but running as Administrator should have fixed that... to be clear you're not storing config files in any of the following?:

C:\Program Files
C:\Program Files (x86)
C:\ProgramData
C:\Windows
C:\Users\<username>\Desktop

Is it Kaspersky? If your antivirus software flags CGWatcher I encourage you to submit a false-positive report to your antivirus software's creator. This involves providing all files to them so they can check them out, and they'll contact you when finished and confirm it was a false-positive. Kaspersky only whitelists specific versions, so even the slightest change in an update means the false-positive comes back. CGWatcher is an unobfuscated .NET application, meaning it is not very difficult for other developers to see what it is or isn't doing. .NET applications can be decompiled rather easily compared to other types of applications.

Edit: by the way, I realize you were just bringing this to my attention and not accusing me of writing anything malicious. I appreciate that. If I came off defensive it wasn't my intention... just trying to show that it would be easy to spot if it was doing something bad.

Not CGWatcher... it is designed to run on the same computer as the miner.

You can use CGRemote to control all of your miners remotely.

Yes. CGWatcher is not required, but if you're connecting to a miner that is running CGWatcher you will have many more features available for that miner.



What you're seeing in CGWatcher is the actual share count in terms of shares you submit to the pool. What you're seeing in cgminer is the diff1 equivalent of these shares. To see this in CGWatcher, go to Settings tab, and then the Display sub-tab. Change the share counts from "Actual" to "Diff1" and click Save Settings.

There is a known issue with Windows 8/8.1 not launching CGWatcher even though it is correctly added to the registry or startup folder. The temporary workaround is to create a batch file that launches CGWatcher, and place the batch file in your startup folder. In a future update CGWatcher will do this automatically for Windows 8 computers.

Gelbstich: CGWatcher is designed to ensure mining stays running... not improve mining performance. However, there are many monitoring options that allow you to set thresholds that if not met, will take the action you specify.

If you're using AMD cards, CGWatcher doesn't disable them due to overheat - it leaves this to the miner. The only part where CGWatcher steps in for AMD cards is that when the miner does disable a GPU due to overheating, it is usually unsuccessful when it tries to re-enable it. So CGWatcher will try to detect when this happens and restart the GPU. I'm not sure where "dead" and "rest" come from... when CGWatcher detects that the miner has disabled a GPU it will list it as "disabled". If it is saying "rest" this is new to me so perhaps newer versions of cgminer/bfgminer handle this differently. I cannot immediately keep up with every change cgminer and bfgminer make. For Nvidia cards, the miners do not detect things like temperature, so CGWatcher does this. CGWatcher's overheat protection for these cards is to throttle intensity until they cool, or disable if they exceed temp-cutoff.

As for your GPU's performance dropping, there are monitoring options that would detect this and restart the miner when this occurs. Perhaps the readme would be a good place to start rather than coming to this thread just to post how pointless this software is... which, by the way, is now running on 45000+ computers. Apparently some people find it useful.


fruor: Sorry, this information is not something that is currently available in CGWatcher. You could possibly try to use the time logged to a specific block, but I don't think it will be 100% accurate. It's something I'll add to the to-do list, which at this point needs to be separated into chapters... so I cannot promise how soon I'll be able to get to it.


Octopuss: Yes, there will be a one-time price for the CGRemote desktop application. It will be at or above the current minimum donation required to join the beta. In other words, it will only cost more once it is released. The idea was not to charge for early access, but to give a discount to those who donated before it was finished and am trusting that I will finish it. Anyone participating in the beta will get the released product free for up to 5 miners. There will be a small fee if additional miners or instances are needed. (Instances meaning you need to run multiple instances at the same time from the same account).

CGRemote has received very positive feedback and I feel that the ultimate price will be more than fair considering what it is/will be capable of.

kimocoin: Thanks

Yes, this is CGWatcher. Specifically it is the library CGWatcher uses to get hardware information. If I remember correctly, I have to open, retrieve hardware info, then close... otherwise it interferes with the miner if I just leave it open.

bitlynx: You found it. I had set it so that scheduled actions would not run between the launch of CGWatcher and the auto-launch of the miner. This idea wasn't the problem.. it's that it wasn't correctly setting the flag saying the miner had been launched.

The log thing is a good idea and is something I've done in CGRemote. (By the way, if you're not already participating in the beta and would like to, send me an email and I'll add you as a way of saying thanks for solving this.) Someone else had just requested an option to disable logging because it was preventing the hard drive from turning off... so as soon as I get some time I'll revamp the logging in CGWatcher.

Version 1.3.5 is now available and should solve the scheduling problem. Thanks again.

Have you set CGWatcher to use your batch file instead of pointing it to the executable to ensure all of the same settings are carried over? Once the miner is running, there is nothing that CGWatcher does other than request information via api from the miner. I don't believe CGWatcher uses enough resources to warrant a drop in hashrate... this is a relatively small amount of information and it happens instantly.

I suggest closing CGWatcher and launching the miner using your batch file. Wait about 10 minutes to ensure the hashrate has stabilized, then open CGWatcher. It should detect the miner and begin monitoring it. Watch for a change in hashrate once CGWatcher is running.

You can always go to the Tests tab and in the Debug Reports & Utilities drop-down list (middle of the window), select "Show last miner start configuration" and click Run. This will show you your original config settings and the exact settings used to launch the miner. If there are any differences, other than CGWatcher enabling the API and perhaps a couple additional settings listed but set to their default values, let me know.

The number of computers CGWatcher is running on displayed at cgwatcher.com is accurate and updated in real time. Out of the 43,000+ computers it is running on, only a handful of times has someone suggested it is affecting hashrate. This was almost always due to CGWatcher using the default gpu-threads value of 2, as was stated the default in cgminer's readme when it would actually run at 1 if not specified. I see this isn't the case here because you are setting gpu-threads to 2... but I'm sure there is an explanation somewhere.

Please try this test build: http://bit.ly/cgw134test

I'm not sure that it will fix the problem but it should provide more info in the log. A few users have reported this but I was unable to reproduce it... even creating the same actions that others were having problems with ran fine on my computer. So if you can email me the log after actions are skipped I'll hopefully be able to see what is going wrong and what conditions are causing it.

Thanks for the feedback.

If you think it is due to CGWatcher merely running you can easily test this by launching the miner with CGWatcher closed, wait five or ten minutes for the hashrate to stabilize, then open CGWatcher and see if the hashrate drops. To date, any time someone reports a lower hashrate using CGWatcher it has been due to gpu-threads. Yeah I see it now in your post... I had scanned through it looking for gpu-threads and forgot about -g.

The only reason you'd have a different hashrate with or without CGWatcher then is a config setting. You can see the exact config settings CGWatcher used the last time it launched the miner by going to the Tests tab. In the Debug Reports & Utilities drop-down (middle of the window), select "Show last miner start configuration" and click Run. It will show the original config settings and the used config settings. It shouldn't change any, but it may add some, like enabling the API. If you find anything different that shouldn't be, please let me know.

Also, obviously make sure you're using the latest version as it may have bug fixes or improvements over older versions. The latest is 1.3.4.6, but I also have a test build you could try here: http://bit.ly/cgw134test