Topic: CGWatcher 1.4.0, a GUI/monitor for CGMiner & BFGMiner to help minimize downtime - page 20. (Read 402339 times)

I didn't know that I shouldn't use the desktop to store the miner or cgwatcher. That might have caused the issue. I will place them in their own folders on C: and see if that resolves anything.

I didn't find ProfilesDatapath or VariablesDatapath but I did find the following below:

ProfilesDataFile=
VariablesDataFile=

Both these entries were blank. Normal or no? The only version of cgwatcher I have used is the latest one available on your webpage, so I don't think that previous version handling is an issue.

UPDATE: I tried the same scenerio after moving the file locations outside the desktop, but still same result.

Something interesting though: When I realize that cgwatcher failed to start up the miner, I plug up the monitor and I see the cgwatcher splash startup screen. It did not get to the actual program window. The logs show the same thing as before, begin cgwatcher process, but only starts up the profile after I plug up the monitor.

Can you email me your cgwatcher.log file? It should have debug log entries that will hopefully show what was happening, because aside from a failing hard drive there is nothing that should cause 26 minutes to pass in between the first and second log entries. Also go to the Tests tab and click Create Debug Report, and include that in the email as well.

If there was a problem with profiles loading, check the ProfilesDataPath setting in CGWatcher.exe.ini and make sure it is pointing to the correct location. There were issues with this that were fixed in 1.3.1, but if the setting was set incorrectly by a previous version you'll have to either manually correct it or delete CGWatcher.exe.ini to have a new one generated when you start CGWatcher. This is also true of the VariablesDataPath setting in the ini file, which works the same way and had the same issue from previous versions.

Also don't use folders on the desktop to store CGWatcher or the miner folder, as Windows treats the desktop a little differently than normal folders and permission issues seem to creep up. I recommend creating a folder like C:\Mining to hold all mining-related stuff (so C:\Mining\cgminer, C:\Mining\CGWatcher, etc.)

Whether the monitor is plugged in or not should not have any effect on CGWatcher. But I can't say for sure what is going wrong without more information.

Hello!

First I wanted to say awesome program, you really have put your heart to the code.

I have a problem though. I have a headless PC that I am mining with. I hooked up my monitor to the PC and configured my cgminer and cgwatcher to my liking, shut down the system, unplugged my monitor, and powered the system on. I have cgwatcher to startup with windows so my rig should have automatically started mining.

It didn't.

Here is the log for that instance:

[9/12/2013 10:31:25 AM]      -- Begin CGWatcher v1.3.1.0 Process -------------------------------------------------------
[9/12/2013 10:57:17 AM]      Active profile is "Default"
[9/12/2013 10:57:17 AM]      No CGMiner instance found.
[9/12/2013 10:57:17 AM]      Preparing to launch CGMiner in 10 second(s)...
[9/12/2013 10:57:18 AM]      Monitoring is turned on at 10 second intervals.

I shutdown the computer at 10:30 AM, and it appears that the system booted up properly and started cgwatcher. But as you can see on the second log line, it didn't activate any profile and did not start cgminer automatically. I was watching my pool statistics on another computer and noticed that it didn't start up. At 10:56 I go and plug up the monitor to see what is going on and as soon as I see the desktop cgwatcher starts doing its thing normally.

That happened today. Yesterday, same problem, little different situation:

I make sure that cgminer is running and cgwatcher is monitoring properly, then I unplug the monitor and leave it be. It mines successfully for 3 hours. Then it drops off. I have cgwatcher to automatically restart the miner after 3 consecutive hours of mining. This happened overnight, so I hook up the monitor and check the log and it gives me exactly the same thing that happened above: "Begin CGWatcher v1.3.1.0 Process", then after I plug up the monitor (about 14 hours later) the next log line tells me "Active profile is Default".

Maybe cgwatcher does not begin loading a profile or scan for cgminer without a monitor plugged in?

Thanks, I'll look into this. It looks like a memory leak, but I didn't see anything obvious after (quickly) looking at the code. If you can send me a cgwatcher.log from one of these computers, that might make it easier to see what is happening... specifically how many times it tried to restart the miner. I do check for memory leaks often but this particular scenario where it constantly restarts the miner for 15+ minutes is not one I've tested.

hi milone,
i had a few instances of this error:


what happen was, when i had a disconnection from the internet for 15mins+ the error occurs, out of the 30rigs i have,i usually found 3-4 rigs having this errors (same spec).

New in version 1.3.1

• Add bitburner code/name to default mining devices.
• Improved automatic API enabling to fix issues with api-allow option being modified incorrectly and locking out other API monitoring applications.
• Thread sync locking on remote socket collection handling.
• Fix default profiles and variables file paths being saved to CGWatcher.exe.ini which caused profiles and variables to not save correctly if the CGWatcher folder was moved or copied to another location because the paths would still point to the original location. These are now left blank unless you change them manually to non-default paths.
• CGRemote file explorer commands expanded to allow full directory navigation, file copy, file info, and existing commands improved.
• CGRemote commands to add, modify, and delete profiles improved.
• Ads may be displayed occasionally (30 seconds per hour, can be closed by clicking X) on CGWatcher's main window with the exception of donation miners. If you want to advertise your latest pool/asic/alt-coin or ask that one bitcoin mining girl out, do it with a 468x60 banner in CGWatcher
• Update and version data backup sites added to (hopefully) get around the main site being blocked in certain countries.
• Pool elapsed time now recorded per pool, available in the Pools tab and Report tab. Also includes a percentage to see which pools were used and how much.
• Remote options window created to provide additional options for CGRemote in the future, and allow for setting a default miner path (which defaults to your most-used miner executable) to use with global profiles.
• Several other improvements (I lost track at some point).

