You showed me your armorylog.txt, I need to see dbLog.txt now.

If you do not have one, do the following:

- open the command line (type cmd in the Windows search bar)
- browse to your Armory installation folder (type this command in the prompt: cd C:\Program Files (x86)\Armory\)
- run ArmoryDB.exe (just type the name out and press return). Let it do its thing then post the log file.


www.imgur.com

--------------------------


Since you can resort to proper English in order to insult the people helping you, you should have no problem maintaining that level of writing when asking for help.

As for your condition, I do not care. You didn't ask for special treatment before hand, so do not expect to be treated otherwise.

Do not delete any file I did not instruct you to. Just go through the motions, ignore any step that you can't perform for now. And for love of all that's alive, please try to construct grammatically sound sentences.

Your log suggests you are only using Armory 0.93.

Your blockchain history seems super old too:


This is what you should do:

1) If you have not done that yet, upgrade Bitcoin Core to 0.13.1. Then start BitcoinQt manually, let it fully catch up.

2) Install Armory 0.95.1: https://github.com/goatpig/BitcoinArmory/releases/tag/v0.95.1

3) In your datadir folder (C:\Users\Zebra\AppData\Roaming\Armory\) do the following:

- delete the /databases folder
- delete armorylog.txt and armorycpplog.txt. Your logs are too long, I need something fresh to narrow down any potential issues.

Once this is all done, make sure BitcoinQt is closed, then start ArmoryQt.exe and let it do its thing. Report here afterwards.

Too many log files. Delete armorylog.txt, armorycpplog.txt and dbLog.txt. Then run Armory again, then post the new logs.


Build is done, run ArmoryQt, it will start scanning.

You can copy paste your logs in pastebin and post the link here. Give me all the logs you got.

Post your logs then

Default path in Windows is:

C:/Users/*yourusername*/AppData/Roaming/Armory/databases

Ignore the sequential part, it is not a bug, just the code not going out of its way to report every file it scans. The DB looks fine. Run ArmoryQt.exe, the post the whole armorylog.txt.

Delete your /databases folder in the Armory datadir.

Both pc running against the NAS? Can you post both specs next to each other for comparison?

I'll look into it for next version.

That's no good


Your log files are:

C:\Users\Thomas\AppData\Roaming\Armory\armorylog.txt
C:\Users\Thomas\AppData\Roaming\Armory\dbLog.txt

Post these both here. Use pastebin if they're too big.

I dont recall anyone complaining about that in recent memory. At this point you should ask Core directly.


LevelDB is flaky on Windows. It has gotten a lot better with the years but a bad shutdown or basically anything else can completely destroy Core's DB.

This is basically your last resort, albeit I can't think of any other issue causing your grief. Your only other solution is to let me SSH/TeamViewer into your machine so I can debug the code directly.

10 days is a bit excessive, but if you have bad connectivity to the network and/or a slow CPU, it will take days. It would prolly take my machine over 12h to sync the full chain now (for info, it builds & scans Armory's DB in 4min total, and I'm on fiber internet).


Since the headers first change in Core, the chain data commit is random, which will grind a HDD to a crawl. The process is very CPU intensive too, courtesy of ECDSA. It will routinely max your cores.

Please post armorylog.txt and dbLog.txt. Is your harddrive running out of free space?


A few years ago someone pushed some data in a signature that was flagged by some anti virus software. This resulted in some block data files getting quarantined. The issue has since then be reported as a false positive and you should not experience it anymore. You can verify yourself if your block files are sequential.

As for the block building report, that output is not meant to be exhaustive. It will only report when the first thread (among many) parses a block file, hence the gaps in the logs.

First link is dead, second one is benign, ignore it.

Use imgur

There's a clickable figure in the wallet's properties dialog next to "Addresses Used", in export mode.


That's benign. Still, pastebin your log file.

Your problem is different from the OP's. You also didn't post your log files as requested.

Consider that for each vocal user seeking help here, there is a silent majority that parses these threads and fix their setup on their own. Isolating each issue in its own thread enhances search results and readability.


In this case Armory is allocing <1GB memory but caching its reads in whatever left over RAM (mmap memory does NOT spill over the swap). This in turn reduces the load on your SSD, as this data is read over several times. As for the SSD load, there's some 90GB of data to process at this time. It will have to be read one way or another.

I don't particularly care to change your appreciation of the code. This is more of an informative point for the silent majority. You obviously made your opinion of me before you started posting.


Do you understand mine? This project went from being funded, with 6 full time developers and 2 interns, to getting bombed and leaving me working on it alone, out of my pocket. There was not even a plan to further development of the FOSS version past 0.93. Armory would be nowhere if I didn't volunteer over a year of my time and money to keep it going. And with that I have to catch up on the technological debt cumulated over 2 years FOSS development stagnation.

Imagine my joy when people who did not participate to the testing phases, provide no feedback or code reviews, let alone contribute some code or help with maintaining the webpage, inaugurate their first post in this forum will all spite and venom.

But at any rate, this path doesn't really achieve anything. Reread yourself. Then put yourself in the position of the people that could help you. Do you really think your post did anything but deter them from helping?


This is not a product but a project. It's always in development, always trying to get better, always in need of feedback, testing and code reviews. This is also beta software that you run at your own discretion. You are approaching this from an entitled perspective. The Bitcoin world will be full of bad experiences if you stick to that view.


Wrong again. A "free product" still has a monetization scheme. You may not be aware of it, but it is still there. Facebook and Google data mine you. Youtube feeds you advertisement. Free to play games come with micro transactions and pay to win schemes.

With Armory, there is none of that. There was quite a push under ATI to go down that path, but under my rule it has strayed as far as possible from this path, to deliver the leanest solution possible. The first I did was to get rid of the phone home code, which was intended to track user statistics for revenue projections and attracting new investors.


Jesus... try syncing 0.93 with the current chain, let's talk again after.


Your coins are not being held hostage. Your private keys are in your wallet, free for you to use. You can access them anytime with offline Armory, with versions as old as 0.90. Your private keys are your coins. Armory is a framework among others that deploys services to interface with the bitcoin network. Why do I even bother trying to explain this...


What is the address chain length on your wallets? Did you restore them from a paper backup before syncing 0.95? Try extending the address chain in offline mode before rescanning. Also, what is the top block displayed in the bottom right? Log files would go a long way.

1) Please don't hijack somebody else's thread, create your own and post your log files.

2) There is a difference between allocated memory (malloc) and mapped files (mmap). The usage figures show you total RAM load, but the distinction is significant: allocated memory belongs to the process while mapped files boils down to hinting the OS that you want these files cached in RAM for faster access. Mapped memory does not prevent new allocations, it simply uses otherwise free resources to speed up I/O.

You are better off documenting yourself on these topics than just jumping to conclusion. Armory has been using this model for nearly 3 years now.

3) This is an open source project, feel free to submit code if you have a better solution, or at least participate to the testing phases and provide constructive feedback and bug tracking.