Everything seemed to run fine in 32bit up until the last stable version 0.93.
New DB engine |
|
|
|
so aside from my previous reply I'm still waiting for a reply on, will the next version actually include Windows 32 bit? I ask because it seems you're latest reply suggests that we're still focusing on 64 bit for Windows.
No, this version is just for bug fixes, you'll have to wait for the version with DB changes. Loooooooovely. No point building a x86 version that can't run in x86 anyways. |
|
|
|
so aside from my previous reply I'm still waiting for a reply on, will the next version actually include Windows 32 bit? I ask because it seems you're latest reply suggests that we're still focusing on 64 bit for Windows.
No, this version is just for bug fixes, you'll have to wait for the version with DB changes. |
|
|
|
Well I went ahead and loaded the newest core and newest Armory and now 2 months of transactions are MIA. I tried to re scan databases with no luck. Currently I have it rebuilding the database looks like it will take a lot of time. Any other suggestions to try? I really like Armory, but it has been flaky for me as of late.
Edit: the balances do show correct, but all the tx and comments are not showing.
Play with the wallet filter. |
|
|
|
So, I've discovered that if you quit Armory when it reports "Bitcoin Engine Initializing", Armory doesn't end the bitcoind process at all. Even if the progress bar is active and the number of remaining blocks is shown.
That's weird, guardian should be handling that. It's specifically meant to kill instances of bitcoind that have survived the parent Armory process. I'll investigate. |
|
|
|
Just to clarify.
Because of this latest bugfix we should avoid installing 0.93.0.80 for now and wait for a different revision number to be releaed.
Am I correct?
Avoid auto bitcoind in .0.80 |
|
|
|
|
Checkout bugfix, should be fixed now
|
|
|
|
I Rebuilt and Rescanned databases, which now means I'm up and running.
Again I urge you to not use auto-bitcoind, at least till it gets stable. Last testing build introduced a stupid bug, and your custom setup could do without auto-bitcoind, for the added control. Every log file you have submitted so far suggest you are letting Armory manage Core. |
|
|
|
This one does not work for me at all. Just gets stuck in the middle of the process and stays there.
Log files |
|
|
|
|
you should stop using auto bitcoind till your setup is stable. Again, the cpplog is more significant.
|
|
|
|
Buggy happenings in 0.93.0.80 (SDM on):
Consistent disconcerting startups. "Armory is disconnected" page remains up for several minutes, and "Blocks remaining" never appears, not even "0 Blocks remaining". Also noticeably more sluggish to shutdown than any of the builds of 93.0.70
These are being worked on as we speak |
|
|
|
|
Did you make sure there is enough disk space available?
|
|
|
|
What's your top block?
As of UTC 12:58, my top block is 347,196. However--and I've edited my original post to reflect this--after some digging I found out that my new transactions stopped after upgrading to 0.93. Displayed on Armory or Core? |
|
|
|
I'm getting a BDM error now:  Was using 0.93.0.70 supernode, Win 7 x64. After restarting computer and trying to start Armory as usual, Armory showed "missing txio" error message (above) and crashed. Tried to update to latest 0.93-bugfix branch (0.93.0.80, build 66702e78f5), and run from ArmoryQt.py, and had same error. This is preventing me from running Armory at all. Do I need to rebuild/rescan, wait for new version, or something else? Sent logs via https://support.bitcoinarmory.com/ site. For supernode stability you'll have to wait on the next installment of DB changes. You can rebuild and rescan to fix this error if you want but there is no guarantee the current version will not run into that same issue again. If you want to make this more stable for now, you can keep a copy of a freshly scanned supernode DB on the side and overwrite bad ones with that to cut on the rescan time. I'm not going after the error directly because it is too convoluted, and the upcoming changes fix that. I'll merge the new stuff in dev sometimes this week then you're welcomed to try that instead. Both build&scan time and stability will be improved. |
|
|
|
That's a band-aid fix. Ideally nothing should gets stuck, so the ugly progress bars are enough. From the sound of it, your Armory is stuck. If you want to help, gimme details about your VM setup and attach your log files.
The VM: 2gb memory 1 processor 2 cores Windows 10 tech preview* ArmoryLog: http://pastebin.com/yRMDMZJPNote that armory has crashed a few times today, and was outputting this error at yesterday. 2015-03-11 00:14 (INFO) -- announcefetch.pyc:271 - Fetching: https://bitcoinarmory.com/announce.txt
2015-03-11 00:14 (ERROR) -- announcefetch.pyc:283 - Specified URL was inaccessible
2015-03-11 00:14 (ERROR) -- announcefetch.pyc:284 - Tried: https://bitcoinarmory.com/announce.txt
2015-03-11 00:14 (INFO) -- announcefetch.pyc:271 - Fetching: https://s3.amazonaws.com/bitcoinarmory-media/announce.txt
2015-03-11 00:14 (ERROR) -- announcefetch.pyc:283 - Specified URL was inaccessible
2015-03-11 00:14 (ERROR) -- announcefetch.pyc:284 - Tried: https://s3.amazonaws.com/bitcoinarmory-media/announce.txt
*Because I didn't want to install another version of windows, I run windows 8 natively. The log file says it's running in Win8, did you give me the right one? Is BitcoinQt running fine and sync'ed fully? Also, get me armorycpplog.txt please. |
|
|
|
Because this is what I do to set up Armory & bitcoin-qt and I really wish it wasn't a 13 step process that takes moving gigabytes of data around and putting arguments in shortcuts.
If you want to run BitcoinQt without arguments you should look at bitcoin.conf. Your installation will be dependent on your /User/AppData folder however. Armory has no .conf and we should remedy that, I agree. We also had internal discussions about possibly adding a GUI feature to relocate the data folders. This is all extra work and not a priority as long as users don't voice their opinion on the matter. Consider that all these options are available through command line arguments because we prefer the less tech savvy users don't shoot themselves in the foot until we have a strong GUI option (if we ever do that is). Keep in mind that CLI args are really quick to implement, GUI equivalents, not so. But if you make the customization part easy it can be more convenient, I have a degree in computer science I'm not new to computers I know that if a person wants something to work for them they have to put some work in too, I just think the process could be easier is all I'm saying.
I understand your point entirely, but again there is a time and priority factor, and while this setup process is convoluted, our expert users rarely complain about it, and considering the accessibility, these are expect features. We don't have the man hours to throw at this currently. Maybe I'll abuse the prospect newbie with that stuff (if he signs with us). Don't get me wrong I'm not playing the blame game here, it was completely my fault. I'm just saying it was a bit shit that I had to start from scratch when something went wrong.
You're stuck between a rock and a hard place on this one. We moved to LMDB so Armory will handle that kind of abuse from 0.93 onward. Core is still using LevelDB and there are no plans to change that. Another suggestion I have is changing the way the UI displays what it's doing. This "Initialising Bitcoin Engine" with an empty progress bar and a six stage spinning icon* isn't great IMO, more detail into what it's doing and maybe an ETA, something to show me that it hasn't just given up and stopped.
*I'm putting Armory on a VM and I'm currently looking at that, and the spinning icon has actually stopped spinning and I'm pretty sure it's stopped writing data (or reading, who knows what it's doing) as well.
That's a band-aid fix. Ideally nothing should gets stuck, so the ugly progress bars are enough. From the sound of it, your Armory is stuck. If you want to help, gimme details about your VM setup and attach your log files. |
|
|
|
Still looking good. No BDM errors or activity in logs. Seems like my class of BDM error has been fixed by Monday's commits.
Glad to hear that. This version will get a build tomorrow, after some Core socket layer issues get fixed. |
|
|
|
-WARN - 1426014846: (..\BlockUtils.cpp:1074) Scanning from 287300 to 347035
-ERROR - 1426014865: (..\BlockWriteBatcher.cpp:963) No block in DB at height 287301
Your copy of the blockchain is missing block data for height 287301. No amount of rescanning will fix that, you need to boostrap anew. btw this is not cool guys even for beta this shouldnt be happening , you should test your stuff better
Did you participate in the month long public testing phase? |
|
|
|
Any WinAPI stuff and std code (which relies on WinAPI at the lower level in Windows) can deal with mixed slashes and double slashes. I really doubt that Armory can deal with file paths (on any OS) that include non-ASCII characters (Unicode support in Python 2 is a real pain, something that I'm happy was fixed in Python 3).
I fixed that in 0.91 but didn't bother reviving it yet in 0.93. I'll need to make LMDB unicode compliant for that purpose, and I'm more concerned with other bugs currently. Once the new DB code congeals, I will make the C++ code unicode ready once again. As for Python, we have a branch on which we are testing Python3, and intent to eventually move to that once it's stable on our end. |
|
|
|
|
Show Posts
