For whatever it's worth, I can't bring my memory clocks under a thousand either (Overdrive and MSI Afterburner alike). Either freezes or just doesn't stick. Using two MSI 7950s.

It seems there was EnsureAPI=Tru in the .ini, corrected it, hmh. o_O The .conf files were okay.

With this same version at least, keeping cgwatcher open, starting the miner, stopping it, starting it again doesn't fix the mapping.

Current contents of my .ini:

[CGWatcher]
UseBackupHardwareMode=False
CurrentProfile=1
[Settings]
MaxAvailableLogEntries=100
Autorun=False
Autolaunch=False
MinimizeToTray=False
StartMinimized=False
NoPromptOnExit=False
PosScreen=0
PosX=13
PosY=435
[Miner]
ProcessStartCushionSeconds=15
ProcessID=0
ProfileID=1
MyProcessID=0
WindowMode=0
Address=127.0.0.1
OverrideAPIPort=False
Port=4028
GPUCount=3
[Monitor]
MonitorOn=True
Interval=5
EnableOverheatProtection=True
NotRespondingRestartChecks=3
AllowDisableWERUI=True
ForceCloseProgramsOnRestart=False
HashRateType=1
HashRateCounter=3
RestartGracePeriod=180
HoursRestartValue=24
CheckShareCountMinutes=10
HashRateRestart=False
HashRateCutoff=800
CheckShareCount=False
AutoRestart=False
SickDeadGPURestartType=0
PrivilegeLoss=False
EnsureStaysRunning=False
[System]
GPUCount=2
CPUCount=1
[Config]
EnsureAPI=True
[GPU-Map]
0=1
1=2

Dunno how that Tru value got there, I don't edit the .ini file directly, nor have ever I typed a True or False value manually in any field, as far as I can recall at least. But it's fixed for now and will not where to look if it happens again.

So, go ahead and update the file, and I'll see how the mapping goes.

Thanks for the quick reply, unfortunately I can only check things tomorrow afternoon (3AM now here) as the system became unreachable about half an hour after I posted, and I couldn't call the person housing it that late to give it a hard reboot. So, feel free to proceed with the update of course... and I'll keep you posted with how it goes.

And having problems again.

So,

Been getting this in my logs today, repeatedly: [6/9/2013 11:11:48 PM]   [d] Miner reported GPU0 that did not have corresponding OpenCL GPU! Adding to OpenCL.GPUs.

This is what cgwatcher detects after a reboot I did just in case, with no mining session started yet, as per your instructions for Tests tab: http://pastebin.com/cw6hQZrL and GPU Map screenshot https://imageshack.us/photo/my-images/24/screenshotbcj.png/?sa=0 On the screenshot, I just rolled that option down, didn't change anything. GPU1 is correct but there is no GPU2 in the system and GPU0 is missing from the map (which would be the other device that appears in the dropdown list, unassigned).

I thought of re-enabling --gpu-platform to see if it helps detection. Clicking config editor yields, for the first time, this exception repeatedly but works if `Continue`: http://pastebin.com/zcHt3mZX screenshot: https://imageshack.us/photo/my-images/14/unhandledexception.jpg/?sa=0 Didn't help, disabled it again. Manually adding the GPU at this point can not be done as GPU0 is not in the list (and as I'd find out moments later, manual mapping doesn't save anyway).

So I enabled my OC and started the miner to see if things change: On the Devices tab, device "-" (which is "0" I recon), reads inactive. GPU Map added GPU0, reports hash rate, but does not allocate a device to it. Also names GPU2 as Tahiti while GPU0 not. While it reports hash rate on the GPU Map and it doesn't on the Devices' (therefore on the Status either), I can't use 'restart miner if hash rate falls under x'. Manually mapping a device at this point doesn't work -- saves okay, but reopening the GPU Map shows the same thing, while the Device tab still reads inactive for -/0. Screenshot: https://imageshack.us/photo/my-images/24/wtfscreenshot.jpg/?sa=0

Otherwise mining's working fine for BTC at least, scrypt is causing me a f**kton of issues lately out of the blue but that's not cgwatcher-related. My scientific guess would be that my GPUs are cursed, even if they worked perfectly with the same coin-specific settings for months, BTC and LTC alike.

To say I'm confused is an understatement. Thoughts?

Sorry for the long and frequent posts.

Are you also running two instances of cgwatcher, one for each port?

