Can't open details window in global transaction ledger (Armory 0.96.2)

[Mr.Vice]

Since 0.96.2 there is a bug that doesn't allow the transaction details window to be opened in the global transaction ledger.
*** UPDATE: It seems that all transaction done prior to Armory 0.96.2 update are affected by this issue. ***

armorylog.txt

Code:

2017-09-07 11:32:20 (ERROR) -- Traceback (most recent call last):
  File "ArmoryQt.py", line 3334, in dblClickLedger
  File "ArmoryQt.py", line 3357, in showLedgerTx
  File "qtdialogs.pyc", line 5255, in __init__
  File "qtdialogs.pyc", line 5176, in extractTxInfo
  File "CppBlockUtils.pyc", line 2994, in getTxByHash
DbErrorMsg: <CppBlockUtils.DbErrorMsg; proxy of <Swig Object of type 'DbErrorMsg *' at 0x00000000072CE5D0> >

[1715623279]

1715623279

[goatpig]

Are you using DB_BARE?

[Mr.Vice]

Are you using DB_BARE?

Nope, haven't set any specific start arguments or armory settings file. I'm only using a custom datadir.
But I have checked older versions and that issue still remains. Recently I've re-donwlaoded the blockchain and since then I'm experiencing these issues. So maybe I've to do a rebuild and rescan?

[goatpig]

Try that for now.

[Mr.Vice]

I have also a issue with rebuild and rescan in this version. The building and scanning part works actually pretty well, but when the scanning is finished Armory immediately start to re-scan. I don't know why this happens...

dblog.txt

Code:

