This is a known issue with Coinotron (it was first reported here).
The problem is the following: the frequency at which Coinotron sends out notifications is proportional to the speed of each miner, and (since share difficulty is fixed at a relatively high value) slow miners can go 120 seconds without any communication with the server. When that happens, cpuminer thinks that the connection to the pool is dead, and tries to reconnect. This is the same logic used by cgminer/bfgminer, and I believe it makes sense, because it's up to the pool to refresh the work at regular intervals and ensure that new transactions are getting included in block candidates. Letting a miner work on data older than 2 minutes is not acceptable.

Assuming you're using the fork mentioned by K1773R, what -H does is enabling some debug output. (So if I got this right it's basically a limited version of the --debug/-D option available with the cpuminer discussed here.)

Thread hash rate is updated when work is refreshed, so obviously with a lower scan time the hash rate will be updated more frequently. (Again, this only applies to solo mining.)
This is irrelevant with respect to mining speed. The only reason why you may want to lower the scan time is to avoid working on stale data, in case the network is producing blocks quickly.

If the hash is higher than the target it can't be an orphan, all you have is a false positive which should not even be considered as a block candidate. So for instance the false positive mentioned by yourofl10 should not have been submitted upstream by the miner, and should therefore be neither accepted nor rejected.
No idea why the miner you are talking about generates false positives; it could be a wanted behavior (possibly a hack to generate hashes faster) or a bug. In either case, this is not the right thread to discuss this.

There is no -H option... unless you're referring to some other fork of cpuminer?
Anyway, the cpuminer discussed in this thread always displays whether a submitted solution (share or block) is accepted ("yay!!!") or rejected ("booooo").

If you are solo mining you may want to set it to a lower value than the default (5 seconds), provided that the *coin daemon is running locally. That can lower the probability of your solutions getting rejected.
If you are mining at a pool, the option is completely ignored by the miner, as better solutions (long polling or Stratum) will then be available.

I'm working to resolve this as soon as possible. Unfortunately this time the attack was done on a pretty large scale.

EDIT: The attack was successfully mitigated, and all systems are back up. Sorry for the inconvenience.

You didn't mention the exact model of the Xeon, but judging from the cpuinfo report you provided it looks like it's an old Netburst-based processor, which would partially explain why it is so slow. Does it support hyperthreading by any chance? Have you tried running a single thread to see if the per-thread speed is higher?

While I'm here, here's a non-exhaustive list of things that can significantly influence your hash rate:

• running in 32 or 64 bit mode;
• CPU microarchitecture (Netburst, Core 2, Nehalem, Sandy Bridge, Haswell, ...);
• CPU cache size and speed;
• CPU clock frequency;
• hyperthreading;
• the CPU time used by concurrently running applications.

On the other hand, all other things being equal, the following do (should) not influence the hash rate:

• the amount or speed of RAM;
• the operating system (as long as it provides full support for the capabilities of the CPU it's running on).

That is actually meant to be a feature.
Automatic payouts are recurring, so the exact amount is not important. What is not paid out by a given automatic payment will be paid out by the next.
Most users are mining 24/7, so there's no point in paying out the exact amount every time the payout threshold is reached, because their balances grow continuously.
The advantage is, of course, that you get payments with nice round numbers, which some people prefer.

If you want a full payout, simply request an instant payout on your payments page.

They are completely different proof-of-work algorithms. You must use scrypt for Litecoin, and you must use sha256d for Bitcoin.

Added this to the FAQ on the first post.

I guess you received an automatic notification stating that your payout address was modified from some IP that is not yours.
That would mean your account was hacked by someone who managed to find out your password in some way or another. If you haven't done so already, you should change your password as soon as possible. For additional security, you may also want to enable two-factor authentication.

As far as I can see, the Litecoin address you mentioned doesn't match any pool account at the moment, and that particular French IP only accessed your account.

Hi... Are you sure you're in the right thread? I don't think LitecoinPool.org has any such function.

Confirmed on Windows XP, though interestingly enough it seems to run with no problem at all in wine.
Even more interesting is the fact that if I build it with a different version of gcc it appears to run fine everywhere. I have now uploaded this build, please see if it works for you.

Sure, as a higher share difficulty leads to fewer shares being found and submitted.
But that does not mean that a high share difficulty can help lowering the percentage of stale shares, which is what matters.

I don't think letting miners choose would be useful. I may try to make the difficulty adjustment less aggressive though.
In any case, since shares are weighted, there's no significant difference between getting 4 diff-32 shares and 1 diff-128 share, be they accepted or rejected.

That can happen if the server you're connected to has a hiccup; the miner should try to reconnect automatically in a matter of seconds.
If you suspect a compatibiliy bug in the miner, feel free to pm me your full connection details so that I can try mining at your pool and see what the problem is.

There's a -q option for preventing the miner from printing the per-thread hashmeter.
To save the output on disk you can just redirect stderr to a file.

Sure!
After reading the documentation of autoconf, I think it should be pretty safe to just replace stdint.h with inttypes.h for all systems.

The Mining tab in the old Litecoin-Qt 0.6.3 also allowed pool mining.
Solo mining with a CPU at the current difficulty would be a bit of a wild goose chase, by the way.

I don't use Windows, so I can't tell you what you have to do step by step, but you probably want to create a batch (.bat) file and write the command to start the miner in it, complete with all the options you want. There are basic usage examples in the first post.

A couple of Windows users reported what is probably the same issue over a month ago: https://github.com/pooler/cpuminer/issues/21
Two other Windows users I asked said they could download the archives and run the miner with no problem at all, though, so I closed the issue when the original reporter stopped answering my questions.
For what it's worth, I have no problem accessing the files hosted at Sourceforge, so I'd be grateful if you could provide some more detail. Operating system, browser information, and what error you get exactly would be a good start.
Please also try to download the files from this page and see if there's any difference.

The latest versions of Litecoin-Qt have removed the Mining tab. If you want to use cpuminer, you can run minerd from the command line, or make a batch file for it. There used to be a graphical frontend, ScryptMiner GUI, but it's currently unmaintained, so I'd advise against it.

Version 2.3.2

• This version includes new AVX2-specific scrypt and SHA-256d routines, which bring an 85%+ speedup to the new Intel Haswell processors. I have tested the new code on a Core i7 4770 (4 cores, 8 threads, 3.4 GHz), and the results seem pretty good: over 95 kh/s for scrypt, and over 50 MH/s for SHA-256d.
• No speed improvements for non-Haswell processors.
• The output stream is now flushed after every log message in order to avoid possible delays on Windows.
• Fixed an undefined-behavior bug in the Stratum code. This could cause crashes, hash miscalculation or no problem at all, depending on the compiler used to build the miner.

The source code is, as always, available at GitHub. Source tarball and binaries are available at Sourceforge.