I logged on about ten minutes before taking the screenshot, and the failed to reinit gpu thread message was repeating at regular intervals; I too suspected that maybe my logging on would have somehow caused this so I observed it for a while to see, thinking that if this is the case then theoretically, the system should soon reboot; I was just surprised to see that it didn't and that nothing was logged/logging so I couldn't check when exactly it died initially either. :/

Mapping works correctly now with either --gpu-platform specified or not, the --no-adl was causing the mapping problem. Also, no more random sick/dead GPUs since said removal, hmh.

Seems to be in order now...

I've disabled --gpu-platform 1 and it seems to work fine now, I can't tell when and where the problem was since I've been using it through mostly all versions of cgminer ever since I first had the problem with CPU showing up. Only GPUs are visible now.

I've moved all my settings into .conf as it's much easier to manage. Why didn't I do this in day one... xD

I thought about logging any info I can get, just in case, and it seems cgminer (with or without cgwatcher) will instantly crash if any of these are used:

"debug" : true,
"per-device-stats" : true,
"verbose" : true,

Weird. Ehh, no biggie.

Lastly, I was thinking about that time a few posts above when my miner was running with one working GPU and a dead one for ~12 hours and cgwatcher didn't reboot the system (or log anything), which got me thinking a bit. Does cgwatcher read everything directly from cgminer? I'm not a programmer whatsoever, but wouldn't this cause issues in unforeseen circumstances where it just waits for an answer from cgminer and that one's not providing/responding or other unpredictable behaviour? Perhaps copying said values from cgminer to ram, and then have the whole thing read only from ram to provide some redundancy? This way, no matter what happens as long as the watcher is alive and responsive, reboots should always execute. Just a misplaced thought though.

Thanks for the clarifications.

Yeah, --gpu-fan works with --no-adl option. Even tho I set them to 100% via Afterburner on boot sometimes after a cgminer instance is closed (or all the time?) they drop back to Auto for some reason so I figured why not, seems to stick well this way. I used --no-adl since cgminer can't adjust my voltages, can't read VRM temps (which I was more concerned about compared to core) and I think it *may* have caused some issues with either screen locking or LogMeIn, can't recall specific details. Updated to the new version, and removed --no-adl for now to see how it goes; it seems this way GPUs are mapped correctly as a first observation.

On my platform 0, I think the CPU used to pop up (dual-core Ivy)... I'll remove the setting these days and see what happens, too lazy to test this too at the moment, 5:20AM. o_O

I've changed the temp thresholds in the config to suit my needs. Regarding this, if in profile manager there are arguments/parameters in the first field and a cfg file linked in the second, will all merge into one command line which is fed to cgminer when started? What if there are duplicates which may or may not specify the same value(s) due to a typo or so, thus conflicting? Just curious how that's handled.

I'll let it dig for silver for now, go to sleep and see how things go.

Thanks again for all your input.

I found a bug, at least in my particular case. I use 2 7950s. cgminer sorts them as as they are physically installed in the system, as does HWINFO, but cgwatcher sees gpu0 as gpu1 and gpu1 as gpu0. Because of this and as my lower card is much hotter than the upper one, it tries to lower the intensity of what it thinks is gpu0, thus slowing down the real first card and of course, this doesn't help with the temp (on rare occasions my bottom card's core touches 91 or so *C, only when mining LTC). Also, using --no-adl argument if it helps.

L.E. Got more info, putting it together now.

last 40 or so hours' log: http://pastebin.com/7JCNbsKe and latest screenshot: http://imageshack.us/photo/my-images/849/screenshotjfv.jpg/

For some reason, CGWatcher also stopped logging (for) the past 12 hours (notice 7AM compared to 7PM in tray), otherwise it was responsive to menus. I'm guessing this is why the restart computer when sick/dead didn't kick in either, as set.

Furthermore, while mining the GPUs in devices tab appear as "INACTIVE", even tho respective values are reported/updated accordingly (this I rechecked after system reboot). I haven't tried clicking ENABLE while cgminer's working tho. I don't understand why I'm getting SICK/DEAD lately, parameters haven't been tinkered with for a month, and it was running 24/7 without issues since. I think after 1.1.4 these problems started surfacing, but I don't know if it's related, just an observation.

Meh.

The entire community's grateful for your work on cgw so far -- especially with v1.1.5; compared to not having it at all, lack of cgremote is meh. All in due time.

