RAM-Reduction & Backup Center Testing (version 0.89.99.16)

[picobit]

So far, I've seen a pattern that 32-bit Windows versions don't seem to work.  But 64-bit OSes do work.  

I would not be too optimistic on a 32-bit version.  The real reason for 64-bit architectures is that you can easily handle more than 2GB of data in one block.  On a 32-bit architecture, that is going to be tough (but of course not impossible).

[justusranvier]

Watching-only wallets contribute to the "Maximum Funds" and "Spendable Funds" totals even if they are configured as "Belongs to: Someone else."

[TierNolan]

And this strange unicode issue from TierNolan.

Adding the string cast seems to have fixed things.

[rkjnsn]

Given the issues with Windows 32-bit that I've seen, I'm going to try to rebuild everything on a native 32-bit VM.  Unfortunately, I tried installing MSVS 2012 Express on WindowsXP-32bit, but I got all sorts of crazy errors.  If anyone else has WinXP-32bit and feels like donating some time, please try downloading and installing MSVS 2012 Express for Windows Desktop.  I ask because, I assume it's possible that there is something wrong with my WinXP system, but I also wouldn't be surprised if Windows XP is just too old at this point for such a new piece of software.

Instead, I'm going to install Windows7-32bit and repeat the build process there.  If it works there, it obviously has a better chance of working on any Win7-32bit and Win8-32bit.  Fat chance for Windows XP, but maybe we'll get lucky.

Visual Studio 2012 only supports running on Windows 7 SP1 and later. By default, the created executables will only run on Vista and later. It can build XP compatible executables, but you have to change the project's Platform Toolset to "Visual Studio 2012 - Windows XP (v110_xp)"

[Mooshire]

Alan  mine worked like a charm, except for rapidly disconnecting/reconnecting while downloading the blockchain. Specs are above.

[Mooshire]

When starting it for the second time, after downloading what blocks it had to, it got stuck scanning on 1%. I found this in the log over and over, for a very long time.

-WARN  - 0: (..\BlockUtils.cpp:4865) Marking orphan chain
-WARN  - 0: (..\BlockUtils.cpp:4888) Done marking orphan chain

[etotheipi]

When starting it for the second time, after downloading what blocks it had to, it got stuck scanning on 1%. I found this in the log over and over, for a very long time.

-WARN  - 0: (..\BlockUtils.cpp:4865) Marking orphan chain
-WARN  - 0: (..\BlockUtils.cpp:4888) Done marking orphan chain

