Are you in Linux or Windows?  If you are in linux, you could modify the code yourself, to remove the one offending line (well, change it).  It's the same line as you see the error:  first try changing it from "str(...)" to "unicode(...)".  If that doesn't work, then just remove the line entirely and change it to "txtime='0'".  That second one should definitely work...

The new wallet needs to support unicode strings, but I will be going through and updating ALL of Armory for unicode support.  I should've done it from the start, but I wasn't really familiar with unicode when I started... (yes, silly American...)

Yes, it fixed that, thanks

Just a random update:  I have been experimenting with LevelDB, and it appears there is an excellent compromise upgrade I can make:  it would be to swap out the underlying C++ txMap_ and headerMap_ normally held in RAM using std::map<a,b>, with a disk-based equivalent using LevelDB.  The change looks like it would pretty transparent to all code that leverages the C++ utilities (besides creating an extra directory to store the map data).   If that's the only thing I changed, I think I'd get quite a bit of value out of it (and some downside):

++ RAM usage would drop considerably;  probably from 1.5 GB (proportional to blockchain size) to 200 MB (should be pretty flat)
++ Quite a bit of data would be saved between loads naturally, probably leading to much faster startup times
-- HDD usage would go up quite a bit;  probably from 50 MB (for installed files and wallets), to about 1 GB (proportional to blockchain size)
-- Creates a much more "stateful" Armory, which is a downside;  Since I currently always rescan the chain, every load is a fresh start free from problems from the last load.  No matter what bad state Armory got into before, a restart will fix it (because the initial scan is much more robust than handling all the crazy event sequences that users can induce). 

I suppose, if necessary, I could keep the rescanning (so keep the load time high) and just swap RAM for HDD usage.  But I think rebuilding the maps every time would be quite a bit slower than the current RAM solution (gah, always a trade-off).  On the other hand, the underlying C++ libraries have become much more robust over the months, such that it may not actually be that much effort to produce similar robustness with the saved data.  To be clear: it's not *that big of a deal*, but with this scheme comes extra risks that a user could get "locked out" by a bad state of the saved data and have no clear way to recover (as happens with Bitcoin-Qt when blkindex.dat gets corrupted).

Edit: In fact, the most frustrating (and frequent) bug reports I've received, have been because the one file I keep between loads (mempool.bin, for holding zero-conf tx), would get corrupted and prevent Armory from finishing loading.  I actually built into the latest release a way to detect that loading failed three times in a row, and to just delete it.  Perhaps I'll do the same thing for this data -- delete the disk maps and let Armory rebuild them if there's a problem.

I'm pretty busy the next couple weeks, but I guess I can relax a bit, now that beta finished   
Please let me know if you have tried (and succeeded) testing coin control.  I think it will be worth a full release just for that feature if I didn't break anything else.

I've had armory crashing twice after running for about two days with the following error:


These are the two lines before the error, which might be of interest


Maybe something to do with chain reorganization?

(Armory 0.85-beta, Windows 7 64 bit)

edit: Ok, maybe not reorg, this is from 3 days ago:

I got it yesterday on my Mac, but first it printed that it had lost connection to the Satoshi client, so I assumed that was the problem.

Got another one of those just now, two in one day. Could you make an executible with the added debug statements so we can help?

Yes!  I just implemented "Coin Control" in Armory, in version 0.86-beta.  It will let you do exactly that if you are in expert mode!

If you are in Linux or OSX, you can get it right now by switching to the "coincontrol" branch.  If not, you'll have to wait for me to compile Windows versions, but I can do that later tonight.  They won't be official, but since you asked for it, you can help me test it

This won't start for me...

Yup, 64 bit win 7. Nice, reinstallation seems to have done the trick.

Thanks Ente:

(a) There are no updates on that yet.  If you have the private key, can you import it into the offline wallet and re-create the watching-only wallet and re-import that on your online computer.  Also, even if I had the pub-key import feature, you can't import public-key-only addresses into a full wallet.  Every address in the wallet must have the private key, or not have the private key (it's too complicated to deal with mixed wallets... you would just create a new wallet for that).

(b) The digital backup does include all imported addresses.  However, I'm more of a fan of paper backups, so I recommend printing out the individual keys (select "Imported Addresses Only").  Especially, if you are importing lots of keys and making digital backups, you don't know which ones have been backed up already without loading the digital backup and checking -- it's obvious if you have them printed, though.

(c) I'm not sure I understand this.  There should be no problem running only bitcoind, and Armory should connect to it the same as it would to Bitcoin-Qt.  Unless you are talking about running bitcoind on a different computer...  (it will be possible to connect to remote nodes, in the future, but it's not ready yet).

Time is definitely a limiting factor in the development.  Almost-full-time job, just got engaged, holiday parties, etc.  My fiance knows how much enjoy working on this, and gives me lots of room/time to work on it, but it would definitely help if I didn't have a job.  But I also don't see how I could sustain on Armory alone without converting it to a paid-product model (and even then, I'm not sure the market is big enough, and the stability of Armory is high enough for that).  Right now I'm mostly happy with the arrangement, despite wanting to spend more time on Armory and less at work, but this is the most stable for me. 

People getting more involved in the code would be great.  Though, I understand Armory code base is big and scary  (about 25k lines of code, so far).  It is fairly well-commented, but it's also flush with corner-case catching, error detection, and luxurious informational dialogs which really obfuscate the intent of the code.  It can be tough for someone to see what the code is doing exactly when I've add multiple ways to detect various error conditions and half a dozen message box warnings to accommodate different conditions.  But I'm not sure there's a good way around that...

I was considering making a plugin system for Armory, that would allow users to create new tabs on the main screen.  There's some details that need to be worked out so that it can be done "safely" (or as safe as is reasonable).  That would definitely make it easy for users to contribute new features that could later be merged when they're fully developed.  Though, I'm not sure that's the best way to get other people involved in the code...