I've never heard of allcoin. Seems sketchy to me. I'd rather trade on mintpal or bittrex but cryptsy is good enough and I've never had major problems with them.

I thought HBN was top of the list last round? or did I miss a last second dash to the line by another coin?
They sometimes take a while to actually add the coin that wins

Cool. Yeah please let me know. I currently dont have any wallets running since 1.3 doesn't barely run anymore for me.
1.3 is SOOO laggy for me now I can barely use it.

Can someone please explain to me how to combine my coins? I have about 15k that has been splitting endlessly since about February so I constantly stake. I generate probably 100+ stakes a day, though 95% of them dont get accepted. Could use a bit of help.

oh and FYI I am running Mac OSX 10.9.4

hmmm... downloaded the Mac file there twice, did exactly what you said and app keeps crashing. Keeps telling me it quit unexpectedly.

Is there a new MAC wallet for Hobo? I see the link on the hobo nickels.info site but link to Mac wallet is dead.
I am still using 1.3 and have noticed for a while that 99% of my stake generations are rejected. Think I saw there is a 1.4?

Any help appreciated...

int64 nActualSpacing = pindexPrev->GetBlockTime() - pindexPrevPrev->GetBlockTime();
 if (nActualSpacing < 0)
 nActualSpacing = nTargetSpacing;

recently I started to receive message:
runtime error
....

This application has requested the runtime to terminate it in an unusual way.
...

it not right after execution - but after syncing with blockchain ends and probably during staking.

rich list is down as well

How long is the block explorer going to be down?

The database has been reconstructed and went live late last night. After looking a bit at the code, I remember that I did not program the system to go into orphan recovery when a "ghost" transaction was found. I wanted to make sure the orphan correction system worked well in production with the check range, before allowing the system to correct deep changes when a reorganization occurred beyond the check range. The issue has come up so infrequently, that it kind of slipped my mind.  
Since system has worked well to date, in the next patch,  I will add the ability for the orphan recovery system to run when a ghost transaction is found.

As for support: I will give a friendly reminder that donation funded explorers are being phased out, and getting the explorer sponsored will keep the CAP CCE explorer online when the donation "funded" explorers are shut down.
I have some good plans in place for 3.5, including GUI updates, market tickers and a mempool display. Though I personally do not see the value of a mempool display, people seem to want it.  

The exchange software I am writing should be going into beta testing late this week - early next week. Once I get into late second stage beta testing, I will be able to dedicate more time to CCE 3.5.

If one looks in the CCE3 development thread (now locked: https://bitcointalk.org/index.php?topic=262539.msg2804427), I spent much of the time on solving the orphan block issue.

There are two methods in place to avoid this issue.

1. When the database loader is triggered by the coin daemon block notify, there is a 15 second delay before the loader starts to query the coin daemon for information. This gives the daemon time to catch and reorganize the quickly detected orphan blocks before the loader commits the information to its database.

2. There is a settable range, normally set at 250 blocks,  in the explorer configuration file for block look back. Every time the database loader is triggered , it compares the previous block hashes in the range against an immediate query to the coin daemon. If a hash does not match, it corrects all the information pertaining to that block(block information, transactions, address balances, etc.) with the new information the daemon provides.


However, if changes occur after the check range, they go unnoticed until a transaction is referred to in a future block that does not exist in the explorer database. After all, it is completely impractical to check the entire chain every update.
I am working on CCE version 3.5, however this is a rare occurrence and I will need to balance the complexity vs. benefit in solving this particular situation. Progress with 3.5 is slow right now because of exchange software I am writing at the moment.

So far this system has proven quite effective and the only issues so far have been with daemons that cannot return information from their own databases after a major reorganization. In that situation, there is not much I can do as I am not going to start patching coin daemons in which I am not a developer for.   (This is not the case here. I am referring to another coin.)

This is one of the advantages of moving to a sponsored system for the explorers. Once people have a vested interest in something, they are much more apt to give me a heads up when these types of things occurred. Again, not the case here, I knew about the Jul 4 fork but did not know it caused a major reorganization that occurred outside the check parameters.

Anyway, I will start on the database reconstruction. It might take a day or so because of the size of the CAP block chain.

Do I need to recreate the database on the explorer? When did this roll-back occur?

Mine too. But something weird is going on, check out this transaction ID at http://cap.cryptocoinexplorer.com: 5a2c52bd5b87031c2debf72e226fa13a131841188106101f5d019a2b100d5b1e transaction coming from nowhere?

09:00:18

gettransaction e2815838e585a050dbfe060f48a6bfdfc28baff632b980a9a0cf0ea2e43256a9


09:00:18

{
"txid" : "e2815838e585a050dbfe060f48a6bfdfc28baff632b980a9a0cf0ea2e43256a9",
"version" : 1,
"time" : 1404483424,
"locktime" : 0,
"vin" : [
{
"txid" : "ddff9b5c56ffb4ca0b8df82438810c391dde369770a808ca784f36d6adfda5ea",
"vout" : 0,
"scriptSig" : {
"asm" : "3046022100e6b7b641b3f942f8427cb36ae0d25d580465bf5a0811f2b579fac7d1ef6d584d022100f2b8c9320ad44fea5dd3f3906fc829cfa6979dfe8fbd77133230e9f083dfa3c401 038797a20f7b93e4a2969870a2a4d9c0b5768916492dedaea94e426984101fde9b",
"hex" : "493046022100e6b7b641b3f942f8427cb36ae0d25d580465bf5a0811f2b579fac7d1ef6d584d022100f2b8c9320ad44fea5dd3f3906fc829cfa6979dfe8fbd77133230e9f083dfa3c40121038797a20f7b93e4a2969870a2a4d9c0b5768916492dedaea94e426984101fde9b"
},
"sequence" : 4294967295
}
],
"vout" : [
{
"value" : 0.00000000,
"n" : 0,
"scriptPubKey" : {
"asm" : "",
"type" : "nonstandard"
}
},
{
"value" : 3000.00000000,
"n" : 1,
"scriptPubKey" : {
"asm" : "038797a20f7b93e4a2969870a2a4d9c0b5768916492dedaea94e426984101fde9b OP_CHECKSIG",
"reqSigs" : 1,
"type" : "pubkey",
"addresses" : [
"EuGFoMB5JW3DJmKRkccRkuZ1SpBRp9Bo7v"
]
}
},
{
"value" : 3000.00000000,
"n" : 2,
"scriptPubKey" : {
"asm" : "038797a20f7b93e4a2969870a2a4d9c0b5768916492dedaea94e426984101fde9b OP_CHECKSIG",
"reqSigs" : 1,
"type" : "pubkey",
"addresses" : [
"EuGFoMB5JW3DJmKRkccRkuZ1SpBRp9Bo7v"
]
}
}
],
"blockhash" : "97e2c40a05b784ce8c57b0030c3da1626c9f27db121bac1801e2f49ed92c6f7e",
"confirmations" : 24166
}

OK. I originally thought that was the case but when the staking icon lit up 4 days ago I figured I was good to go. Oh well...