EMC stratum support should be fixed in git now, with support for fractional diffs and diffs just below 1. I used some of Inaba's code ideas and expanded it to include support for the actual fractional diffs as well.

I've tried both dynamic and manually set to 2, but I only get diff 1 shares on au stratum. I have restarted my miner multiple times but still only get diff 1.

Doh!   fix soon...

EDIT: Reuploaded, please try again

Still no idea, but the fake "burst" in Q should have gone. It's still a low priority concern but I will investigate at some stage.

cgminer should also show you the highest share on exit, and each pool information shows you if you found any blocks for them, either via the pool menu at runtime or the pool summary on exit.

Tried your stratum implementation. It seems that you send a mining difficulty in response to the mining authorise request while cgminer is only expecting an auth message at that stage so it will fail to connect.

EDIT: Also, expecting "auth" as an "id" is wrong since id is an integer for json in stratum. This appears to be a hangover of luke-jr making fucking bullshit up.

It is advantageous if a pool goes down for cgminer to not try to switch to another one that hasn't been working. 1 failed getwork is enough to do it. It's the same mechanism it uses on startup to see if a pool is alive. Overkill? Dunno, I wasn't expecting pools to fail sending getworks so often.

It's not a mistake. Previously cgminer did not check the backup pools were working. Now it does check them even if not mining on them.

Did it not give you the option to debug it when it crashed? 

By the way, does nothing unless you're mining litecoin. also does nothing because they're the defaults in cgminer for that hardware. So the only thing you need to set is an intensity. Intensities above 9 on windows tend to increase CPU usage.

I think this is great news, allowing p2pool to scale to any size in the future, taking a lot of load off the local p2pool software itself, allowing it to concentrate on the business of getting those blocks and transactions out ASAP. Sending higher difficulty targets to the miner will take it even further.

Much appreciated! Occasionally nothing useful comes from the information, or windows decides to disable the debugger, but at least we have tried.

That's helpful indeed.

However it does not change the fact that I'd really appreciate it if at least *one* of the users out there getting crashes at least tried to help me get debugging info.

I cannot reproduce the windows crashes as the only machine I have that can run windows can barely mine at all.

If you are having windows crashes, I need your help to debug the issues.

See here for how you can help:
http://ck.kolivas.org/apps/cgminer/debug/

If you have a reliable test case that crashes cgminer then you are the person most likely to be able to help me fix it.

Nvidia drivers by default on OpenCL use "busy wait" for the code, meaning it will always use 100% CPU. To do it in CUDA directly you can manually specify to not use busy waiting. However, I've done some testing, and CUDA code direct for BTC mining is no faster than openCL when maxed out, and if anything, every so slightly slower when asked to not busy wait. Note that there is precious little mining software that does native CUDA, and it is of NO benefit to nvidia miners, apart from the CPU usage issue, IF it's coded correctly. No, cgminer does not support cuda natively and I have precisely zero interest in implementing it, unless someone sent me 1000 BTC to implement it, especially considering GPU mining has a very very limited use by date now...

You're welcome. Thanks for the feedback 

Noted.

New versions: ->2.9.3, 11th November 2012

The GBT rollout wasn't that painful, so hopefully with this release cleaning up a few issues I can call this version the current stable release. I note more and more pools are moving to stratum instead anyway, which is in my opinion the better choice for pooled mining.


Human readable changelog

If a GBT pool was not the primary, then shares leaked to it or switching to the GBT pool would easily generate stale work. Now cgminer gets a new block template once per minute even from the backup pools. This is of course going to waste more bandwidth but is the only way to guarantee that any GBT work generated is not stale.
Cgminer will now detect backup pools failing even when not mining on them.
Sometimes cgminer would show the current block as just all zeroes. This bug has been worked around.
When mining on a server without longpoll, such as solo mining, if a stratum pool is available, its block change information will help the solo now.
Hopefully the URL stored for stratum pools when saving a configuration file works now.
The pools that had longpoll failing (like p2pool) should be fixed again.
Solo mining will now show the best share diff as well, even if they're all below target.


Full changelog

- Make header larger on gen stratum work to accomodate \0 at the end.
- Use stratum block change from backup pools as an alternative to longpoll for
pools that don't support LP.
- Check share target diff for best_share to be calculated when solo mining.
- Round some more static string arrays to 4 byte boundaries.
- There is no need for the static arrays to be larger than required, so long as
they're 4 byte aligned to appease ARM.
- Store the full stratum url information in rpc_url for correct configuration
file saving.
- Put in a hack to prevent dud work from sneaking into test_work_current being
seen as a new block.
- Reset the work->longpoll flag where it will affect stratum work items as well.
- Check for both coinbase/append and submit/coinbase support before using GBT
protocol.
- First pass through testing for GBT should not set probed to true since we are
about to probe again.
- Hash1 is only used by the deprecated cpu mining code and never changes so
remove it from the work struct and bypass needing to process the value for all
other mining.
- Get a work item once per minute for all getwork and GBT pools to test they're
still alive and to maintain a current GBT template.
- Get a fresh block template with GBT pools on switching to them.

I have tried to reproduce this bug and cannot, on mingw while building on windows and on mingw cross compiled on linux. The fact that your version numbers are screwy suggests something is wrong with your git repository and this may have nothing to do with cgminer. The correct way to build from git is to ./autogen.sh first, and not to manually use autoreconf (yes I know the docs are outdated). Testing a tarball release version instead of build from git should tell us whether that's the case.

It didn't really get trumped. No one has any idea. Usually if nothing is being produced or lots of HW errors despite a high hashrate, the intensity is too high.