Sorry, I took on another project that will last 6-8 weeks, so I will not be able to work on it during that time. My plan was to release 1.1.5 fixing any known problems before starting the new project, and it seems to be working pretty well (I'll still try to fix bugs if they are reported.) So once this project is finished I will be working primarily on CGRemote, but unfortunately my best estimate right now is 2.5 to 3 months.

How is FastCash4Bitcoins.com different from someone posting an ad on Craigslist offering to buy bitcoins? Because it's a company with a website? Is it the TLD that sets them apart? Seriously... if they are a MTB, we are likely all MTBs. Posting a buy order on an exchange is essentially the same thing - offering to buy bitcoins from somebody else.

This is a bad decision made by ignorant officials who are either too dumb or too proud to ask questions and learn about something they know nothing about before making decisions that affect it. If it's because they're worried about getting "their share"... they would have to send warnings to anyone who buys bitcoins from someone else. And if that's the case, they need to start sending warnings to everyone who buys anything from someone else because it is also exchanging fiat currency for something of value... which is all that was happening here. They were not creating or issuing bitcoins; they were just offering to buy something that already existed.

I will be dumbfounded if this decision is not reversed. If these bad decisions are allowed to stand it will set a precedent for future bad decisions regarding bitcoin.

/rant

In CGWatcher you can set cgminer options using a config file or arguments or both. As of cgminer 3.1.1, you could not enable more than one device at a time using the config file. Instead you have to use arguments (-d 0 -d 1) if you wanted to enable devices 0 and 1 for example. This is why the "device" option was taken out of the Config File Editor in 1.1.5, because it doesn't work for more than one device so I didn't want to cause confusion by leaving it in. Instead you just have to set these options as arguments.

So in CGWatcher you can edit your profile to either:

a) point to the .bat file instead of the miner's .exe file as the miner path. To do this, change the filter in the bottom right corner of the dialog from Miner executable to Batch or Command file... or something like that.

b) point to the miner's .exe file as the miner path and set -d 0 -d 1 in the profile's arguments. You can still use a config file or arguments for other options, but enabling specific devices has to be done in arguments.

Kiplingscat: There was a bug in the Config File Editor that caused auto-gpu and auto-fan to default to True. If you set them to False and then saved the config file, it would save correctly. But the next time you opened the config file in Config File Editor, they would default back to True. This may explain the problem you had.

It has been fixed and the download file updated so please download again if you have not already done so.

poohbah: I will edit the setting's text to make this clearer. My thinking was that should there be a problem that was undetected by other checks, a restart at the schedule start time would hopefully resolve it and ensure that the scheduled mining ran properly. Ultimately I'd like to preserve a history of statistics, but there are other things to do first.


digitalindustry: Thanks


Lucko: I did find a problem with .bat or .cmd files that used the 2>log.txt or similar argument. It has been fixed in 1.1.5 and should be available tomorrow. (I said that about last weekend but I got sick so it was delayed.)

You'll still need to use a .bat or .cmd file when using the 2> argument because the .NET process class has a problem with it that I haven't tracked down yet.

It doesn't matter if you don't use a config file if you're using arguments. Arguments inside a .bat or .cmd file will be shown in the CGWatcher Profile Manager window (in the Arguments textbox) so you can easily edit them, and upon saving it will update the .bat or .cmd file with any changes you made. So whether you point to a .exe, .bat, or .cmd file for your miner, you can manage the arguments for it in the Profile Manager window.

