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

[HardwarePal]

I paid $25 for a product that doesnt work 90% of the time and shares my hashrate.
People beware.

[1714906525]

1714906525

[milone]

Mylo:  It is impossible for a program in Windows to delete itself. It would get an "Access Denied" error because the program would be in use. I don't understand what the donation strings have to do with it. CGWatcher and CGRemote have similar online files they use to check for updates and in CGWatcher's case, update pool workers for any users that choose to enable donation mining (which is completely optional, and disabled by default). Much of this code was copied from CGWatcher to save time, which is why there are donation worker strings in CGRemote. I've been working on updates for both programs, but I'm going to go through and remove any reference to donation workers in CGRemote if that will provide any reassurance. I don't require or perform any "hidden" donation mining in CGWatcher - a free program that's been run on over 100,000 computers... so why would I try to do it in CGRemote - a program users have paid for with a smaller user base? Not that I would do it regardless, but I'm trying to point out the logic doesn't even make sense. CGRemote reads a file online that contains information about versions, and this file is where the donation workers were listed. CGWatcher has a similar copy you can read at http://pastebin.com/d10euYAM. I don't publish the URL for CGRemote's, because when the auto-update feature is enabled it contains the URL of the new version's files. But the traffic isn't encrypted, so it wouldn't be difficult to find. I admit that I am guilty of copying and pasting code if it means getting things done quicker, which is why the donation workers were ever in CGRemote to begin with. But there was no code that would actually enable donation mining... it was just a collection of strings.

