PM'd you. Sorry don't have access to my two step auth. for my email.
Edit: I'm thinking it is because Armory is loosing connection to bitcoind. I've just woke up and started Armory, and it show 30 less blocks the "bitcoind getblockcount" does.
I do have restrictive iptables in places, but this has never effected bitcoind/qt in the past, however, it seems disabling my firewall stop Amory from moaning about disconnects/reconnects for the first few seconds on startup and it displayed the correct block count.
Not sure if this is the issue (I'm struggling to see how it would), just a bit of a coincidence.
FYI, Armory connects to bitcoin-qt/d via sockets (via python-twisted) on localhost over port 8333. Is that potentially an issue?
I just looked through the log file you sent me, and I see the most interesting thing:
...
2012-10-30 15:10 (INFO) -- ArmoryQt.py:2339 - New Block! : 205678
2012-10-30 15:10 (INFO) -- ArmoryQt.py:2339 - New Block! : 205678
2012-10-30 15:10 (INFO) -- ArmoryQt.py:2339 - New Block! : 205678
2012-10-30 15:10 (INFO) -- ArmoryQt.py:2339 - New Block! : 205678
2012-10-30 15:10 (INFO) -- ArmoryQt.py:2339 - New Block! : 205678
2012-10-30 15:10 (INFO) -- ArmoryQt.py:2339 - New Block! : 205678
2012-10-30 15:10 (INFO) -- ArmoryQt.py:2339 - New Block! : 205678
2012-10-30 15:10 (INFO) -- ArmoryQt.py:2339 - New Block! : 205678
2012-10-30 15:10 (INFO) -- ArmoryQt.py:2339 - New Block! : 205678
2012-10-30 15:11 (INFO) -- ArmoryQt.py:2339 - New Block! : 205678
2012-10-30 15:11 (INFO) -- ArmoryQt.py:2339 - New Block! : 205678
2012-10-30 15:11 (INFO) -- ArmoryQt.py:2339 - New Block! : 205678
2012-10-30 15:11 (INFO) -- ArmoryQt.py:2339 - New Block! : 205678
2012-10-30 15:11 (INFO) -- ArmoryQt.py:2339 - New Block! : 205678
2012-10-30 15:11 (INFO) -- ArmoryQt.py:2339 - New Block! : 205678
2012-10-30 15:12 (INFO) -- ArmoryQt.py:2339 - New Block! : 205678
2012-10-30 15:15 (INFO) -- ArmoryQt.py:2339 - New Block! : 205678
2012-10-30 15:22 (INFO) -- ArmoryQt.py:2339 - New Block! : 205678
2012-10-30 15:29 (INFO) -- ArmoryQt.py:2339 - New Block! : 205678
2012-10-30 15:32 (INFO) -- ArmoryQt.py:2339 - New Block! : 205678
2012-10-30 15:51 (INFO) -- ArmoryQt.py:2339 - New Block! : 205678
2012-10-30 15:52 (INFO) -- ArmoryQt.py:2339 - New Block! : 205678
2012-10-30 16:06 (INFO) -- ArmoryQt.py:2339 - New Block! : 205678
2012-10-30 16:09 (INFO) -- ArmoryQt.py:2339 - New Block! : 205678
2012-10-30 16:21 (INFO) -- ArmoryQt.py:2339 - New Block! : 205678
...
I have
no idea what could be causing that (it's the first time I've ever seen that). But it looks like a good explanation for why nothing is being updated.
The logic in the code goes like this:
(1) Check the blk000X.dat file for updates
(2) If there are updates, read in the new data, add the header to the header map
(3) Re-calculate the longest header chain (which may involve a re-org)
(4) Write "New Block! :
" to log file
So, for some reason, Armory is detecting new blockfile updates, but after the blockchain update, it thinks that the main chain was not extended. Unfortunately, when there are re-orgs or errors in the underlying C++ code, that doesn't get written to the log file (it's too difficult to capture it from python).
I'm going to have to spend some time thinking about how this could possibly be happening (difficulty-bits conversion-to-float error?). Thanks for the log-file... maybe I'll figure out what's so special about your system! By the way, if you don't mind re-downloading the blockchain in Bitcoin-Qt, I would appreciate you trying that. Go to your ~/.bitcoin directory and delete all the blk000*.dat files, then restart Bitcoin-Qt. In the past, I've seen bizarre Armory behavior when something unusual showed up in the stored blockchain data (I don't know what, but I know that many people who reported bizarre behavior saw it go away when they re-built their block files this way).
Thanks for your patience!