GuiltySpark343: This type of information is not recorded in 1.1.4 but there have been requests for things like this so in 1.1.5 there will be a separate log just for miner events. Just keep in mind that exact times may be slightly off by up to the number of seconds you have set as the Monitor interval. (Example, if you have CGWatcher Monitor interval set to 30 seconds, event times may be up to 30 seconds off from when the actual event occurred.) I'm not sure exactly what all events will be recorded, but if you have any suggestions/requests, please let me know. The miner also has a logging option, using 2>logfile.txt where it will write its log to logfile.txt, but setting this argument in CGWatcher seems to cause an error starting the miner so you'd have to create a .bat or .cmd file that launches "cgminer.exe 2>logfile.txt", then point CGWatcher to the .bat or .cmd file for now until I figure out what is causing the problem. (I don't actually do anything to the arguments so this may be a issue with .NET Process.StartInfo.Arguments not liking the > character.) The miner has some different logging options but other things have taken priority so I haven't had a chance to really look into incorporating them into CGWatcher yet... but it is on the to-do list.


poohbah:


I'm not sure what you mean by that. From the log entries you posted, it restarted the running instance at the scheduled start time, correct? Or am I misunderstanding what you meant?

I guess the question is... what is the expected behavior if scheduled mining is set to start but the miner is already running? If a scheduled stop time is set, should it still honor it? Right now what happens, or should happen, is that the miner will be restarted at the scheduled start time (just to be safe the miner is mining properly) and the miner will be flagged as being on scheduled mining time so that if a schedule stop time is set, the miner will be stopped after that many hours.

There are also differences in how the start/stop/restart/pause buttons behave, and although I'm pretty sure I put it in the ReadMe, I may need to make it clearer. The buttons in the Settings tab (Stop, Restart) will cancel scheduled mining time (thus voiding a scheduled stop time), while the Pause/Start on the Status tab will not. As an example...

I want the miner to run while I'm at work so I set the schedule to start mining on Monday at 9am and set it to stop after 8 hours (5pm). Monday 9am comes and the miner is started (or restarted if it was already running) turning on the scheduled mining flag. If I use the Pause/Start button on the Status tab, it will stay on the schedule and still stop at 5pm (if it is running at 5pm and I have not closed CGWatcher in between.)

If I use the Stop/Restart/Start buttons on the Settings tab, it cancels the scheduled mining meaning if I start it again and 5pm comes around, it will not be stopped. Scheduled mining will resume as normal the next day it is set to start.

So all of this only affects the scheduled stop time... which is different from the "Restart after X hours" which restarts the miner instead of stopping it.

If the miner is on scheduled mining time with a stop time specified and you click the Start/Stop/Restart button in the Settings tab (which will void that scheduled mining), I will add a prompt to ask the user if they want to continue (canceling the stop time), or simply "pause" the miner so that when they restart it it will still stop at the appropriate time.

All that said, scheduled mining hasn't really been touched since I implemented it aside from maybe a bug fix or two. In the next update (1.1.5), it will get its own tab and will ultimately get more options including not only starting the miner at specific times, but also increasing or decreasing intensity at specific times or when the computer is idle. But I'm not sure how soon I'll get to that. 1.1.5 has some major changes and improvements "under the hood", so I want to get it released soon (within the next couple days). But because it will now get GPU info on its own (including for Nvidia cards), I am trying to do a lot of testing with the limited Nvidia systems I have access to. 1.1.5 also has improved support for multiple miner instances running at the same time, though each miner will need its own CGWatcher instance and unique api-port set in its arguments/config file. I still have some things to work out (such as making sure they don't overwrite each other's settings in the .ini file.)

Because of these significant changes, I will probably post a download link to the new version as well as a link to the previous version just in case anyone has problems with the new version... although I am working on allowing the user to correct any GPU-matching problems on their own. If anyone happens to be mining with Nvidia cards (or even Intel HD graphics if that even works) and would be willing to test the new version, please let me know here or email me at the address in the ReadMe. I know AMD+Nvidia systems are unusual and temperamental at best, but I am also looking to test more of these - for example on one PC I have there is an integrated Nvidia GeForce 6150SE and an AMD Radeon card I installed. Although these configurations are rare in the mining world, I still want to be able to handle them... if not automatically, at least let the user tell it which GPU is which since trying to match them across the different libraries is a mess.

Yes, hashrate not displaying correctly has been fixed in 1.1.5 which I am trying to have ready this weekend.

Sorry, I didn't say that clearly. I did add that the the program, but haven't released the update yet. Because of the changes with how it handles GPUs, I have some things to work out but I've been making good progress so I'm expecting to have it ready this weekend.

I've also been adding support for multiple miners running, although each will need their own CGWatcher and a different api-port set in the config file or arguments so there is no cross-communication. CGWatcher will allow multiple instances of itself in 1.1.5 as well to accommodate this.

MooC Tals: Were you able to get CGWatcher to detect a running miner process? It is not yet capable of handling multiple instances with any accuracy (it just picks one and goes with it). I've been working on this but I'm not sure if it will be completely ready in the next update.

It appears that the method in CGWatcher for finding miner processes is causing an exception, which is causing it to bail before it finds them. In version 1.1.5, this method has been completely rewritten so it should correct this problem, or at least provide more info for finding the exact issue.

Also, if a miner is running the first time CGWatcher is ran, it sets that miner to the default profile it creates. If a miner is not running, you'll need to set the profile miner settings yourself. I'm not sure yet how I want to handle what it does if multiple miners are running.

For all versions of CGWatcher prior to 1.1.5, it was completely dependent on the miner to get all GPU information... so if it couldn't connect find a miner (because of an error) or the miner's API was disabled, it would not be able to display any GPUs. With 1.1.5, CGWatcher gets GPU data itself and any GPU data from the miner will supplement it. This will allow for some overheat protection in CGWatcher for GPUs that cgminer doesn't get information on - specifically Nvidia and possibly Intel GPUs. If it is an AMD card that cgminer can get data for, it leaves overheat protection to cgminer which can provide more fine-tuned management by adjusting fan and clock speeds. CGWatcher's overheat protection, at least for now, is limited to automatically adjusting a GPU's intensity and in cases where its temperature exceeds the temp-cutoff setting, the GPU will be disabled until its temperature returns to the temp-target range.

The new version uses OpenHardwareMonitorLib, which should be better tested than anything I could write in the similar time it took to implement. If you've used OpenHardwareMonitor and your GPU data is reported, it should also be reported in CGWatcher.


sydameton: I'm not sure if the the new version will be able to report your GPU voltage. Even if it can, I don't know if CGMiner will let you modify them. However, the voltage would at least be displayed.


I am hoping to have 1.1.5 ready this week. It has a lot of improvements to the monitor, and all known bugs have been fixed. Hopefully no new ones are introduced, but I am going to spend the next few days testing. The GPU handling is completely changed, and while it's worked perfectly on every miner I've tested, I can't say for certain it won't have problems with different hardware setups.

Thanks for the feedback. I'm working on getting any CGWatcher issues resolved in the next update and getting CGRemote released.

AlphaColt: Just to clarify, CGWatcher doesn't modify clock or fan speeds. CGMiner is what modifies them using the settings you tell it to use. CGWatcher just makes changing those settings easier. When you change a GPU setting in CGWatcher (like clock speed, fan speed, etc), all it is doing is passing a command to CGMiner telling it the changes you want to make, then displaying the results it gets back from CGMiner. Why clock or fan speeds modified by CGMiner would cause them to not show in Afterburner, I cannot say because I never had that happen. You can also try Sapphire Trixx and see if it works any better than MSI Afterburner. I find that both work better than Catalyst Control Center, which often won't display multiple cards unless they care connected to monitors, using dummy plugs, or cross-fired.

I didn't realize the latest version was still prone to it going nuts over API access but I just happened to check the log on another miner of mine and saw a similar group of entries. I will definitely look into this and make sure it is corrected. I've also made some other improvements, so I'll be releasing 1.1.5 sooner than I expected... probably in the next few days.

1.1.5 gets GPU data outside of the miner if the miner doesn't (specifically, Nvidia temperatures) and will take similar steps to prevent overheating as the miner does with AMD cards. If temps go over temp-overheat, it decreases intensity (instead of down-clocking). If temps go over temp-cutoff, it disables the GPU. Once temps return to temp-target, it will reset/re-enable. I know there aren't a lot of miners using Nvidia cards, but I thought they should at least be using the same protection against overheating as AMD miners have. I still have to do some tests and can't guarantee it works for every card, but it found most data for my GTX 285 that I've been testing it with. I don't know if anyone mines with Intel HD integrated graphics but I will probably add similar support for that just to cover all the bases. GPU data is updated continuously (about every few seconds) even if not mining.

There is also better support for non-responding miners and a restart computer option is added to the 'Restart if sick or dead GPUs are detected' check. Anyway, I will look into this and if anyone else is having a problem please let me know so I can get it fixed before the next release.

18RATTT: I couldn't find anything that would cause this issue because starting the miner using the start button uses the same code as when it is started automatically. However, I did add some log entries to provide more information when auto-starting the miner, so if it happens again it may provide some help in locating the problem. It will now create debug log entries any time the miner is started (or stopped) showing the active profile, miner path, config file, and arguments that are being used to start it.

In regards to email notifications, it is something that has been requested and is on the list but no ETA on implementing.


pengoau: Thanks for the info. Did you have the 'Ensure miner stays running' option checked? When the miner is closed outside of CGWatcher, it doesn't know whether it crashed or you closed it purposely (clicking the X or using the menu in the miner) so it does not automatically start it unless this option is checked. If this option was checked and it failed to launch the miner (it may take several seconds, up to your monitor interval at most) please let me know, and include the data from the Report tab and any related log entries (make sure 'Show Debug Log Entries' is checked in the Log tab so these entries are included.)

Also, I've made some changes to the monitor that if the miner has stopped responding for 3 consecutive checks, it will be killed and restarted. This will happen as long as the monitor is enabled and does not require a specific option to be enabled. You can change the number of consecutive checks this has to happen before the miner will be restarted (default: 3) by changing the NotRespondingRestartChecks=3* to another value in the INI file in version 1.1.4.2 (and future versions.) This is something obvious that CGWatcher should have been doing already, but since I had never personally experienced the miner to stop responding I never watched for it.

Additionally, using the info you've provided, CGWatcher will now disable the WER UI ("close" window displayed when a program stops responding) upon starting and restore it to its previous setting upon closing. This may be sort of an overkill to make sure it is able to kill a non-responding miner successfully. If you should not want it to disable the WER UI (since it will also cause this "Close" window to not appear for other programs that stop responding), you can change AllowDisableWERUI=True to AllowDisableWERUI=False* in the INI file. I don't think having this window disabled is a big problem so it will disable it by default.


cyberworx: Please post in your own thread.


sydameton: I've changed the 'Restart when sick or dead GPUs are detected' option to allow you to select whether you want it to restart the miner or the computer. Currently this option is only available for when sick or dead GPUs are detected, as was requested. As I mentioned above, I also changed the monitor to check to see if the miner process is not responding and if it isn't respoding for 3 consecutive checks, it will restart the miner (killing the process if necessary.) This may be enough to correct the problem that you encountered without needing to restart the computer.

If you do set it to restart the computer when sick or dead GPUs are detected, it will give you a 30-second countdown window from which you can cancel the restart if you would like. By default, it will not force-close other programs when restarting because I didn't want it to cause anyone to lose unsaved work in other programs they may have running. If you want to change this to allow CGWatcher to force-close other programs when restarting, change ForceCloseProgramsOnRestart=False to ForceCloseProgramsOnRestart=True* in the INI file.


All of these changes have already been made and will be available in 1.1.4.2. Ultimately, I may create an option to restart the computer if restarting the miner fails... but this won't be in this update. This update should hopefully be available in the next few days.


(* - This setting may not exist in the INI file before you run 1.1.4.2 for the first time so you'll have to either start CGWatcher (which will add it to the INI file) or add the setting manually under the [Monitor] section.)

Igloczek: Yes, this is possible. I will probably change the 'Restart miner when sick or dead GPUs are detected' option to allow you to choose whether you want the miner restarted or the computer restarted when this happens. Just keep in mind that you will need to have CGwatcher run at startup and automatically launch the miner if you want it to continue mining automatically after a system restart. Also, if the computer prompts to select a Windows user and/or enter a password after restarting, this will also require user input before mining resumes.


sydameton: Thanks, this was a bug as far as the log entry it made. The hashrate (0 Mh/s) was below the cutoff (1000 Mh/s), but the bug was that it reported this had been the case for at least 30 seconds, when it most likely was not. When it's inside the startup grace period, it doesn't really care how long it has been below the cutoff because it won't restart it anyway. Once outside the grace period, the timer resets and it begins to care.

In other words, ignore the 'for at least 30 seconds' part, but everything else is correct. I've modified the code so it will be fixed in the next update.

grottenolm: Thanks for the feedback. I just uploaded version 1.1.4.1, which should correct the problem you had with the 'Ensure miner stays running' option. It was indeed a bug, something that I overlooked when implementing profiles. I also found a bug that prevented the hashrate cutoff type (Kh/s, Mh/s, Gh/s) from being saved and reloaded, so that is corrected as well.

I've also added an option for choosing whether you want the monitor to check for accepted share count changes, or total share count changes (accepted, rejected, or stale). Let me know if this resolves your problem with solo-mining.

Someone else mentioned setting different hashrate cutoffs for different profiles, specifically when mining SHA256 vs Scrypt where you may use Mh/s for one and Kh/s for the other. That's an obvious annoyance so I may end up making some or all monitor options per-profile.


Edit: In response to your edits, I've made another change to 1.1.4.1 that will disable or prevent the "Ensure miner stays running" option if the active profile's miner path is not valid. The bug I fixed earlier caused the active profile's miner path to not be set properly before this option started the miner.

The next big update will be a UI overhaul. I have a thread in the newbie section where I discussed this earlier today... or last night... I can't remember. I will keep your ideas in mind when laying out the new interface. Right now you can see a restart counter and the last restart reason in the Report tab, along with a ton of other info.

The last idea is interesting, but my focus right now is getting the Windows version of CGRemote finished. I'd love to make enough money to devote all of my time to these projects, but I do not think that is realistic. I haven't received anywhere near enough in donations to pay for mobile dev work. Android development is something I want to learn so it's on the list, but it may be a while before I get that far down it.

kislam: Thanks for the suggestions. I try to write software that is as intuitive as possible, but after focusing on the underlying code so much it's easy to lose track of how the user might interpret things in the UI. I've realized that with the added features so far, and more to come, it has gotten to a point where I need to completely overhaul the main window... but there were so many improvements to the monitor in 1.1.4 that I wanted to get it released as quickly as possible. I am planning on a UI design similar to that of VirtualBox's settings window where instead of tabs there is a listbox (or treeview like in Explorer) on the left side (probably with icons to make items more distinguishable) and clicking on an item switches the main area of the window. With tabs I try to limit adding new ones because it quickly becomes a mess. Here is an example:


The list doesn't have to run the entire height of the window... I will probably leave room at the top for hashrates, profile, temperatures, etc. that will always be visible Adding profiles has significantly changed the way the application works and I think it alone is reason enough for the switch. Plus this will give me a lot of room to add features in the future without worrying about where I'm going to put things. I am also creating a smaller overlay window that just displays hashrate, temperatures, profile, etc. that you can switch to or that you can have open when you minimize CGWatcher so you can keep an eye on mining without it taking up too much of the screen. It will have an option to stay on top of other windows as well, although from my experience that never seems to work 100% of the time... especially if another window sets itself to stay on top.

While I'm still in the planning stages of this change, I'm open to any ideas or suggestions anyone has about the new UI. I will also be putting together an alternative download that comes with the latest pre-compiled version of cgminer (similar to what GUIMiner does) so that all you need to get started is to provide your pool information, which it will ask for when you first launch. I didn't expect that a large portion of CGWatcher users would be new to mining, so I want to make the new UI as user-friendly as possible. I already have a lot of thoughts and ideas for this written down, butany suggestions on that are appreciated as well.

Also, ideas for the CGRemote UI are welcome. I've been working on the "under the hood" stuff, so the UI will be the last thing I do.

18RATTT: Please download version 1.1.4 again using the same link on the CGWatcher page. I apologize for this, but the bug was found this morning and was fixed... but even by then there had already been around 60 downloads. It would not affect users who have two or more monitors (which is why it slipped past me) but even those users should update with the newest files.

The new Config File Editor in version 1.1.4 may be helpful to beginners, regardless of whether or not they want to use CGWatcher to monitor their miner. The Config File Editor makes it a lot easier to configure the miner, then it can either save it to a config file or convert the configuration to arguments (as well as convert arguments to a config file), so if you are creating a batch file it will be helpful in setting up the arguments. It shows all of the possible options for the miner, and does some validation to make sure the values are correct or in the correct format.

If you create a profile and point to a .bat or .cmd file as the miner path, it will even save the profile's arguments into the .bat or .cmd file for you. It also has buttons to open the .bat or .cmd file in Notepad so if you want to manually edit them, it is much quicker than navigating folders.

I'm admittedly bias, but I can't see an advantage to having not having a GUI and not having the CGWatcher monitor make sure the miner stays running. After you wake up a few mornings to find that the miner stopped working in the middle of the night, you'll see it does a lot more than just provide something pretty to look at. It can also start with Windows, start the miner when it starts, start minimized to the system tray, etc.

If he is just "cracking" brain wallets I have a bitaddress.org file that I modified to check wallet balances and activity, so you can check word lists or randomly generated addresses. When it finds a balance (or activity) it will notify you. It's javascript so not the fastest method, but it works and is all contained in one file. I modified it when someone on reddit posted a challenge to break in and steal 1 BTC from each of their 5 brain wallets that had weak passphrases. I found out about it the day before it ended and didn't end up getting into any of them.

I'll undercut IHackedBitcoin and sell it for the low, low price of a 8 BTC donation. 

Act fast, supplies are limited.

Maybe I'm missing something (and admittedly I may be) but what exactly does listing wallet addresses and private keys prove? I can create a bunch of wallets and list their addresses and private keys too. How do we know you didn't create those wallets? It's sort of a which came first, the chicken or the egg thing. If you are able to derive a private key from a wallet address, why are you only wallets that have had ~0.1 BTC or less in them? It seems more likely that you have created those wallets or are randomly generating addresses and then checking to see if they've had activity. In that case, you'll probably find that mining is more lucrative.

Also, if you have improved Nvidia mining by a factor of 3, write a Nvidia miner. There will be a line of people waiting to donate to you then.