CGMiner's unable to set voltage on my dual 7950s as well, I read something about why somewhere but I can't recall atm, so I do that with Afterburner. As for the threads, I never used that config editor, I just put my variables in the profile editor, which is -g 2 for my cards but I don't have to specify it as that's default. Not sure what to say here, try it the typing way, or even not specifying it at all and see what goes? In my case, I just copied what I had in my .bat file altogether into CGWatcher's profile manager.

Nah, I meant TeamViewer or whatever else. I'm not the programmer lol!

Lol.

Anywho, you can run 2 watchers each with a miner at the same time but you need to modify the API ports for one of them, think someone else was trying to do the same thing a few pages back, or just check cgminer's readme for --api-port or something like that, same for the watcher's listener somewhere in the GUI. Too lazy to take a quick look (need to remote in again).

Not at all, hope it will work.

I dunno what to say about the missing devices. Are you able to start the miner via CGWatcher with the modded profiles.dat though (the grey problem) or still no go?

It was filled automatically, I didn't edit anything, all was set up via GUI. I figured if you could use mine for reference, edit it with your paths & settings, put it in the folder and start CGWatcher it would just load it up and work? Dunno why yours is zero, tho I can't remember if the default profile has any data in it whatsoever to begin with, in which case empty file is normal.

Quite odd, I don't know how I can help you, will have to wait for the dominus to reply. Yet I wonder, if you were to edit your watcher's profiles.dat file, using mine as a guide, saving and starting it, maybe it would work? Mine has two profiles, replaced first one with placeholders, second just wildmarks for sensitive. The file has 4 lines starting with profiles, 0, 1 and space.

PROFILES=2
0||||||||||||
1|||LTC@wemineltc.com w/ failsafe|||C:\Users\***\Desktop\cgminer-3.1.1-windows\cgminer.exe||||||--scrypt -o stratum+tcp://eu.wemineltc.com:3333 -u *** -p *** -o stratum+tcp://eubackup.wemineltc.com:3333 -u *** -p *** -o stratum+tcp://stratum2.wemineltc.com:3333 -u *** -p *** --gpu-platform 1 -I 19 -w 256 --thread-concurrency 22400 --no-adl --api-listen --api-allow W:127.0.0.1

My bad, didn't notice (in due time). I see [5/20/2013 5:48:31 PM] No CGMiner instance found., but from what I can tell it's more than that, maybe the author can help you out, I'm just taking guesses. Tho, if you run cgminer externally, then wait a few and Refresh the Status tab, there's nothing? Or in devices?

L.E. To your edit, there isn't a default folder for cgminer to my knowledge... why it would be grayed out I don't know. If you "Manage Profiles", and create a new one, still grayed out?

Does CGMiner see your cards properly? Or in what sense do you mean it doesn't show any?

Thank you so much for the updates and for all your hard work. When I'll get my farm up and running, I'll be sure to donate for your time, much appreciated!

L.E. Was this a double consecutive restart? I was sleeping when it occurred so can't tell how it actually happened:

[5/18/2013 8:54:37 AM] CGMiner has been continuously mining for 8 hour(s), you've requested to restart after 8 hour(s). Attempting to restart...
[5/18/2013 8:54:38 AM] Restart command sent to CGMiner with full API access...
[5/18/2013 8:54:51 AM] CGMiner was successfully restarted.
[5/18/2013 8:55:02 AM] API access lost at 5/18/2013 8:55:02 AM!
[5/18/2013 8:55:02 AM] Full API access became read-only access at 5/18/2013 8:55:02 AM!
[5/18/2013 8:55:02 AM] I do not have API access to the currently running CGMiner process (3324)
[5/18/2013 8:55:03 AM] API access lost at 5/18/2013 8:55:03 AM!
[5/18/2013 8:55:03 AM] Full API access became read-only access at 5/18/2013 8:55:03 AM!
[5/18/2013 8:55:03 AM] I lost API access to a process in which I had it (PID: 3324). Attempting to restart CGMiner...
[5/18/2013 8:55:04 AM] API access lost at 5/18/2013 8:55:04 AM!
[5/18/2013 8:55:04 AM] Full API access became read-only access at 5/18/2013 8:55:04 AM!
[5/18/2013 8:55:05 AM] I had no API access to CGMiner so I killed the process. I will now attempt to re-open it...
[5/18/2013 8:55:10 AM] CGMiner started successfully.
[5/18/2013 8:55:11 AM] CGMiner was successfully restarted after killing its process.