I'm working on a CGRemote update now... as I am every other day... so I want to understand the problem you're describing so I can try to fix it in this next update. But it is impossible for CGRemote to delete itself. There is no code for it to do this, and even if there was it wouldn't work. You're also the only one out of a moderately large user base reporting this is happening. The deletion of an executable sounds like antivirus software, but I can only take your word that you don't have any disabled. If you can describe to me step-by-step how to reproduce this behavior, I'll spend as much time as is necessary figuring out what is happening. You can post it here, on our support forum (http://www.coinmyne.com/support) or email it to me.


HardwarePal: CGRemote is still in beta, which means it may be unstable, have bugs, and be missing features. Most users report very positive feedback and for the number of users in the beta we receive a relatively small amount of bug reports. This next update should improve stability, which admittedly is something that has been reported by several users, but it is difficult to troubleshoot in some cases because the issues are occurring outside of CGRemote (rather part of the .NET framework). I've been looking into alternative methods for thread management, which seems to be the cause of instability for some users. The next update has been delayed a week because of a new feature we decided to include in this update that will be very helpful to those monitoring more than one miner, but it should be available this weekend or Monday at the latest. I still continue to put a lot of time into CGWatcher, a program that is given away for free and has received very little in way of donations... so you can bet I will work even harder for a program that users are paying for. Thank you for purchasing CGRemote, and I assure you I am working every day, 7 days a week, on improving stability, fixing bugs, and adding features. I appreciate your patience until this next update is out. If it does not resolve your stability issues please let me know immediately.

Edit: What do you mean by "shares my hashrate"? Where is your hashrate being shared?

[milone]

Version 1.3.6 is now available. Most significant changes:

• Fix CPU priority settings when using a batch file.
• Added vertminer to known miner names
• New 'Startup Batch file' option added for setting CGWatcher to start with Windows. This is recommended for Windows 8/8.1 where the other settings have known issues.
• Monitor setting to set maximum hashrate threshold
• New start mining failure option to restart computer if failed starts exceed threshold.
• New start mining failure option to send email to default email address.
• Remove scrypt settings when miner is sgminer.
• Default gpu-thread value of 2 can now be disabled in Settings -> Miner tab.
• Xintensity,rawintensity, and cl-filename settings support added (no longer under Misc. Options)
• New troubleshoot mode setting will help start miner in such a way that it is easier to see errors and debug info.
• Force close other programs on computer restart setting in Settings -> CGWatcher
• Fixed Windows startup entries not being removed when changed to a different method.
• Startup entries now given identifiers in filename so in cases of multiple instances, one doesn't overwrite the other.
• Experimental increase/decrease text size is now a setting in Settings -> Display and persists through restarts.
• Coin 'never remove' flag and 'adjustment' field can now be imported from CGRemote during coin updates.
• Additional fields available for edit in Coin Manager.
• Additional support for VertMiner
• Email settings tab added, setting for default email address for use in notifications where email is not specified.

[Wipeout2097]

I'd like to have a way to dump a screenshot to disk,  for example when a GPU becomes Dead. Is there any way with CGWatcher to do this?

Thanks!

[milone]

Yeah, in fact this code already exists for capturing a screenshot and sending to CGRemote. I'll just have to add it as an action to the scheduler. The sick or dead devices event is already there, so you'd just create a scheduled action to save a screenshot when event occurs: sick or dead device detected.

Thanks for the feedback... I'll get this in the next update.

[Wipeout2097]

Yeah, in fact this code already exists for capturing a screenshot and sending to CGRemote. I'll just have to add it as an action to the scheduler. The sick or dead devices event is already there, so you'd just create a scheduled action to save a screenshot when event occurs: sick or dead device detected.

Thanks for the feedback... I'll get this in the next update.

Oh, thanks man. I looked into running an external program on scheduled action and so on, but your update will be great. Cheers.

[mdopro1]

I just bought CGRemote, had a little hard time getting APIs running properly but that's because of my limited knowledge of how API work.

Software is amazing so far!

I'm wondering if the software can issue a notification of any kind (sound, visual) when a round ends on my current pool. Is that something CGRemote can do?

[milone]

I just bought CGRemote, had a little hard time getting APIs running properly but that's because of my limited knowledge of how API work.

Software is amazing so far!

I'm wondering if the software can issue a notification of any kind (sound, visual) when a round ends on my current pool. Is that something CGRemote can do?

Thanks... I've been working very hard on this next update and I think everyone will really like the new features and improved stability.

While there are plans to provide audio and visual notifications (along with email), there are no plans right now to implement anything pool-specific. Writing support for individual pools would be very time consuming, not to mention there are are new pools popping up every week so it would be endless. If the rounds are just based on time, it would be possible for the user to sync a timer in CGRemote with the pool's round, and then notifications could be triggered based on that timer. If you have any suggestions on how to make this work without having to poll the pool, let me know. I'm not against writing pool-specific stuff in the future, but there are too many things to do before I could get to that. I just try to avoid it because it relying on pools is not something I've had great experiences with.

[mcofko]

Hey, I've installed the new version of cgWatcher and must say that I love some new features that you implemented/added. But, I have one problem with new version, each graphic card is producing in avg. 100KH/s less then with previous version 1.3.5. With three cards is this 300Kh/s less. I'm running the same config file on the same mining pool, and I'm running my cgwatcher in Win8. Do you now what could be the reason for this problems?

[milone]

I haven't really changed much in this update that should affect config settings, other than making the "gpu-threads" default value of 2 optional (in Settings -> Miner tab).

If you go to the Tests tab and locate the Utilities section, select "Show last miner start configuration" and click Run. You can email me this info or post it here (you can remove any worker names/passwords if you wish), and I'll look for any differences that should not be there. This report shows your config settings vs. the config settings CGWatcher used when launching the miner. In most cases they're identical, but maybe a small difference could be causing this.

[atchoum6760]

Hi !

I have 2 R9 270 X and when i use cgwatcher just one card start the card number 2 don't start why ?

THX

[chup]

Cgwatcher is reporting config file problem when following sequence appears:

Code:

"scan" : [
	"noauto",
	"dualminer:all",
	"gridseed:all",
	"opencl:auto"
],
"set-device" : [
	"dualminer:clock=800",
	"gridseed:clock=850"
]

Last version of Bfgminer works with mentioned lists, cgwatcher not. I was trying to edit config file with config editor and to check "not validate" the file, but error on saving settings still persists and config file is not accepted. Workaround not so elegant is to remove from config and put the same instructions in arguments line.

[milone]

Hi !

I have 2 R9 270 X and when i use cgwatcher just one card start the card number 2 don't start why ?

THX

Can you start the miner using CGWatcher, wait a minute or two until the miner is running and CGWatcher is monitoring it, then go to the Tests tab and locate the Utilities section in the middle... then select "Show last miner start configuration" and click Run... then email me the results? If it is a problem with a setting, this report should show it.

Cgwatcher is reporting config file problem when following sequence appears:

Code:

"scan" : [
	"noauto",
	"dualminer:all",
	"gridseed:all",
	"opencl:auto"
],
"set-device" : [
	"dualminer:clock=800",
	"gridseed:clock=850"
]

Last version of Bfgminer works with mentioned lists, cgwatcher not. I was trying to edit config file with config editor and to check "not validate" the file, but error on saving settings still persists and config file is not accepted. Workaround not so elegant is to remove from config and put the same instructions in arguments line.

I still have to add support for these multi-value settings. Right now it is designed to accept a string of text for these particular settings, so when it gets a collection of strings it breaks. As you've discovered, the temporary solution is to set these in arguments. You can still use the rest of the config file, but any time you're listing multiple values for a setting it has to be done in arguments currently. I'll definitely work on fixing this.

[sapstar]

Hi, Since the recent update, I am seeing incorrect hash values for the current hash rate. This shows correctly in SGminer. I am using SGminer 4.1 with lantis bins. Is this a bug or am I doing something wrong?

http://i.snag.gy/lbXJ5.jpg

[milone]

Hi, Since the recent update, I am seeing incorrect hash values for the current hash rate. This shows correctly in SGminer. I am using SGminer 4.1 with lantis bins. Is this a bug or am I doing something wrong?

Can you create a debug report (go to Tests tab, click Create Debug Report button) and email it to me? You can remove any pool worker names/passwords that might be in there if you'd like (I think it includes config settings towards the bottom). Make sure to create this report while the miner is running and while the incorrect hashrate is shown. Thanks..

[sapstar]

Can you create a debug report (go to Tests tab, click Create Debug Report button) and email it to me? You can remove any pool worker names/passwords that might be in there if you'd like (I think it includes config settings towards the bottom). Make sure to create this report while the miner is running and while the incorrect hashrate is shown. Thanks..

Hi Milone, Just emailed you the defect report.

[sapstar]

Just realised that the graphs under the hash rate also don't work. I have 5 gpu's, but stats are not shown.

http://pasteboard.co/1L7XUPWg.png

[jollyriffic]

this program is not very user friendly.
tried to make changes and trying to figure it out is such a pain.

[milone]

sapstar: I replied to your email. I'll also post here in case anyone else having a similar problem reads this. Nothing worse than finding someone with the same problem with you on a forum and then never finding the solution.

You need to fix or correct the GPU map inside of CGWatcher. You can do this by clicking "Incorrect hashrate for this GPU?" under the Average Hashrate in the GPU tab. It looks like a map was already created at one point for 4 GPUs. Note that this is the same idea as the "gpu-map" setting in cgminer, but CGWatcher has its own internal mapping. When you click the "Incorrect hashrate for this GPU?" link, it will open the GPU Map window, where you match detected GPUs (ADL) to their correct hashrates (OpenCL). You can also clear the existing map (Clear Map button... this will not clear cgminer's "gpu-map" setting, only CGWatcher's mapping) and see if this is enough for CGWatcher to match ADL to OpenCL devices - but if not you may have to map them yourself. Usually CGWatcher is pretty good at doing this, but in this case you're mapping GPUs with the "gpu-map" setting in cgminer and this can cause it to mis-map them sometimes. Once you do this the GPUs should start being reported correctly.


jollyriffic: I'm sorry, when I created it, things were a lot different and it has since grown into a monster larger than I ever imagined. If I were to do it again, there are definitely design changes I'd make... but adding improvements and new features left no time to redesign it. I'm hoping I got it better in CGRemote. And maybe down the road I'll have some time to redesign CGWatcher to be more user-friendly.

If you have specific questions on how to do something, feel free to ask or post them in our support forum at http://www.coinmyne.com/support.

[sapstar]

sapstar: I replied to your email. I'll also post here in case anyone else having a similar problem reads this. Nothing worse than finding someone with the same problem with you on a forum and then never finding the solution.

You need to fix or correct the GPU map inside of CGWatcher. You can do this by clicking "Incorrect hashrate for this GPU?" under the Average Hashrate in the GPU tab. It looks like a map was already created at one point for 4 GPUs. Note that this is the same idea as the "gpu-map" setting in cgminer, but CGWatcher has its own internal mapping. When you click the "Incorrect hashrate for this GPU?" link, it will open the GPU Map window, where you match detected GPUs (ADL) to their correct hashrates (OpenCL). You can also clear the existing map (Clear Map button... this will not clear cgminer's "gpu-map" setting, only CGWatcher's mapping) and see if this is enough for CGWatcher to match ADL to OpenCL devices - but if not you may have to map them yourself. Usually CGWatcher is pretty good at doing this, but in this case you're mapping GPUs with the "gpu-map" setting in cgminer and this can cause it to mis-map them sometimes. Once you do this the GPUs should start being reported correctly.

Thanks very much for the info Milone. Now I know what caused the issue. It has been a coincidence that I have added a GPU after the update. I think that caused the gpu-map incorrect.