That works perfectly, thank you.

It's not that CGWatcher takes "priority", as normally there is no problem using other API-monitoring applications while CGWatcher is running. But there was a problem with recent versions of CGWatcher not enabling the API correctly. This is fixed in 1.3.1, which will be available shortly (today or tomorrow).

Until then, there is a workaround that should prevent this. You just have to make sure that you enable the API in arguments, and include 127.0.0.1 in the full privilege group (W:).

So in the profile arguments, make sure there is a setting:  --api-allow W:127.0.0.1

Because of the bug, this has to be done in arguments because the arguments api-allow option will override the config file api-allow option (if one is used). Once CGWatcher sees that 127.0.0.1 is already included in the W: group, it should leave the setting untouched.

In 1.3.1, this is corrected and the code for checking if the API is enabled and enabling it is now a little smarter.

Hey guys,

Not sure if this has been covered or not, is there a way to stop CGWatcher taking full priority on the API?

I cannot connect to the API with other items when it's in use, and it would certainly be nice to!

Any ideas?

I'm on the version before the latest if that helps?

Thanks

p.s. For example if I'm using PiMiner to show stats on an LCD display, or using AnubisApp to connect, I get the following:

Connection to 192.168.0.211:4028 failed: 'An existing connection was forcibly closed by the remote host. '


This only happens when ran in conjuction with CGWatcher running, so I presume CGwatcher is taking "priority" access or something.

I've added an option that will be available in the next CGWatcher update to select whether you want it to show actual share counts or diff1 share counts for accepted, rejected, and stale. Regardless of which you choose, the percentages should now be (more) accurate. But if you choose to show actual share counts (as it currently does), the hw errors count may be disproportional to the other share counts because it is always diff1 (from what I understand). However, the hw errors percentage will be more accurate (by taking the fact it is diff1 into consideration.) Recent cgminer API updates include some percentage values, but from testing it seems we're calculating the same numbers and getting the same results so I will continue to calculate myself to accommodate older versions (and possibly bfgminer, which may or may not have added this to the API).

With shares higher than diff1, the numbers may not actually add up perfectly as is stated in the cgminer readme. They should be reasonably close though, so if you wish to see what your share counts look like as diff1 shares, you now have that option. As with any new feature or change, if you experience any issues when using this option please let me know.

The next update should be within the next few days.

I don't think this is anything to worry about, but you may want to ask on the cgminer thread or at least post what cgminer is logging when these errors occur. You can also add 2>log.txt to the arguments to have cgminer output its log to a file called log.txt so you can go back and check later.

Because of the hashrate, your single is going to have higher difficulty shares, and the accepted/rejected numbers are going to be shown without regard to share difficulty. Hardware errors are the equivalent of diff1 shares, so the percentage in your case is going to be off. I'm not sure how I'm going to adjust for this, I haven't given it much thought yet.

So if you're running diff4 shares, your accepted/rejected share counts would need to be multiplied by 4 to be in proportion to your (diff1) HW error count. The problem is your share difficulty may change often so it isn't just a matter of multiplying by it.

That is how I understand it. If I'm incorrect hopefully someone will correct me.

More info:
https://forums.butterflylabs.com/jalapeno-single-sc-support/3059-hw-error-rate-jalapeno-3.html

I'm currently running cgwatcher 1.3.0.2 on cgminer 3.3.4. here's some of the output
 Mining duration.................. 24 hrs, 12 min, 31 sec
 Current total hashrate........... 62.55264 Gh/s
 Current average hashrate......... 62.53938 Gh/s
 Accepted shares.................. 38984
 Rejected shares.................. 184
 Stale shares..................... 0
 Discarded work................... 6283
 Local work....................... 1663309
 Getworks......................... 3224
 Getwork failures................. 0
 Hardware Errors.................. 9160

I've tried everything I can think of to reduce the hardware errors 19% seems a little high. I've direct connect to modem, reboot modem, direct connect to pc via usb (as opposed to using an active usb extension), changed pools, switched to bfgminer (although i'm not certain I'm comparing apples to apples with their errors), reinstalled zadig and reinstalled the drivers for the single...and that's about all I could think to do. I don't know what's acceptable or really what the hardware errors even mean. Is this something I should take to BFL? I don't see anything goofy in the miner.log


[8/28/2013 7:59:12 AM]  CGMiner (3196): Process found; started at 8/28/2013 7:52:56 AM using "Default" profile on port 4028.
[8/28/2013 7:59:12 AM]  CGMiner (3196): Pool 0 ( pool ) status is ALIVE
[8/28/2013 7:59:12 AM]  CGMiner (3196): Current pool is Pool 0 (pool )
[8/28/2013 7:59:12 AM]  CGMiner (3196): Network difficulty is now 65,750,060.
[8/28/2013 7:59:17 AM]  CGMiner (3196): GPU0 (ATI Radeon HD 4800 Series) status is UNKNOWN
[8/28/2013 7:59:17 AM]  CGMiner (3196): BAS0 status is ALIVE

I was thinking maybe it had something to do with using the NoGPU exe of cgminer but even with the regular binary I still can't get below 15% error rate. Any suggestions? And, milone, if you have any ideas you might consider putting a threshold in to the watcher. If your error rate is above X (commonly acceptable percentage) suggest some changes or diagnostics to get that number down to an acceptable level. If that can even be done. I just know when I see that big red number of hardware errors I want to click on it and find out what the problem is.

Any advice would be appreciated. It seems like this number should concern me but maybe I just don't quite understand what I'm seeing.

Thanks, I've fixed this for the next update. Until then, it should only happen if one of the hashrate values (sha256 or scrypt) is set to zero, so as long as they're both at least 1 it should not disable it.

milone, i found a minor bug in 1.3.0.2

one of the setting in the monitor tab isnt saving properly. here's how to reproduce:
1. go to monitor tab
2. check the "if hashrate fall below .... dont forget to specify the sha/scrypt value"
3. then save settings
4. restart cgwatcher
5. go to monitor tab, the check become unchecked.

api-listen was already enabled.
forgot to mention, I love the program regardless of problems getting it to work.
(will make a lot easier switching mining pools and coins)

Please update cgwatcher to 1.3.0.2., and let me know if that does not fix these problems. The crashing should be fixed, and there were improvements and fixes to how the miner is started.

Just installed v1.2.9 this past weekend. I'm getting the below error in my event log after CGWatcher has periodically crashed. Usually happens within 60 seconds of cgminer crashing. Any ideas?




Log Name:      Application
Source:        .NET Runtime
Date:          8/26/2013 11:30:39 PM
Event ID:      1026
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      rig1
Description:
Application: CGWatcher.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.AccessViolationException
Stack:
   at PInvokeDelegateFactoryInternalWrapperType4.ADL_Adapter_ID_Get(Int32, Int32 ByRef)
   at PInvokeDelegateFactoryInternalWrapperType4.ADL_Adapter_ID_Get(Int32, Int32 ByRef)
   at OpenHardwareMonitor.Hardware.ATI.ADL.ADL_Adapter_ID_Get(Int32, Int32 ByRef)
   at OpenHardwareMonitor.Hardware.ATI.ATIGroup..ctor(OpenHardwareMonitor.Hardware.ISettings)
   at OpenHardwareMonitor.Hardware.Computer.Open()
   at CGWatcher.Hardware.HardwareModule.Open()
   at CGWatcher.Hardware.HardwareModule.Refresh()
   at CGWatcher.frmMain.workerHardware_DoWork(System.Object, System.ComponentModel.DoWorkEventArgs)
   at System.ComponentModel.BackgroundWorker.WorkerThreadStart(System.Object)
   at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr, System.Object[], System.Object, System.Object[] ByRef)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(System.Runtime.Remoting.Messaging.IMessage, System.Runtime.Remoting.Messaging.IMessageSink)
   at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem .ExecuteWorkItem()
   at System.Threading.ThreadPoolWorkQueue.Dispatch()

Event Xml:
http://schemas.microsoft.com/win/2004/08/events/event">
 
   
    1026
    2
    0
    0x80000000000000
   
    287
    Application
    rig1
   
 
 
    Application: CGWatcher.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.AccessViolationException
Stack:
   at PInvokeDelegateFactoryInternalWrapperType4.ADL_Adapter_ID_Get(Int32, Int32 ByRef)
   at PInvokeDelegateFactoryInternalWrapperType4.ADL_Adapter_ID_Get(Int32, Int32 ByRef)
   at OpenHardwareMonitor.Hardware.ATI.ADL.ADL_Adapter_ID_Get(Int32, Int32 ByRef)
   at OpenHardwareMonitor.Hardware.ATI.ATIGroup..ctor(OpenHardwareMonitor.Hardware.ISettings)
   at OpenHardwareMonitor.Hardware.Computer.Open()
   at CGWatcher.Hardware.HardwareModule.Open()
   at CGWatcher.Hardware.HardwareModule.Refresh()
   at CGWatcher.frmMain.workerHardware_DoWork(System.Object, System.ComponentModel.DoWorkEventArgs)
   at System.ComponentModel.BackgroundWorker.WorkerThreadStart(System.Object)
   at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr, System.Object[], System.Object, System.Object[] ByRef)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(System.Runtime.Remoting.Messaging.IMessage, System.Runtime.Remoting.Messaging.IMessageSink)
   at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem .ExecuteWorkItem()
   at System.Threading.ThreadPoolWorkQueue.Dispatch()

 

I try not to change the version number unless a significant fix was made, and in this case there were two.

These bugs must be coming in through an open window.