Mooshire, is it solved by restarting the app?  So far, I haven't seen it get into any permanent bad state.  I've seen that happen before, and then it goes away on a restart. (P.S. - I do plan to find and fix it, I just want to make sure that, for now, it doesn't leave anyone in an unusable state)

Watching-only wallets contribute to the "Maximum Funds" and "Spendable Funds" totals even if they are configured as "Belongs to: Someone else."

What is the wallet filter set to?  If it is "All wallets" it will include all wallets.  If you set the filter to "My Wallets" it has the behavior you expect.  Bottom-left corner of main window.

Leveldb/snappy is still broken:

...

The pull request I sent you on GitHub fixes the problem for me. With that patch applied, the time from starting the program until balances are displayed is about 28 seconds.

I have modified it in my source code and will commit it with the next version.  

Visual Studio 2012 only supports running on Windows 7 SP1 and later. By default, the created executables will only run on Vista and later. It can build XP compatible executables, but you have to change the project's Platform Toolset to "Visual Studio 2012 - Windows XP (v110_xp)"

I don't want to spend a ton of time on it... but now that the RAM issues are under control, and it previously worked on XP, I would be willing to spend a couple hours getting it work on XP.  Especially because some users might have old XP systems laying around they'd want to use for offline use (don't bash them, it's still better than an online computer )

[goatpig]

I don't want to spend a ton of time on it... but now that the RAM issues are under control, and it previously worked on XP, I would be willing to spend a couple hours getting it work on XP.  Especially because some users might have old XP systems laying around they'd want to use for offline use (don't bash them, it's still better than an online computer )

You can't install msvc11 on WinXP, you need .NET Framework 4.0, which is only compatible with Windows 6.0 (Vista) and above. I have built the LevelDB port using the WinXP tool, but haven't tested it. There are instructions for WinXP deployment with the port I sent you.

[etotheipi]

Anyone tried this with Win7-32bit?  I'm running it right now, but I don't have a pre-sync'd version, so it might be a while before I can really run it.  I guess I could figure out how to bootstrap it...

Btw, I just executed a couple offline transactions using the new version on the online computer (offline computer is still using an ancient version).  Everything is smooth, so far.  Except for that occasional faulty startup thing.  That's my next task after I finish with the Windows LevelDB upgrade from goatpig (thanks goat!)

[Mooshire]

I started it up again, the visual indicator didn't change from 1% until it went straight to the wallet after a few minutes. Looking at the live log file, it stopped right after the completed handshake, also it said the armory version was 0.88 (ArmoryQt.py:1162) also, got this error. (WARNING) -- ArmoryQt.py:1838 - Memory pool file was corrupt.  Deleted. (no further action is needed)

Not sure if it's significant. Hope this helps.

[etotheipi]

I started it up again, the visual indicator didn't change from 1% until it went straight to the wallet after a few minutes. Looking at the live log file, it stopped right after the completed handshake, also it said the armory version was 0.88 (ArmoryQt.py:1162) also, got this error. (WARNING) -- ArmoryQt.py:1838 - Memory pool file was corrupt.  Deleted. (no further action is needed)

Not sure if it's significant. Hope this helps.

So is it working?  It sounds like it's working and you're just reporting some inconsistencies in the log file.  Don't worry, both those things are normal.  I mean, not totally normal, but they happen.

[Mooshire]

I started it up again, the visual indicator didn't change from 1% until it went straight to the wallet after a few minutes. Looking at the live log file, it stopped right after the completed handshake, also it said the armory version was 0.88 (ArmoryQt.py:1162) also, got this error. (WARNING) -- ArmoryQt.py:1838 - Memory pool file was corrupt.  Deleted. (no further action is needed)

Not sure if it's significant. Hope this helps.

So is it working?  It sounds like it's working and you're just reporting some inconsistencies in the log file.  Don't worry, both those things are normal.  I mean, not totally normal, but they happen.

Yes, it's working.

[rkjnsn]

Visual Studio 2012 only supports running on Windows 7 SP1 and later. By default, the created executables will only run on Vista and later. It can build XP compatible executables, but you have to change the project's Platform Toolset to "Visual Studio 2012 - Windows XP (v110_xp)"

I don't want to spend a ton of time on it... but now that the RAM issues are under control, and it previously worked on XP, I would be willing to spend a couple hours getting it work on XP.  Especially because some users might have old XP systems laying around they'd want to use for offline use (don't bash them, it's still better than an online computer )

I mainly use Linux, myself, but I do have a fair amount of experience getting things to build on Windows for work. I'd be happy to help if you run into problems, time permitting.

[Winterfrost]

Everything synced fine from a fresh install (Win7 64-bit), but I did find an issue when I sent a transaction. It went through successfully and showed up in the receiving address as well as in the transactions list in Armory. However, when I went away from my computer and came back later, the transaction is no longer there and the wallet has reverted the balance to what it was before. So basically, it now says there are funds to spend even though in reality they've already been sent elsewhere. The bug also persisted across restarting.

[etotheipi]

Everything synced fine from a fresh install (Win7 64-bit), but I did find an issue when I sent a transaction. It went through successfully and showed up in the receiving address as well as in the transactions list in Armory. However, when I went away from my computer and came back later, the transaction is no longer there and the wallet has reverted the balance to what it was before. So basically, it now says there are funds to spend even though in reality they've already been sent elsewhere. The bug also persisted across restarting.

Ack, I haven't seen that one before.  Are you sure it has confirmations?  Armory on Windows has always had an issue with the memory pool, for some reason it cannot persist through a restart (that's what all the "Memory pool file was corrupt.  Deleted. (no further action is needed)" messages are about.  But it should resolve itself after the transaction gets one confirmation.  If not, then that's a problem, for sure!  Does it have one confirmation yet?

[Winterfrost]

Everything synced fine from a fresh install (Win7 64-bit), but I did find an issue when I sent a transaction. It went through successfully and showed up in the receiving address as well as in the transactions list in Armory. However, when I went away from my computer and came back later, the transaction is no longer there and the wallet has reverted the balance to what it was before. So basically, it now says there are funds to spend even though in reality they've already been sent elsewhere. The bug also persisted across restarting.

Ack, I haven't seen that one before.  Are you sure it has confirmations?  Armory on Windows has always had an issue with the memory pool, for some reason it cannot persist through a restart (that's what all the "Memory pool file was corrupt.  Deleted. (no further action is needed)" messages are about.  But it should resolve itself after the transaction gets one confirmation.  If not, then that's a problem, for sure!  Does it have one confirmation yet?

Yes, this is the address and this is the transaction.

[etotheipi]

Everything synced fine from a fresh install (Win7 64-bit), but I did find an issue when I sent a transaction. It went through successfully and showed up in the receiving address as well as in the transactions list in Armory. However, when I went away from my computer and came back later, the transaction is no longer there and the wallet has reverted the balance to what it was before. So basically, it now says there are funds to spend even though in reality they've already been sent elsewhere. The bug also persisted across restarting.

Ack, I haven't seen that one before.  Are you sure it has confirmations?  Armory on Windows has always had an issue with the memory pool, for some reason it cannot persist through a restart (that's what all the "Memory pool file was corrupt.  Deleted. (no further action is needed)" messages are about.  But it should resolve itself after the transaction gets one confirmation.  If not, then that's a problem, for sure!  Does it have one confirmation yet?

Yes, this is the address and this is the transaction.

Ugh.  Okay, definitely a bug.  And the saving-between loads is causing it to persist (it's one of the reasons I liked rescan-every-load, from a reliability perspective).   Can you do me a favor and close Armory, then restart it with the "--rescan" option?  I just realized, I need to put a button into the interface to do that...

[etotheipi]

Winterfrost:  can you also send me a copy of your log file?  Use File->Export Log File.  Then attach it to an email to "bugs@bitcoinarmory.com".  This could be an ugly bug to track down because it's probably pretty difficult to reproduce it on demand.  Hopefully there's something in the logs that helps...

[Winterfrost]

I sent you the log file. I'll let you know what happens when the rescan finishes.

Update: rescan finished and balances are back to normal.

[cp1]

Finally got around to building it.  It worked fine without any makefile changes on Ubuntu 13.04 64-bit.  I think it took about 3 hours to build the database, but I wasn't watching very closely.  It loads instantly on a wallet with no balance   Very nice work.