-INFO  - 13:28:10.969: (..\BlockchainScanner.cpp:852) scanned from block #483426 to #484061
-INFO  - 13:28:20.391: (..\BlockchainScanner.cpp:852) scanned from block #484062 to #484129
-INFO  - 13:28:21.438: (..\BlockchainScanner.cpp:214) scanned transaction history in 20239s
-INFO  - 13:29:43.031: (..\BlockchainScanner.cpp:1787) resolving txhashes
-INFO  - 13:34:04.875: (..\BlockchainScanner.cpp:1846) 455 blocks hit by tx filters
-INFO  - 13:34:46.953: (..\BlockchainScanner.cpp:1935) found 575 missing hashes
-INFO  - 13:34:46.984: (..\BlockchainScanner.cpp:1980) Resolved missing hashes in 302s
-INFO  - 13:34:46.984: (..\DatabaseBuilder.cpp:1231) verifying txfilters integrity
-INFO  - 13:34:46.266: (..\DatabaseBuilder.cpp:1314) done checking txfilters
-INFO  - 13:34:55.313: (..\BlockchainScanner.cpp:1787) resolving txhashes
-INFO  - 13:34:55.313: (..\BlockchainScanner.cpp:1846) 0 blocks hit by tx filters
-INFO  - 13:34:55.313: (..\BlockchainScanner.cpp:1935) found 0 missing hashes
-INFO  - 13:34:55.313: (..\BlockchainScanner.cpp:1980) Resolved missing hashes in 9s
-INFO  - 13:34:56.641: (..\lmdb_wrapper.cpp:388) Opening databases...
-INFO  - 13:34:56.844: (..\DatabaseBuilder.cpp:186) scanned new blocks in 20634s
-INFO  - 13:34:56.844: (..\DatabaseBuilder.cpp:190) init db in 20899s
-INFO  - 13:34:56.844: (..\BDM_supportClasses.cpp:1890) Enabling zero-conf tracking
-WARN  - 13:34:57.828: (..\BDM_supportClasses.cpp:1943) running 5 zc parser threads
-WARN  - 13:34:57.828: (..\BDM_supportClasses.cpp:1943) running 10 zc parser threads
-WARN  - 13:34:57.828: (..\BDM_supportClasses.cpp:1943) running 15 zc parser threads
-INFO  - 13:35:01.453: (..\BlockchainScanner.cpp:852) scanned from block #484130 to #484167
-INFO  - 13:35:01.469: (..\BDM_supportClasses.cpp:401) Starting address registration process
-WARN  - 13:35:28.875: (..\BDM_supportClasses.cpp:1943) running 20 zc parser threads
-WARN  - 13:35:28.891: (..\BDM_supportClasses.cpp:1943) running 25 zc parser threads
-WARN  - 13:35:37.672: (..\BDM_supportClasses.cpp:1943) running 30 zc parser threads
-INFO  - 13:35:40.219: (..\BlockchainScanner.cpp:857) scanned block #484168
-WARN  - 13:36:16.703: (..\BDM_supportClasses.cpp:1943) running 35 zc parser threads
-WARN  - 13:36:17.672: (..\BDM_supportClasses.cpp:1943) running 40 zc parser threads
-WARN  - 13:36:17.672: (..\BDM_supportClasses.cpp:1943) running 45 zc parser threads
-WARN  - 13:36:17.672: (..\BDM_supportClasses.cpp:1943) running 50 zc parser threads
-WARN  - 13:36:17.672: (..\BDM_supportClasses.cpp:1943) running 55 zc parser threads
-WARN  - 13:36:17.672: (..\BDM_supportClasses.cpp:1943) running 60 zc parser threads
-INFO  - 13:36:19.406: (..\BlockchainScanner.cpp:852) scanned from block #0 to #142691
-INFO  - 13:37:30.688: (..\BlockchainScanner.cpp:852) scanned from block #142692 to #170004
-INFO  - 13:38:40.281: (..\BlockchainScanner.cpp:852) scanned from block #170005 to #183110
-INFO  - 13:39:46.031: (..\BlockchainScanner.cpp:852) scanned from block #183111 to #189230
-INFO  - 13:40:55.609: (..\BlockchainScanner.cpp:852) scanned from block #189231 to #194895
-WARN  - 13:41:23.531: (..\BDM_supportClasses.cpp:1943) running 65 zc parser threads
-INFO  - 13:42:34.516: (..\BlockchainScanner.cpp:852) scanned from block #194896 to #200879
-INFO  - 13:43:59.281: (..\BlockchainScanner.cpp:852) scanned from block #200880 to #206654
-INFO  - 13:45:30.984: (..\BlockchainScanner.cpp:852) scanned from block #206655 to #211835
-INFO  - 13:46:59.828: (..\BlockchainScanner.cpp:852) scanned from block #211836 to #216013
-INFO  - 13:48:21.781: (..\BlockchainScanner.cpp:852) scanned from block #216014 to #219400
-INFO  - 13:49:37.609: (..\BlockchainScanner.cpp:852) scanned from block #219401 to #222889
-INFO  - 13:50:45.188: (..\BlockchainScanner.cpp:852) scanned from block #222890 to #226014
-INFO  - 13:52:10.563: (..\BlockchainScanner.cpp:852) scanned from block #226015 to #229700
-INFO  - 13:52:28.063: (..\BlockchainScanner.cpp:857) scanned block #484169
-INFO  - 13:53:11.781: (..\BlockchainScanner.cpp:857) scanned block #484170
-INFO  - 13:53:17.125: (..\BlockchainScanner.cpp:852) scanned from block #229701 to #232827
-INFO  - 13:54:37.609: (..\BlockchainScanner.cpp:857) scanned block #484171
-INFO  - 13:54:53.438: (..\BlockchainScanner.cpp:857) scanned block #484172

...during the second scan, which immediately occured after the first one I've gotten a readFromSocket thread exception. Currently I'm doing a fresh rebuild & rescan with 0.96.1.2-testing. Probably there isn't much difference between the lastest testing and release version, but I'm trying my luck...

[Mr.Vice]

This issue can be tagged as soleved.

Even though I've deinstalled McAfee AV a long time ago this piece of software still hurts my neck. Because I've found out that it isn't enough to just deinstall it. In order to completely remove every "service" that is linked to it, you'll have to download a tool called "MCPR.exe" from the official McAfee website that is able to remove everything that still recides on your PC.

