You must not be doing the symlinks correctly. It's probably best to avoid that, just use the satoshidir and datadir switches.
Definitely this. Try with the command line arguments (make a shortcut if you have to) and let us know.
Topic: RAM-Reduction & Backup Center Testing (version 0.89.99.16) - page 3. (Read 41311 times)
Definitely this. Try with the command line arguments (make a shortcut if you have to) and let us know.
I installed the Windows 64 bit .16 version over the .14, though not in C: but in a different drive. When I do this, the copy of the blockchain is deleted and I have to wait an hour for the database to build again. After this is done, my wallets are completely gone and I can't seem to find a good way of getting them back easily without resorting to paper backups. I'm not sure if this is default behaviour, but I can imagine this will scare the shit out of some people.
Edit: to clarify, it was originally installed in C:, the second time in a different drive. In both cased I had symbolic links made in AppData\Roaming\ to both the Armory and Bitcoin folders, located on a different drive. Oh and for some reason it takes about 15 minutes for Armory to get the database build each time I start it.
Edit: to clarify, it was originally installed in C:, the second time in a different drive. In both cased I had symbolic links made in AppData\Roaming\ to both the Armory and Bitcoin folders, located on a different drive. Oh and for some reason it takes about 15 minutes for Armory to get the database build each time I start it.
You must not be doing the symlinks correctly. It's probably best to avoid that, just use the satoshidir and datadir switches.
Windows 7 32bit lenovo T60 with 2 gig Ram. I am surprised that it runs at all! It does occasionally lock up, but it is usable. I am using the same machine with a TAILS USB for offline use. It seems to work fine in that environment.
I am thrilled! I can drop my watching wallets on the hard drive directly into the Windows Armory and my TAILS USB never needs to touch the Windows OS.
At some point I hope to write up a tutorial on how I set it up. It is a little tedious as I have not been able to make Armory persistent in TAILS yet and am reinstalling as needed. I keep the .armory in the Persistent archive.
I am thrilled! I can drop my watching wallets on the hard drive directly into the Windows Armory and my TAILS USB never needs to touch the Windows OS.
At some point I hope to write up a tutorial on how I set it up. It is a little tedious as I have not been able to make Armory persistent in TAILS yet and am reinstalling as needed. I keep the .armory in the Persistent archive.
I installed the Windows 64 bit .16 version over the .14, though not in C: but in a different drive. When I do this, the copy of the blockchain is deleted and I have to wait an hour for the database to build again. After this is done, my wallets are completely gone and I can't seem to find a good way of getting them back easily without resorting to paper backups. I'm not sure if this is default behaviour, but I can imagine this will scare the shit out of some people.
Edit: to clarify, it was originally installed in C:, the second time in a different drive. In both cased I had symbolic links made in AppData\Roaming\ to both the Armory and Bitcoin folders, located on a different drive. Oh and for some reason it takes about 15 minutes for Armory to get the database build each time I start it.
Edit: to clarify, it was originally installed in C:, the second time in a different drive. In both cased I had symbolic links made in AppData\Roaming\ to both the Armory and Bitcoin folders, located on a different drive. Oh and for some reason it takes about 15 minutes for Armory to get the database build each time I start it.
Hi,
Just a minor bug report. I'm running Ubuntu 13.04 64 bit. I managed to install 0.89.99.16 today (it's building the database now, and I'm looking forward to using the new version!). However I had a lot of headaches getting the installation to work. I downloaded the OfflineBundle but running the very simple install script f***ed up my package dependencies. I managed to resolve this by NOT installing the libqtwebkit4 in the bundle. I already had what I assume is the same version of this library, but installing the one in the bundle with dpkg somehow ran me into the following Launchpad bug: https://bugs.launchpad.net/ubuntu/+source/qtwebkit-source/+bug/1175902. Ultimately I escaped from the resulting dependency hellhole by using dpkg -i --force-overwrite to get back to the version of the deb in my apt cache.
I don't think this is an Armory bug per se, and I assume others have managed to install the 0.89.99.16 fine using the bundle on the website, but I thought I'd post this as a heads up in case anyone else runs into the same issue.
Just a minor bug report. I'm running Ubuntu 13.04 64 bit. I managed to install 0.89.99.16 today (it's building the database now, and I'm looking forward to using the new version!). However I had a lot of headaches getting the installation to work. I downloaded the OfflineBundle but running the very simple install script f***ed up my package dependencies. I managed to resolve this by NOT installing the libqtwebkit4 in the bundle. I already had what I assume is the same version of this library, but installing the one in the bundle with dpkg somehow ran me into the following Launchpad bug: https://bugs.launchpad.net/ubuntu/+source/qtwebkit-source/+bug/1175902. Ultimately I escaped from the resulting dependency hellhole by using dpkg -i --force-overwrite to get back to the version of the deb in my apt cache.
I don't think this is an Armory bug per se, and I assume others have managed to install the 0.89.99.16 fine using the bundle on the website, but I thought I'd post this as a heads up in case anyone else runs into the same issue.
Install 12.10 deb on 13.10 works.
On my system Ubuntu 13.10 v.99.16 seems to have a 'wait/watch' issue in transition from updating blockchain (bitcoind) to scanning the blockchain.
This is already happening a number of builds ago.
If all the blocks are already downloaded and Armory is started, Armory continues after this check.
When there are new blocks and the 'wait/watch' issue seems to be there, the --debug last info is: "(INFO) ArmoryQt.py:3781 - Switching Armory functional mode to "Offline" ".
Visually: Qt states "Synchronizing with Network x blocks" with x > 0 and stays that way. Now more counting down. Just continue to display only this information.
When only <10 new blockchain blocks, Armory does continue, with 92 blocks (last time I got this error) Armory gets in the 'wait/watch' modus.
Maybe only happens when there is a new block file?
I can try a rescan or a reinstall of bitcoind and Armory, but maybe you prefer some more error analysis before I do that or to try another build first.
Please let me know.
[EDIT] Today (11/25) Armory did not stop when it started with 152 blocks to download (bitcoind). The number of blocks to download is not the variable triggering the freeze.
On my system Ubuntu 13.10 v.99.16 seems to have a 'wait/watch' issue in transition from updating blockchain (bitcoind) to scanning the blockchain.
This is already happening a number of builds ago.
If all the blocks are already downloaded and Armory is started, Armory continues after this check.
When there are new blocks and the 'wait/watch' issue seems to be there, the --debug last info is: "(INFO) ArmoryQt.py:3781 - Switching Armory functional mode to "Offline" ".
Visually: Qt states "Synchronizing with Network x blocks" with x > 0 and stays that way. Now more counting down. Just continue to display only this information.
When only <10 new blockchain blocks, Armory does continue, with 92 blocks (last time I got this error) Armory gets in the 'wait/watch' modus.
Maybe only happens when there is a new block file?
I can try a rescan or a reinstall of bitcoind and Armory, but maybe you prefer some more error analysis before I do that or to try another build first.
Please let me know.
[EDIT] Today (11/25) Armory did not stop when it started with 152 blocks to download (bitcoind). The number of blocks to download is not the variable triggering the freeze.
OS X app crashes for me on Mavericks after a few minutes of use, too 
Luckily, picobit's build script is pretty easy, so it's not too hard to make new releases when I update the code. Though they will likely need extra testing, since OSX has a few quirks. I'm hoping he'll see this and try scanning his own package for hardcoded directories and figure out what's wrong (though, he is a busy guy...)
I got a few more polishing activities (actually, mainly updating the website and replacing the dead links in the app), and then I'll at least release the Windows and Linux versions. Perhaps early next week. But I won't post the OSX packages to the website as-is, since they are basically unusable...
I got a few more polishing activities (actually, mainly updating the website and replacing the dead links in the app), and then I'll at least release the Windows and Linux versions. Perhaps early next week. But I won't post the OSX packages to the website as-is, since they are basically unusable...
The .16 testing version, unfortunately, is pretty much unusable on my Mac. It's a recent model iMac (Core i5 3.2GHz, 8G RAM, no SSD). Scanning the blockchain brings the system to a crawl and makes doing anything else very frustrating. And this is exacerbated by the fact that once this completes Armory will usually crash within a short while so it has to rescan the blockchain every time it starts. I ran it from the command line and I can see something that I wonder could be part of the problem. There are leftover references to picobit's system in the errors it displays in Terminal. For example:
File "/Users/joeschmoe/BitcoinArmory/osx_picobit/workspace/Armory.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/Twisted-13.1.0-py2.7-macosx-10.4-x86_64.egg/twisted/internet/base.py", line 824, in runUntilCurrent
If there's any information I can provide to help fix this then I'd be glad to help
File "/Users/joeschmoe/BitcoinArmory/osx_picobit/workspace/Armory.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/Twisted-13.1.0-py2.7-macosx-10.4-x86_64.egg/twisted/internet/base.py", line 824, in runUntilCurrent
If there's any information I can provide to help fix this then I'd be glad to help
Interesting! Each next version seems to work less and less reliably on OSX. And for sure, that absolute path reference is ... not right.
Luckily, picobit just messaged me to let me know that he may have a solution (a variant of the current build recipe). I'm going to try it out tonight and see what happens.
Great! Looking forward to getting this working. The recent rise in the value of btc has me nervous every time I fire up Bitcoin-qt
The .16 testing version, unfortunately, is pretty much unusable on my Mac. It's a recent model iMac (Core i5 3.2GHz, 8G RAM, no SSD). Scanning the blockchain brings the system to a crawl and makes doing anything else very frustrating. And this is exacerbated by the fact that once this completes Armory will usually crash within a short while so it has to rescan the blockchain every time it starts. I ran it from the command line and I can see something that I wonder could be part of the problem. There are leftover references to picobit's system in the errors it displays in Terminal. For example:
File "/Users/joeschmoe/BitcoinArmory/osx_picobit/workspace/Armory.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/Twisted-13.1.0-py2.7-macosx-10.4-x86_64.egg/twisted/internet/base.py", line 824, in runUntilCurrent
If there's any information I can provide to help fix this then I'd be glad to help
File "/Users/joeschmoe/BitcoinArmory/osx_picobit/workspace/Armory.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/Twisted-13.1.0-py2.7-macosx-10.4-x86_64.egg/twisted/internet/base.py", line 824, in runUntilCurrent
If there's any information I can provide to help fix this then I'd be glad to help
Interesting! Each next version seems to work less and less reliably on OSX. And for sure, that absolute path reference is ... not right.
Luckily, picobit just messaged me to let me know that he may have a solution (a variant of the current build recipe). I'm going to try it out tonight and see what happens.
The .16 testing version, unfortunately, is pretty much unusable on my Mac. It's a recent model iMac (Core i5 3.2GHz, 8G RAM, no SSD). Scanning the blockchain brings the system to a crawl and makes doing anything else very frustrating. And this is exacerbated by the fact that once this completes Armory will usually crash within a short while so it has to rescan the blockchain every time it starts. I ran it from the command line and I can see something that I wonder could be part of the problem. There are leftover references to picobit's system in the errors it displays in Terminal. For example:
File "/Users/joeschmoe/BitcoinArmory/osx_picobit/workspace/Armory.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/Twisted-13.1.0-py2.7-macosx-10.4-x86_64.egg/twisted/internet/base.py", line 824, in runUntilCurrent
If there's any information I can provide to help fix this then I'd be glad to help
File "/Users/joeschmoe/BitcoinArmory/osx_picobit/workspace/Armory.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/Twisted-13.1.0-py2.7-macosx-10.4-x86_64.egg/twisted/internet/base.py", line 824, in runUntilCurrent
If there's any information I can provide to help fix this then I'd be glad to help
Ack, somehow that file didn't make it to S3. I'll have to check the script to see if it was being excluded from the upload or if there was an error.
Thanks for catching that... the data behind the link is now there, so the previous link should work again.
Thanks for catching that... the data behind the link is now there, so the previous link should work again.
The link to the windows installer appears to be dead.
Edit: Only in the first post.
Edit: Only in the first post.
I see. So that's already 28 gigabytes of HD space wasted. This is getting ridiculous.
It is ridiculous, but it's what we had to do to get the new version working. It also maximizes security and leaves open the possibility of having remote bitcoind/bitcoin-qt instances, etc.
That I could live with. Remote instance would be most useful so I could just dump the bitcoind (and the blockchain) to my server. Please tell more.
mount the blockchain with NFS (for example)
expose RPC to public and limit to given ip (if you dont want that, no need for it) and use SSL on it (if this is possible with armory)
I see. So that's already 28 gigabytes of HD space wasted. This is getting ridiculous.
It is ridiculous, but it's what we had to do to get the new version working. It also maximizes security and leaves open the possibility of having remote bitcoind/bitcoin-qt instances, etc.
That I could live with. Remote instance would be most useful so I could just dump the bitcoind (and the blockchain) to my server. Please tell more.
I just tested on a fresh install of 13.10 online, and it works great. I am not sure if the offline bundle will work with 13.10 offline though.
If you've got enough Bitcoins to need Armory, then 28 GB of hard drive space shouldn't be an issue...
I see. So that's already 28 gigabytes of HD space wasted. This is getting ridiculous.
It is ridiculous, but it's what we had to do to get the new version working. It also maximizes security and leaves open the possibility of having remote bitcoind/bitcoin-qt instances, etc. And will be useful for heavyweight Armory servers in the future. For now, it's what we gotta do. We'll scale it back in future versions after this design is stable.
----- Ubuntu/Debian
Only 10.04 and 12.04 are mentioned.Is the 12.04 deb/installer compatible with 13.10?
Good question! I actually don't know. Anyone want to make some VMs and try it out for me/us?
I recently upgraded from the 0.88 stable to version 0.89.99.14-beta on Windows 7 64-bit.
Looks like the new version created the '%userdir%\AppData\Roaming\Armory\databases\leveldb_blkdata' directory, which now is larger than the original blockchain dir. What's the point in using double the HD space?
Looks like the new version created the '%userdir%\AppData\Roaming\Armory\databases\leveldb_blkdata' directory, which now is larger than the original blockchain dir. What's the point in using double the HD space?
So it doesn't have to hold the full blockchain in the ram. This is a "full implementation", intended for full nodes. This path was opted to reduce overhaul time and limit the code base to debug. There are plans for a lighter version of the DB now that this new code is solid.
I see. So that's already 28 gigabytes of HD space wasted. This is getting ridiculous.
I recently upgraded from the 0.88 stable to version 0.89.99.14-beta on Windows 7 64-bit.
Looks like the new version created the '%userdir%\AppData\Roaming\Armory\databases\leveldb_blkdata' directory, which now is larger than the original blockchain dir. What's the point in using double the HD space?
Looks like the new version created the '%userdir%\AppData\Roaming\Armory\databases\leveldb_blkdata' directory, which now is larger than the original blockchain dir. What's the point in using double the HD space?
So it doesn't have to hold the full blockchain in the ram. This is a "full implementation", intended for full nodes. This path was opted to reduce overhaul time and limit the code base to debug. There are plans for a lighter version of the DB now that this new code is solid.
Jump to: