Please Help Test Armory 0.91-beta!

[justusranvier]

Armory sometimes gets into a infinite loop of connecting and disconnecting from the node.

It's triggered after a node loses Internet connectivity (maybe it's set up to connect through a proxy and the proxy goes down for some reason).

When connectivity is restored and the node starts to catch back up with the network, Armory will start connecting and disconnecting 1-2 times per second, with the GUI showing a "can not connect to node" error message.

Closing and reopening Armory (while doing nothing at all to the bitcoind node) resolves the problem.

[1713535426]

1713535426

[1713535426]

1713535426

[1713535426]

1713535426

[bitpop]

Armory sometimes gets into a infinite loop of connecting and disconnecting from the node.

It's triggered after a node loses Internet connectivity (maybe it's set up to connect through a proxy and the proxy goes down for some reason).

When connectivity is restored and the node starts to catch back up with the network, Armory will start connecting and disconnecting 1-2 times per second, with the GUI showing a "can not connect to node" error message.

Closing and reopening Armory (while doing nothing at all to the bitcoind node) resolves the problem.

I got that when Bitcoin runs out of connections but yours might d be different. It is possible a spot opened up while restarting tho

[goatpig]

I'm not sure this is the trigger. My connection at home is currently being very unstable, I get disconnected for tenths of minutes at time, all with Bitcoin core and Armory running, and I don't get this issue at all.

I've experienced on transaction broadcasts that get turned down. Overall I think this is related to ZC transactions. We don't have much on this one yet, and frankly it's low priority right now. I expect that I'll eventually run into it, and that usually enough to identify the cause and fix it.

[drrussellshane]

I think I found a bug... when I clicked on a new (unconfirmed) incoming transaction, and clicked "Open Relevant Wallet", the wallet that it opened was not relevant.

[aerobatic]

I think I found a bug... when I clicked on a new (unconfirmed) incoming transaction, and clicked "Open Relevant Wallet", the wallet that it opened was not relevant.

i'd like to report a bug in all versions of Mac Armory including 0.91 beta 0.90.99.5)

My Mac is set to sleep at 2am, and wake at 9am every day.  its part of the energy saver sleep modes (its not a power down, its just a suspended sleep)

Quite often, after the mac has been asleep, and woken up... Armory hangs and doesn't recover.  When i click into the Armory window, i see the Busy icon, which never goes away.  Armory has completely hung, it won't even quit gracefully and has to be 'force quit'd.   When i re-run it immediately after, its fine.   Bitcoin-QT is still running in the background, and is connected.

This is repeatable almost every day for me, as my mac sleeps every night and wakes every day.

wish you all the best, and good luck...  hope you can reproduce it too.

-- Jez

[doug_armory]

i'd like to report a bug in all versions of Mac Armory including 0.91 beta 0.90.99.5)

My Mac is set to sleep at 2am, and wake at 9am every day.  its part of the energy saver sleep modes (its not a power down, its just a suspended sleep)

Quite often, after the mac has been asleep, and woken up... Armory hangs and doesn't recover.  When i click into the Armory window, i see the Busy icon, which never goes away.  Armory has completely hung, it won't even quit gracefully and has to be 'force quit'd.   When i re-run it immediately after, its fine.   Bitcoin-QT is still running in the background, and is connected.

This is repeatable almost every day for me, as my mac sleeps every night and wakes every day.

wish you all the best, and good luck...  hope you can reproduce it too.

Hello. I just tried this a few times on my setup. I haven't been able to reproduce it yet. My suspicion is that this is a Qt (or maybe PyQt?) issue. I'll continue to look into it, though, and do some overnight sleeps.

Thanks for letting us know.

[L0rdCha0s]

Just reporting an issue I've seen in Armory 0.90.99.5

Outbound transactions seem to be 'disappearing' from the transaction list, but the wallet balance is correct, and you can still see the transaction if you go to the Addresses involved in the Wallet Properties and look at the Address's transaction list.

