The password you provide on the second page you listed is wrong, please correct it. The embeddable miner on the first page, on the other hand, appears to be working well, and so does the online miner on the pool website. I have briefly tested both of them using your worker's credentials, and shares do show up in your account page.
Please keep in mind that share counts are not updated in real time, but only every minute.

To mine solo just tell cpuminer to connect to your local Litecoin daemon, using the local IP of the machine and the RPC username and password defined in your litecoin.conf. The default port is 9332.
If you want to set up failover pools in cpuminer, see this thread.

At present it's only used for the avatar, you don't need to worry about it.

DDoS attack is in progress. Sorry for the inconvenience.

Done. There's now a --sharelog option that allows you to specify a file for logging submissions.

At present this is printed when a share is submitted. I could add an option so that it is printed every N seconds instead.

I'm curious... what for?

I don't think that would make sense, since it's the user himself who supplies the information. It does make sense in cgminer as cgminer can handle multiple providers.

Could be done, but wouldn't it be a bit useless?

Just to get an idea, what kind of statistics would you like to see?

I don't think I'm going to add the curses library as a dependency.

Sorry guys, pool is currently down. Yes, DDoS once again.

I just had a look at the 0.5.2 commit. All I did is adding a 1-second pause between retries; I don't think I've changed anything else in the failover mechanism.
So I'd say if the problem you describe exists in 0.5.2 it should also exist in 0.5.1.
Can you please send me some logs if the issue shows up again?

I have added a 1-second pause between retries as a quick-and-dirty fix for this issue.

After exchanging a few private messages with ShadesOfMarble, this turned out to be a OS-and-locale-dependent issue; it should be fixed now.

Version 0.5.2 should also support miners that (like Phoenix) issue long polling requests using the GET method.

Did you tell cpuminer to use your configuration file?
(This is described in the --help output, by the way.)
If you don't specify arguments, cpuminer will just use the default connection settings, and will try to connect to localhost:9332 without credentials.

If that is not the problem, please post the full output given by minerd.

If miners were allowed to do ntime rolling themselves, they could end up working on the exact same work unit, so it's not a good idea. Maybe it is possible to allow for little variations using a very low "expire" parameter, assuming of course that miners interpret that correctly, but honestly I can't see why you need the miners to roll the work themselves when they can just ask the proxy to do it.

Support for additional protocols is not planned at this time. I have very limited time to dedicate to this project, so right now I can only fix bugs and maybe add a few minor features.

Please send me an email (address is on the homepage). I will try to notify you when registrations open again.

I'm really busy with other stuff in this period, so no, or at least not any time soon.

Yes, macavity is right, that's the true raison d'être of this program, and why it was developed.
RollProxy allows multiple miners to reuse the same work unit. And this can bring huge bandwidth savings.

No, no reward system intrinsically needs to pay for stale shares, as validity of shares can be checked as soon as they are submitted.
I'm not even sure payouts need to be instant for a pool to be called a "pure PPS" pool. On the other hand, if a pool really uses a pure PPS system, there should be no reason to delay payments.

It's the "doesn't pay for orphans" aspect that makes me think this cannot be considered a pure PPS system. And it isn't SMPPS either. Maybe an acronym for this system has not been devised yet.

I'm confident Coinotron's system is fair and legit, but I would like to understand better how it works, so that (if need be) we can find a proper name for it.

I still don't understand. In a pure PPS system, rewards must be completely independent of block finding, so it's not clear what you mean when you say that you "don't pay orphans".

How do you implement that? You link shares to a given block round and wait till the block is confirmed before paying the shares? So if the block gets orphaned you invalidate all the shares linked to that round?

Unless I'm mistaken, that would require adapting the pool server to directly support the Stratum protocol. I don't think there's a server-side proxy that can take care of interfacing with pushpool.

At any rate, I had a look at the official documentation for the protocol, and its main feature appears to be extranonce rolling. In the case of Litecoin, this feature is useless, since the regular nonce space is large enough for all kinds of miners, including the fastest GPUs. (Even the rollntime extension is useless, unless it is used to share the same work unit among multiple miners using a proxy.)

While I'm at it, I would like to mention that there are at least two other (older) mining protocols out there, namely pushpool's binary protocol and the Multiminer protocol (MMP), and each has its advantages. Unfortunately, no mainstream miner supports the former, and only Phoenix seems to support the latter.

Sorry, I'm a bit confused. Does that mean that the pool is using a SMPPS system?

Unfortunately that doesn't help. What is needed is a way for RollProxy to connect to the Internet through a SOCKS4/5 proxy, not a way for the miners to connect to RollProxy through an additional local proxy.