Quote from: HowlingMad on June 15, 2014, 01:54:24 PM

I noticed a problem with 0.91.2 -
I had recently re-installed everything on my computer and rebuilt everything. With Armory, I had loaded the first two wallets that I have and processed the block chain until the balances were shown.

I added a fourth wallet and Armory has sat at "Scanning Transaction History" and "100%" for almost an hour. The last entries in the log are:
INFO - 1402836130: (..\BlockUtils.cpp:4567) Scanning Wallet #1 from height 0
-INFO - 1402836131: (..\BlockUtils.cpp:4567) Scanning Wallet #2 from height 0
-INFO - 1402836138: (..\BlockUtils.cpp:4567) Scanning Wallet #3 from height 0
-INFO - 1402836145: (..\BlockUtils.cpp:4567) Scanning Wallet #4 from height 0
-INFO - 1402836146: (..\BlockUtils.cpp:4888) Saving wallet history to DB
-INFO - 1402836146: (..\BlockUtils.cpp:5920) Enabling zero-conf tracking (lite)
-DEBUG - 1402836657: (..\BlockUtils.cpp:5599) Organizing chain
-DEBUG - 1402836657: (..\BlockUtils.cpp:5723) Done organizing chain
-DEBUG - 1402836657: (..\BlockUtils.cpp:5599) Organizing chain
-DEBUG - 1402836657: (..\BlockUtils.cpp:5723) Done organizing chain
-INFO - 1402836657: (..\BlockUtils.cpp:5143) Added new blocks to memory pool: 2
-INFO - 1402836657: (..\BlockUtils.cpp:4888) Saving wallet history to DB

I am using a Lenovo V570 laptop with Win 7 Home x64. Cpu 25% utilized and 5Gb RAM free. If I restart Armory, it states 18 minutes to scan transactions.

Is there are problem in using Bitcoin Core? or something else going on?
Thanks,

https://bitcoinarmory.com:8443

Make a ticket and attach your log file (the whole thing)

Quote from: chrisrico on June 15, 2014, 03:28:37 AM

Quote from: teste on June 15, 2014, 02:37:58 AM

Quote from: teste on June 15, 2014, 02:30:58 AM

Why Bitcoin-Qt Core is able to recover syncronization from hibernation and Armory cant?

When this be implemented, will help in any way?: https://github.com/bitcoin/bitcoin/issues/4124

No, that won't help. Armory is using mlock to help store your keys securely.

Quote

mlock() locks part of the calling process's virtual address space into RAM, preventing that memory from being paged to the swap area

The goal here is that your unencrypted private keys are never written to disk (swap) where they could more easily be recovered.

Thats the gist of it, but it isnt limited to unencrypted private key. Pretty much anything crypto (public keys included) is held in mlock'ed memory.