About the only unusual thing about my wallet is that it contains 4000 addresses (we're a bitcoin merchant services company).

Steps to reproduce

1. Environment: Ubuntu 13.04, Armory 0.90.99.5, Bitcoin Core 0.90
2. Create new offline transaction in online Armory (in my case,for the entire wallet balance).
3. Sign transaction offline
4. Broadcast transaction online.
5. The unconfirmed transaction does appear in the transaction list
6. Wait for a block
7. Outbound transaction suddenly disappears from transaction list, but the balance stays correct.

Has anyone else seen this?

EDIT: Confirming this doesn't happen in 0.90.x

[e4xit]

Armory sometimes gets into a infinite loop of connecting and disconnecting from the node.

It's triggered after a node loses Internet connectivity (maybe it's set up to connect through a proxy and the proxy goes down for some reason).

When connectivity is restored and the node starts to catch back up with the network, Armory will start connecting and disconnecting 1-2 times per second, with the GUI showing a "can not connect to node" error message.

Closing and reopening Armory (while doing nothing at all to the bitcoind node) resolves the problem.

justusranvier I solved this on my machine by editing my bitcoin.conf file to add 127.0.0.1 as a mandatory peer. This allowed Armory to maintain connection to Bitcoin-Qt(/d) even when Bitcoin-QT/d maxed out allowed peers with external nodes.

I may have misinterpreted your problem though.

[goatpig]

I think I found a bug... when I clicked on a new (unconfirmed) incoming transaction, and clicked "Open Relevant Wallet", the wallet that it opened was not relevant.

Unattended consequences of the transaction ledger mess up in .4 and .5

I think I found a bug... when I clicked on a new (unconfirmed) incoming transaction, and clicked "Open Relevant Wallet", the wallet that it opened was not relevant.

i'd like to report a bug in all versions of Mac Armory including 0.91 beta 0.90.99.5)

My Mac is set to sleep at 2am, and wake at 9am every day.  its part of the energy saver sleep modes (its not a power down, its just a suspended sleep)

Quite often, after the mac has been asleep, and woken up... Armory hangs and doesn't recover.  When i click into the Armory window, i see the Busy icon, which never goes away.  Armory has completely hung, it won't even quit gracefully and has to be 'force quit'd.   When i re-run it immediately after, its fine.   Bitcoin-QT is still running in the background, and is connected.

This is repeatable almost every day for me, as my mac sleeps every night and wakes every day.

wish you all the best, and good luck...  hope you can reproduce it too.

-- Jez

May or may not be a Qt issue. We are moving to a more scalable model in 0.91.1, which will introduce a comminucation framework that will be a lot more resilient to this kind of desyncing between Armory's frontend/backend/Bitcoin core

Just reporting an issue I've seen in Armory 0.90.99.5

Outbound transactions seem to be 'disappearing' from the transaction list, but the wallet balance is correct, and you can still see the transaction if you go to the Addresses involved in the Wallet Properties and look at the Address's transaction list.

About the only unusual thing about my wallet is that it contains 4000 addresses (we're a bitcoin merchant services company).

Steps to reproduce

1. Environment: Ubuntu 13.04, Armory 0.90.99.5, Bitcoin Core 0.90
2. Create new offline transaction in online Armory (in my case,for the entire wallet balance).
3. Sign transaction offline
4. Broadcast transaction online.
5. The unconfirmed transaction does appear in the transaction list
6. Wait for a block
7. Outbound transaction suddenly disappears from transaction list, but the balance stays correct.

Has anyone else seen this?

EDIT: Confirming this doesn't happen in 0.90.x

Related to the transaction ledger snafu too. All this will be fixed in .6, which CircusPeanut is currently help me test.

[etotheipi]

Alright, lots of the issues with 0.90.99.5 have been resolved, and pushed to 0.90.99.7.  I just pushed the new version along with notifications.  Hopefully the notifications will actually work properly this time (no more "You are using version X+1 please upgrade to X+1!").

[qnxt]

Alright, lots of the issues with 0.90.99.5 have been resolved, and pushed to 0.90.99.7.  I just pushed the new version along with notifications.  Hopefully the notifications will actually work properly this time (no more "You are using version X+1 please upgrade to X+1!").

Still broken.

https://i.imgur.com/sVCdvX1.png

(I downloaded from the web, not via the secure downloader. Also, I put the new version in ~/Desktop instead of /Applications, where 0.90.99.5 is.)

[SimonBelmond]

Alright, lots of the issues with 0.90.99.5 have been resolved, and pushed to 0.90.99.7.  I just pushed the new version along with notifications.  Hopefully the notifications will actually work properly this time (no more "You are using version X+1 please upgrade to X+1!").

Just updated Bitcoin Core and Armory and all worked like a charm. So pleased to see the Armory-Team being well earthed and constantly improving. The work you guys are doing is awesome and absolutely key to the development of Bitcoin and Co. I congratulate and thank you guys. The new features are cool and I know there is lots more in the pipeline.

Still had to click away the message mentioned above though. ;-) Shall I use the bug reporting? ;-)

