No, I'm sorry if I wasn't clear. Those were two different events, not connected in anyway. I have had this problem with connecting, downloading blocks and finally seeing my transactions for a long time BEFORE my system crashed for a completely unrelated reason.
This problem started several months ago when I requested one bitcoin from an online wallet to be sent to an Armory address before ever snychronizing and downloading the block chain. I think this was a big mistake because I never had the downloaded any blocks even on previous version of Armory and Core.
It's preferable to get Core and Armory sync'ed before sending coins to your wallets. Some people don't realize the hardware requirements for Armory are kinda high. I'm not sure if you are experiencing the known issue on 0.93 (for which we are currently testing a fix), or if it's a setup issue. At any rate, you should produce some log files. |
|
|
|
I've no idea if it's related to this branch, but I sent you the full logs just in case.
In the support channel? Ticket #? Or did you add a link to this thread, or asked for me by name? The migration to the new ticket system left the support channel in a weird state. Sorry, I should have been more specific. Ticket: ARMORY00000469, I did mention your name in the ticket body. Ok great |
|
|
|
I've no idea if it's related to this branch, but I sent you the full logs just in case.
In the support channel? Ticket #? Or did you add a link to this thread, or asked for me by name? The migration to the new ticket system left the support channel in a weird state. |
|
|
|
Is there any other setting that I need to change when I turn off bitcoinQT auto-management in Armory? When I manually start bitcoinQT and armory, I can not get armory to connect to the network at all. Nothing happens when I click the "Go Online" button. I have unchecked the "Let armory run bitcoinQT/bitcoind" option. Is there another option that I am missing, perhaps in some config file somewhere?
1) Start BitcoinQt, let it sync 2.a) If you are using a custom folder for BitcoinQt's block data, you have to tell Armory where to look. Assume you are using C:\Bitcoin for your BitcoinQt folder (you are running BitcoinQt with the -datadir="C:\Bitcoin" argument), you need to run Armory with the --satoshi-datadir="C:\Bitcoin" argument. 2.b) Under certain conditions Armory fails to automatically resolve your Core blocks folder, even if it's in the default location. In this case you'll have to force that path with the --satoshi-datadir arg. 3) Start Armory, it should figure find the running BitcoinQt instance right away. Otherwise, log files. |
|
|
|
Download 0.93 for Windows XP, Vista, 7, 8+ (32- and 64-bit) - this is what Download page on Armory official site states. So they claim that 0.93 is 32-bit compatable  More like we forgot to relabel the link properly. |
|
|
|
I'm afraid it's all true! ArmoryQt.exe isn't a valid Win32 application, and that's a problem with your offline XP machine as it appears to be 32-bit windows. Armory 0.93.0 is all 64-bit. I think goatpig may have promised a 32-bit Windows build of 0.93.next-sub-version. If not, 92.3 still uses the same format for signatures, so you'll be OK no matter what.
I have promised that, that's true. I hope to still make it happen but I can give no guarantee the x86 build will run on XP. The current version will build in x86 btw, if you are brave enough to setup the Windows build env (I should write a howto) |
|
|
|
After instalation and launch of 0.93 on Win XP got "C:/......./ArmoryQt.exe is not valid Win32 application" Need to roll back to 0.92.3 Will my 0.93 on-line Armory/Win 7 properly communicate with 0.92.3/ Win XP used as offline ? Yes, 0.92.x can manage wallets and sign transactions created from 0.93 |
|
|
|
This appears in the log every time it encounters a new block: -ERROR - 1425181756: (..\StoredBlockObj.cpp:1863) We should've found an unpsent txio in the subSSH but didn't
-ERROR - 1425181756: (..\BlockUtils.cpp:1585) Error adding block data: missing txio! Also, maybe related, I have these lines repeated many times in my log files, from 2-20: 2015-02-20 18:17 (ERROR) -- Traceback (most recent call last):
File "armorymodels.pyc", line 1102, in data
File "CppBlockUtils.pyc", line 1729, in getScrAddrObjByKey
RuntimeError: no ScrAddr matches key
2015-02-20 18:17 (ERROR) -- Traceback (most recent call last):
File "armorymodels.pyc", line 1169, in data
File "CppBlockUtils.pyc", line 1729, in getScrAddrObjByKey
RuntimeError: no ScrAddr matches key
2015-02-20 18:17 (ERROR) -- Traceback (most recent call last):
File "armorymodels.pyc", line 1128, in data
File "CppBlockUtils.pyc", line 1729, in getScrAddrObjByKey
RuntimeError: no ScrAddr matches key
-ERROR - 1425164415: (..\BlockWriteBatcher.cpp:429) STXO needs to be re-added/marked-unspent but it
-ERROR - 1425164415: (..\BlockWriteBatcher.cpp:430) was already declared unspent in the DB
-WARN - 1425164415: (..\StoredBlockObj.cpp:1883) failed to erase txio in subshh: doesn't exist!
I just realized you are using supernode =P. I'm halfway through what I expect is the last change to the DB structure, it will speed up the scanning, with more scalability and stability, and will nuke this issue among others. That'll be packed with the extra slim fullnode version, but it won't be the release we'll put out this week. That one is for emergency bug fixes. |
|
|
|
|
How often does this happen? Is it always the same address?
|
|
|
|
|
updated the fix some more, people running this fix please pull and build again.
|
|
|
|
I hit the BDM error yesterday. I'm running the 0.93-bugfix branch as of this afternoon. The initial rebuild finished without issue.
I'll post back if I see any of the new log messages in armorycpplog (none so far).
You can quick search for the word "repair". If that shows up, you had the issue again, and the fix worked. |
|
|
|
|
Most of that RAM is shareable, means the OS will give it to other processes were they to ask for it. The whole point is they didn't, so the OS allowed Armory to use the free RAM to run faster. There's a critical difference here. If a process is denied memory, it will crash. Shareable memory won't be denied to other process and Armory wouldn't crash either if it had less than the token 26GB it is using on your system, it would simply scan slower.
If you restart Armory once it has scanned, you will realize it will only need about 200~300 MB of RAM, since it doesn't have to process the whole blockchain over.
|
|
|
|
Both of you will need the fix in https://bitcointalk.org/index.php?topic=970983.0If you build the binaries on your own, just go ahead and pull the fix and try it out. If you depend on the release builds, turn off bitcoind auto-management and run BitcoinQt manually, this will mitigate the issue. You will have to rebuild and rescan if you are going to use BitcoinQt as it won't fix the issue, just prevent it from reoccurring. The fix will repair bad DBs on its own though. |
|
|
|
|
I do expect this issue to occur only after bitcoind catches up a day or two worth of blocks. I hope some people will try it over the weekend and give me positive responses as well, although ideally I'd like them to try it once for the sanity check and once more a few days later to confirm the fix.
Also, if everything went well, I'd appreciate seeing log files, which will carry the markers for the DB error and the confirmation it was repaired.
|
|
|
|
Also your master branch as of 25248a752364afa91b4701f5b28b203ecd8364f2 doesn't build:
This commit is in dev, and dev is unstable currently. I was stopped halfway through a big change to go after the BDM error issue. |
|
|
|
|
I've pushed a tentative fix in branch 0.93-bugfix. If you build Armory yourself, please pull and test away. We're planning on releasing a build to cover the bugs that made it past the testing phase sometimes next week. This fix in particular we'd like to have some testing on before that upcoming release.
As usual, thank you for your patience, and happy testing =)
|
|
|
|
|
Extend the address chain for that wallet, it should recompute the highest used address index.
|
|
|
|
Armory 0.93 does not work for me, I though it was due to Armory being on a fuse NTFS partition on Debian ( thread), but even on an ext4 partition it fails to sync and also fails at building the database  . Force your bitcoin folder with --satoshi-datadir, the path auto detect is failing somehow. |
|
|
|
|
Show Posts
