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

It's a heuristic false positive that only happens with kaspersky (heuristic meaning it didn't find malicious code, it is just making a poorly-educated guess based on some characteristics.) I've sent false positive reports and they admit it's a false positive and correct it for that version, but then if I make any changes at all (like a bug i fixed today) it becomes another false positive. I've asked them how to resolve this, but they haven't answered other than to say a specific version's false positive was corrected. I update too often to go through this every time, so they need to be a little more helpful than whitelisting an md5 or sha hash.

I've posted more info at http://manotechnology.blogspot.com/p/false-positives.html

Upload the files to virustotal.com to see the results from 45+ antivirus scans.

Its just me or TROJAN!?!?

http://imageshack.us/a/img42/8721/urc6.jpg
http://imageshack.us/a/img543/4598/5wbw.jpg

or false positive?

milone, I first found this bug from 1.1.4.1 ...and in other versions, there he is in 1.2.4
OK, I try un-check the Validate before saving.

Thanks, this was a bug related to culture settings. It should be fixed if you download again, if not let me know.

Also, you can un-check the Validate before saving checkbox to skip validation checks before the config file is saved. This will allow you to save config files even if CGWatcher thinks the values are incorrect. But that is a workaround and I'd prefer to fix any bugs causing validation to fail.

Thanks for reporting.

Screeshot error

error occur when I try to open the config file in the Config File Editor.
As I understand CGWatcher ignores the option and does not pass it cgminer, as the voltage is not changed. I change with the help of MSI AB.
My config file:

... what does the error say? And pasting your config file would be helpful. Does the error occur when you start the miner or when you try to open the config file in the Config File Editor? I can't tell you how to fix it with no information.

Also, it's gpu-vddc, although that shouldn't cause an error in CGWatcher - it would just think it's a different option. Having invalid json (incorrect format) will though. The option should be in this format in the config file:


(the comma at the end may need to be removed if this is the last option listed in the config file)

Hello milone!
I can't specify a configuration file voltage(gpu-vvdc 1.050,1.050,1.165,1.165) 4 graphics cards. When checking the config error POPs up. How to fix this?

The easiest way to update is to copy all files in the update archive (CGWatcher-*.*.*.rar) to your existing CGWatcher folder, overwriting any files. This won't affect profiles or configurations because those files are not included in the update (they are created the first time CGWatcher runs if they don't exist.)

If you ever need to revert back to a previous version for some reason (e.g. I break something), you can download all older versions on the download page (or ideally report the problem and I'll fix it and update the download files.)

There is also an auto-update option in the latest versions of CGWatcher. I'm currently trying to find a better (more reliable) hosting option for the files but in a worst case scenario if the host is down it just won't update itself until it's back up. After the updater downloads any necessary files successfully, it will close CGWatcher and re-open it using the new version to complete the process.

As soon as CGRemote is released and I get back to CGWatcher, I'll look more into cpu affinity options. I didn't expect this would have a noticeable effect on gpu/fpga/asic mining since cpu usage in cgminer is typically very low, but admittedly I hadn't put much thought or testing into it. I'm open to adding any options that may improve hashrates. In case you're not aware, you can set profiles to use a batch file instead of the executable. This would ensure that if CGWatcher ever restarts the miner, it uses the same settings as you're using now by launching a batch file outside of CGWatcher because any time it restarts a profile that uses a batch file, it closes the miner and re-launches the batch file to make sure all settings are applied. Just set the Miner Path in the Profile Manager window to the batch file. Arguments from the batch file will be loaded automatically into the Arguments textbox and if you make any changes to the arguments it will save them back into the batch file. Having the "start /REALTIME" option or other lines (e.g. setx) will not cause a problem and these aren't modified or removed when saving arguments to the batch file. (If browsing for a batch file, you may need to change the filter drop-down to "Batch and Command files" in the bottom right corner of the Browse window. I'll probably change this to show miner executables and batch files together in the future.)

I really appreciate CGMiner but I have not been able to keep up updating my Miners with each new release.

-What is the best way to carry over profiles and setting from previous to new version ?  ( I currently copy over the profiles.dat from the previous version over-writing the empty profiles.dat created by the newer version)


In the features dept, I still use manual batch files to launch my cgminer with the API access enabled then I start cgwatcher. ON different PC's for example I have noticed that Semptron 145 single core will yeild better hash rates with the Process REALTIME  priority  ( ie  start /REALTIME cgminer.exe )

On a system with multiple cores I will often bind cgminer  (ie start /AFFINITY 01  cgminer.exe to a "specific" core).  This way I can use the other cores for other jobs, without seeing CPU load / latency from other process slow down the cgminer hash rates.

It would be interesting to see these feature built in cgminer.

Thank you for the excellent software.

I just started using CGWatcher, and I must say I'm impressed. My CGminer sometimes stalls; I hope CGWatcher will prevent the loss of BTC by automatically restarting CGminer ;-)

Yep, what play described is what was happening. I've now changed the settings to fix it.

Hopefully this is what atariguy is referring to. This will be fixed in the next update.

play, thanks for making this an easy bug fix. If you'd like to participate in the CGRemote beta, PM me your email address. It should start in the next day or two.

On latest version, when you start cgwatcher does launch 2 cgminer. One is from the tick in "Run miner when started" other one is from the option "Ensure miner stays running unless paused or stopped in CGWatcher".

On my rigs I just left the last option and everything else seems fine.

No other reports on two miners starting. In the code that starts the miner, there is only one line that actually launches the miner so I can't imagine how it would happen, but I won't say it's impossible... stranger things have happened. This happens when you are running two instances of CGWatcher? Does it happen when Windows starts or when you press the Start button in CGWatcher?

The best help would be to reproduce this behavior, so do whatever you did that caused two miners to be launched. Then go to the Tests tab in CGWatcher and click the Create Debug Report button. If you are running two instances of CGWatcher it is probably best to do this in both instances. Email the debug reports to my email address in the readme.

I will be updating CGWatcher soon with some changes needed for the CGRemote beta, so if I find it is a bug I'll make sure it is fixed in this next update.

Thanks! At first I had a hard time getting 2 instances of CGWatcher to run, but then I updated to the latest version and that fixed that problem. I've now got it working, but there is one problem. For some reason, CGWatcher launches 2 instances of the mining programs. This happens even when there is only one instance of CGWatcher running. This didn't happen in the older version I had been using, so it's either a new bug or I have something wrong on my end (which could well be the case). Have you had other reports of this?

Nice work milone.

Sorry unpack, I'm not sure what you mean. The download link is via Dropbox. As mentioned in the post and readme, the source has not yet been released so that is why it is not yet on GitHub.

Please provide gitHub ,sourceforge or dropbox.com  download support,Then you always have problems downloading address
Thank you very much

Thanks for the update!

I'm hoping to start the CGRemote beta within a week... (*hoping*, I'd say two weeks at the most but am really shooting for the middle of next week. I'm happy with the framework and the rest of the work now is relatively easy stuff. Until it is ready, updates are being posted to http://manotechnology.blogspot.com/p/cgremote.html