[Finnminer]

Updated from the perfectly working .4 to .5 and it's now back to unusable.

A ton of these in the log:

Code:

2014-04-02 10:17 (ERROR) -- BDM.pyc:252 - BDM was not ready for your request!  Waited 20 sec.
2014-04-02 10:17 (ERROR) -- BDM.pyc:253 -   getattr   name: getTopBlockHeight
2014-04-02 10:17 (ERROR) -- BDM.pyc:254 - BDM currently doing: Passthrough (14133058)
2014-04-02 10:17 (ERROR) -- BDM.pyc:255 - Waiting for completion: ID= 81876446
2014-04-02 10:17 (ERROR) -- BDM.pyc:256 - Direct traceback
2014-04-02 10:17 (ERROR) -- BDM.pyc:259 - Traceback:
Traceback (most recent call last):
  File "armoryengine\BDM.pyc", line 249, in passthruFunc
  File "Queue.pyc", line 176, in get

I'm happy to report that this problem is fixed in .7.

[Carlton Banks]

• Coinbase tx's still don't respond to view details (since 0.90.99.4)
• Text colour in mouse-over "# of confirmations" tag is just off-black, (it was previously white of course). Not at all easy to read near-black text on a black background
• Seems to take quite a while (1-2 mintues) to go from finishing wallet consistency check to showing a number in the progress bar for database preparation. 0.90.99.4 was pretty snappy for that

bitcoin core 0.9.0, Ubuntu 12.04

[L0rdCha0s]

Related to the transaction ledger snafu too. All this will be fixed in .6, which CircusPeanut is currently help me test.

Perfect! Works great in 0.90.99.7

[goatpig]

Broken Notification: working on it as we speak

• Coinbase tx's still don't respond to view details (since 0.90.99.4)
• Text colour in mouse-over "# of confirmations" tag is just off-black, (it was previously white of course). Not at all easy to read near-black text on a black background
• Seems to take quite a while (1-2 mintues) to go from finishing wallet consistency check to showing a number in the progress bar for database preparation. 0.90.99.4 was pretty snappy for that

bitcoin core 0.9.0, Ubuntu 12.04

Thanks for the report.

Regarding the 3rd issue, .4 was populating the ledger partially, so that's not a fair comparison. This will be much snappier in 0.91.1, with the push model backend.

Will look into the other ones.

[qnxt]

0.90.99.7 is occasionally freezing on me on OS X 10.9.2, just sitting at the main window idle. I've only noticed so far when switching back after leaving it in the background for a while. It beachballs and shows "Disconnected", without me being able to do anything. The first few times it did that, it came back after 3 - 5 minutes, but it just got stuck for about 20 or 30 minutes before I did a force quit.

Last logfile entry:
2014-04-04 19:25 (INFO) -- announcefetch.py:249 - Fetching: https://s3.amazonaws.com/bitcoinarmory-media/announce.txt?ver=0.90.99.7
(Is there some additional logging level I failed to turn on?)

Doesn't use up much CPU when it's doing that, either.

[mattbit]

Since a week ago, Armory is constantly crashing at 23% when scanning transaction history.  I was using the previous stable release and tried upgrading to the beta version but it's still happening.  Here is the log:

Log file opened at 1396656691: /home/matt/.armory/armorycpplog.txt
-INFO  - 1396656693: (BlockUtils.cpp:2311) Set home directory:
-INFO  - 1396656695: (BlockUtils.cpp:2333) Set blkfile dir: /home/matt/.bitcoin/blocks
-INFO  - 1396656695: (BlockUtils.cpp:2343) Set leveldb dir: /home/matt/.armory/databases
-INFO  - 1396656695: (BlockUtils.cpp:2299) SetBtcNetworkParams
-INFO  - 1396656695: (BlockUtils.cpp:4337) Executing: doInitialSyncOnLoad
-INFO  - 1396656695: (BlockUtils.cpp:4378) Number of registered addr: 1257
-INFO  - 1396656695: (leveldb_wrapper.cpp:399) Opening databases...
-DEBUG - 1396656695: (BlockUtils.cpp:4390) Called build&scan with (0,0,0,1)
-INFO  - 1396656697: (BlockUtils.cpp:2424) Total blk*.dat files:                 130
-INFO  - 1396656697: (BlockUtils.cpp:2442) Current Top block in HEADERS DB:  294168
-INFO  - 1396656697: (BlockUtils.cpp:2443) Current Top block in BLKDATA DB:  294168
-INFO  - 1396656697: (BlockUtils.cpp:2444) Current Applied blocks up to hgt: 0
-DEBUG - 1396656700: (BlockUtils.cpp:5597) Organizing chain w/ rebuild
-DEBUG - 1396656701: (BlockUtils.cpp:5721) Done organizing chain
-INFO  - 1396656703: (BlockUtils.cpp:2545) First unrecognized hash file:       129
-INFO  - 1396656703: (BlockUtils.cpp:2546) Offset of first unrecog block:      29280764
-INFO  - 1396656703: (BlockUtils.cpp:2555) First blkfile not in DB:            129
-INFO  - 1396656703: (BlockUtils.cpp:2556) Location of first block not in DB:  29280764
-INFO  - 1396656703: (BlockUtils.cpp:4423) Fetching stored script histories from DB
-INFO  - 1396656704: (BlockUtils.cpp:4465) Reading all headers and building chain...
-DEBUG - 1396656704: (BlockUtils.cpp:5597) Organizing chain w/ rebuild
-DEBUG - 1396656705: (BlockUtils.cpp:5721) Done organizing chain
-INFO  - 1396656712: (BlockUtils.cpp:4469) Total number of blk*.dat files: 130
-INFO  - 1396656712: (BlockUtils.cpp:4470) Total number of blocks found:   294169
-INFO  - 1396656712: (BlockUtils.cpp:4482) Getting latest blocks from blk*.dat files
-INFO  - 1396656712: (BlockUtils.cpp:4483) Total blockchain bytes: 17,337,233,740
-INFO  - 1396656712: (BlockUtils.cpp:4489) Parsing blockchain file: /home/matt/.bitcoin/blocks/blk00129.dat
-INFO  - 1396656712: (BlockUtils.cpp:4622) /home/matt/.bitcoin/blocks/blk00129.dat is 33,554,432 bytes
-INFO  - 1396656713: (BlockUtils.cpp:4503) Processed 1 raw blocks DB (0 seconds)
-INFO  - 1396656713: (BlockUtils.cpp:4535) Starting scan from block height: 0
-ERROR - 1396656927: (StoredBlockObj.cpp:1082) Cannot get tx copy, because don't have full StoredTx!

[etotheipi]

Since a week ago, Armory is constantly crashing at 23% when scanning transaction history.  I was using the previous stable release and tried upgrading to the beta version but it's still happening.  Here is the log:

....

Code:

-INFO  - 1396656713: (BlockUtils.cpp:4503) Processed 1 raw blocks DB (0 seconds)
-INFO  - 1396656713: (BlockUtils.cpp:4535) Starting scan from block height: 0
-ERROR - 1396656927: (StoredBlockObj.cpp:1082) Cannot get tx copy, because don't have full StoredTx!

Haven't seen this one in a while, but we think it's caused by building your DB with the old version and corrupt blk*.dat files from Bitcoin Core.  Since your DB is already built, you need to rebuild it with the new version.  We'd love to know if this fixes your problem -- because we actually haven't run into the "don't-have-full-tx" problem on any of our own systems before, so we can't test whether we fixed it!

So please use "Help"->Rebuild & Rescan Databases.  With some luck that fixes it.  If not, I recommend you do a factory reset and redownload the blockchain (because this is ultimately caused by bad blk*.dat files which will only be fixed with a redownload).  With the new bittorrent stuff, it's a heck of a lot faster than it used to be!

[Winterfrost]

Loaded the latest testing version, and now my wallets don't appear. Armory still thinks they're loaded though.

https://i.imgur.com/jUVe2HA.png

Edit: Nevermind. I rebooted and everything is back to normal. That's what I get for doing things late at night.