This tool can be found under this link: http://us.mcafee.com/apps/supporttools/mcpr/mcpr.asp

That address book issues also had been related to the german locale settings. When you're using it then you're unable to select addresses (especially when using multisig lockboxes). So after switching to English (us) everything works like it should. That would explain why you haven't encountered any of this issues.

[goatpig]

This issue can be tagged as soleved.

Even though I've deinstalled McAfee AV a long time ago this piece of software still hurts my neck. Because I've found out that it isn't enough to just deinstall it. In order to completely remove every "service" that is linked to it, you'll have to download a tool called "MCPR.exe" from the official McAfee website that is able to remove everything that still recides on your PC.

This tool can be found under this link: http://us.mcafee.com/apps/supporttools/mcpr/mcpr.asp

That address book issues also had been related to the german locale settings. When you're using it then you're unable to select addresses (especially when using multisig lockboxes). So after switching to English (us) everything works like it should. That would explain why you haven't encountered any of this issues.

So the take home is copy to clipboard is botched with non ASCII character sets?

As for McAfee, was it messing with your blockchain data or Armory's DB?

[Mr.Vice]

So the take home is copy to clipboard is botched with non ASCII character sets?

Yes. That's pretty strange. When I'm using german locale settings I can't select addresses via button in the address book, because Armory can't copy it in ASCII character format. As a work-around you can right-klick and copy the address and paste it into the field. When you do this Armory can identify which wallet this address belongs to. So probabbly the clipboard stores non ASCII chars and when you paste them into the text field Armory converts them back into ASCII?

But that work-around doesn't work with Lockboxes. When you create a new one and copy and paste addresses of wallets it says that a unvalid address was entered. Although it identifies the wallet that address is related to.

As for McAfee, was it messing with your blockchain data or Armory's DB?

It was messing with Armory's DB.

[goatpig]

Yes. That's pretty strange. When I'm using german locale settings I can't select addresses via button in the address book, because Armory can't copy it in ASCII character format. As a work-around you can right-klick and copy the address and paste it into the field. When you do this Armory can identify which wallet this address belongs to. So probabbly the clipboard stores non ASCII chars and when you paste them into the text field Armory converts them back into ASCII?

Armory uses the pyQt4 clipboard interface which is pretty buggy actually. I'm guessing that what can't handle non ASCII data.

[Mr.Vice]

Armory uses the pyQt4 clipboard interface which is pretty buggy actually. I'm guessing that what can't handle non ASCII data.

Ok, I see. If there is a interface that is capable of unicode, it should cover most of the locales supported by Armory.

I have another question - I know this is off-topic but there are already so many topics opened, that would be like a data package with a header of 90%.
Since I've been using the address book many times - with german locale settings - I think that may have caused an error. Because I've been able to use/generate a P2SH-P2PK address that was 100 indices from my current address count away. Now my question is if every address I will generate in the future will dismiss 100 unused addresses in between?
I accidently transfered some BTC to that address :-/ My address count then jumped to 166 instead 66...

[goatpig]

Ok, I see. If there is a interface that is capable of unicode, it should cover most of the locales supported by Armory.

This is more of a python2 thing than Qt4 really. The solution would be python3, but at this rate might as well do Qt5, which is a task on its own and pretty much at the bottom of the list atm.

The wallet used index is increment only, regardless of what address type you request.

[Mr.Vice]

Ok, I see. If there is a interface that is capable of unicode, it should cover most of the locales supported by Armory.

This is more of a python2 thing than Qt4 really. The solution would be python3, but at this rate might as well do Qt5, which is a task on its own and pretty much at the bottom of the list atm.

The wallet used index is increment only, regardless of what address type you request.

Ok, thx for the info! It is really no big deal, as long as in english [us] locale everything is working well ;-)

Now I get it!! There were already indices 67-166 pre-generated P2PKH ones ;-)
I've forgotten that Armory always reserves a pool of pre-generated addresses, which are displayed in the unused addresses expander...