I'm still repairing database from problems, which cause longer processing of blocks, almost-not-working website etc, but mining really works without problem.

The reason is that one database table which is not needed in mining got insanely fragmented. So queries take ages to process (profile page, stats page, calculating rewards), but mining core is OK. I'm repairing table right now, but it will take some (I expect that it finish in 24 hours). Please excuse crappy website performance in meantime, I'm working on it.

Thanks to troubles with database, I stopped calculating rewards. Everything will be fine soon, as I enable scripts again.

I'm still solving database issues, you can see higher stale ratio right now. I'm sorry for troubles.

There are some database problems which are causing "bad gateway" messages on web interface. I'm solving it, should be better in few hours. Mining is not affected.

Edit: I temporarily disabled JSON interface for retrieving profile information. Many users started to pull information much more frequent than before, which affected website performance. I'm still investigating it, will update status later.

Yes, of course, because miners were disconnected during this time.

Because of some troubles in datacentre around 19.00 UTC, pool balancers were migrated to another machines. I'm sorry for short pool outage, it was down for ~2 minutes.

What kind of error? Is it connection timeout or do you see any error message?

Can you provide some additional information? Miner, version, what exactly is "a lot"? Do you still see the problem?

Did it "repair" for you? As was mentioned above, there is some delay between round end and processing all block rewards... AFAIk there was no problem at this time.

As CyberPhunk said, "unconfirmed" reward dropped a bit because of invalid block.

gr0bi42, I don't know why you have such high stale ratio. There isn't anything what I'm hiding... What phoenix version _exactly_ do you use? I'll try this version on my machines, maybe there is some change in phoenix...

Well, round reward isn't related to round length. How much you have _usually_ for one round in last day or two? And was you connected in the end of the round? Significantly lower round reward may happen when you disconnect few minutes before round finish,

I know about many phoenix miners connected to api2 and nobody has such problem. 50% stale is *obviously* bad, but you're the only person who reported this. So I'm little suspicious about some other problems 'on the way', like network routes. You're not mining on the pool right now, so I cannot debug it specifically for you, but pool servers performs well at this moment, so I don't see anything to 'fix'.

Hi, payments are processing twice per hour, so if you set threshold to 0.01 and you have higher threshold, just wait a moment.

ad 1) There's no manual payout option ("button"), but payments are processed twice per hour, so setting threshold to 0.01 will make the job...
ad 2) Not yet, but I'm testing this feature right now.

Yes, that "feature" affect only fast miners, usually more GPUs handled by one Diablo instance...

There should be no difference in rejected ratio between phoenix and poclbm, so it sounds weird. Are you using api.bitcoin.cz or api2.bitcoin.cz? If api.bitcoin.cz is the problem still here, even after restart which I did before moment?

I restarted server handling api.bitcoin.cz before few moments, it is up and running again. I needed to load new kernel, sorry for troubles.

Short answer - no.

It is using historical feed from bitcoincharts.com (URL to CSV is easily readable from source codes...), but server provides only limited history (+/- 3 days).

But I think that providing historical data would be interesting (paid) service for bitcoincharts.com, because they _have_ (almost) complete trading history in database...

This happen when bitcoincharts is down for maintenance. Historical feed then return HTML page instead of CSV with trading data...


Yes, this happen when mtgox's websocket interface close connection for some reason (server restart, ...) and websocket connection fails. This is bug on my side, but I'm using 3rd pardy websocket library and I didn't find a proper way how to reconnect after such failure (better said; I even didn't find a way how to catch this error and not let the script to crash completely :-/).

Oh well... Diablo isn't working properly for some technical reasons; Diablo changed some stuff in his miner few weeks ago and refused to "fix" it to be backward compatible. Please use another miner (I recommend phoenix or poclbm).