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

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, 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

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.



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.

Cgwatcher is reporting config file problem when following sequence appears:

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.

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

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.

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?

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.

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?

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

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.

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!

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.

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?

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

Yesterday this happened again, then again, why your app keeps deleting .exe file and adding up donation strings in .ini everytime?

Basically your software acts like malware right now, forcing me to donate-hash my rigs for no reason, otherwise it closes and deletes itself.
It is not a problem for me to take a video of this with no antivirus enabled or anything of that sort.

What bothers me most that you actually know what I'm talking about, otherwise your software would not rewrite donation mining strings and leave out the rest as it is.

Needless to say I don't use CGRemote at all "thanks" to aforementioned "feature"

milone its under usb settings for 4.1 and up on cgminer. When I set that like when it kept picking up an unsupported drillbit systems device (new firmware), I went and selected it  and cgwatcher would kill the cgminer and restart with not saving the setting.

I'll keep an eye for the update.

That's very nice milone. Keep up the good work man!

Talking back about .exe self-destroy "feature" I thought you might get me some input on this one, very weird experience indeed.

isriam: 

I think I might have answered you on our support forum but I'll answer here just in case it wasn't you. The problem it is having is with the "scan" setting... change it to:


and it should work correctly.


mylo:

Which .exe is getting deleted? CGRemote doesn't delete any executables. Are you sure it's not your antivirus software deleting it? Also, the next update has several stability improvements and should be available this week.

As for adding and switching pools, I think you'll be happy with the solution I've come up with in this next update. We spent the day testing it and it went pretty well, but I still have a few changes to make. There is also a CGWatcher update that will be released in the next few days that will correct the issue with using variables when adding pools in CGRemote. This has already been fixed in the code. And CGRemote will also provide several new options for adding pools to multiple miners while assigning each miner a unique worker and password. There are also options to save the new pool, regardless of whether or not the miner is running CGWatcher, so adding pools will persist through miner restarts.

I'll also check out the Windows 8 issue. I do a lot of development on Windows 8, but my miners are running Windows 7. We just put a rig together today just for software testing, so it will be useful in getting the Windows 8 problems figured out once I get it loaded. I also bought a USB Block Erupter just so I could mine on my notebook (Windows and try to replicate this problem.

Today was a very productive day... I just need a few more to work out the issues we found. I appreciate the feedback and patience. Please keep in mind CGRemote is still in beta because there are these issues to work out and still a lot to be added. There is no doubt in my mind it will be the best, most complete miner management software available. The features it has now are only the beginning... the ideas we've come up with just in the past week are nothing short of awesome and we're working very hard on getting them implemented as quickly as possible.

Hey milone, thanks for the answer but I got a new bugging thing going on right now.

1) Whenever I start CGRemote, it runs for any number of hours then shuts down itself and DELETES .EXE file. What the actual fuck man?
You are doing great job and all but why this happens every single time? Does it have something to do with scheduled "donation hashing"?

2) I switched all my miners (one by one, can't mass switch) through CGRemote to a new pool but variables do not get written in .conf,
so when the miner restarts for any reason ("Closed outside CG/SGMiner", restarts after N period etc.) all my miners switch to old pool mining undesirable coin (big waste)

I appreciate your input milone and I very much hope to get some reasonable solution for these problem which kinda annoy.
Linux is all cool, Anubis and PHPMiner work fine but I thought your software is much more versatile so I gave it a shot.

Talking back about Windows 8 problem, I have one miner running on it and whenever I add a new pool it gets itself on top of the list no matter where I put it.
I guess it is a write-permission thing and "Running as administrator" doesn't help it either.