Topic: Extremely long engine initialization, v 0.95.1 - page 2. (Read 2435 times)

I believe the PC is actually very stable, I have not experienced a similar issue before. But now it seems it has finished building the database, well maybe.

In the command prompt window i know see this:

-INFO  - 1480142143: (..\DatabaseBuilder.cpp:268) parsed block file #688
-INFO  - 1480142189: (..\DatabaseBuilder.cpp:268) parsed block file #689
-DEBUG - 1480142189: (..\Blockchain.cpp:242) Organizing chain
-INFO  - 1480142227: (..\DatabaseBuilder.cpp:56) updated HEADERS db in 2603.85s
-INFO  - 1480142227: (..\BlockUtils.cpp:1636) Enabling zero-conf tracking


That is the last line I see in there and it does not update. There is no error recorded either though so I suppose it finished? The Armory database has 142MB.

It was all so simple last year...

Somehow, your system appears to be very unstable. This isn't the first time you report errors that can be summed up to LMDB failing entire sets of I/O operations.

I would suggest you try to sanitize and isolate your setup as much as you can. This is what I would do:

1) Uninstall Armory, make sure the binaries are gone, download 0.95.1, verify the hash and signature, then install fresh. You don't need to wipe your datadir for that purpose, only the installation folder.

2) Do not run BitcoinQt when Armory is performing it's original build & scan. This should free up a lot of resources. Maybe taxing your system puts it over in terms of stability. You can start BitcoinQt once Armory is fully built and scan.

Running the DB alone gets you through the build phase. You have to run a client against that DB at least once so it has some wallet data to scan the blockchain against.

Your steps would be:

a) Start DB alone, let it complete. Once it says "Enabling zero-conf tracking", it's ready.
b) Start the client, you will know within the client when the scan is complete.
c) Start BitcoinQt.

3) Do not build the DB on your NAS. Create a folder on your SSD, and point to it specifically with --dbdir. The final DB_BARE db is ~200MB, DB_FULL is ~1GB, you shouldn't have trouble affording the space.

4) Consider running a few benchmarks on your system to test for stability. At least one RAM, one CPU and one storage stress test.

5) If you find out your CPU isn't stable underload, you can use --thread-count to manually force the level of parallelism during build & scan operations. This defaults to maximum available cores in your system.

OK, thank you for spotting that! Not sure how it got there. However, the DB creating did not finish I am afraid. It stopped at this error:

-DEBUG - 1480128093: (..\Blockchain.cpp:242) Organizing chain
-INFO  - 1480128131: (..\DatabaseBuilder.cpp:56) updated HEADERS db in 2484.12s
-INFO  - 1480128131: (..\BlockUtils.cpp:1636) Enabling zero-conf tracking
-ERROR - 1480128133: (..\BDM_mainthread.cpp:257) caught exception in main thread: no sdbi at this key

That second prefix dash looks weird. It should be 2 minus (-) signs.

I tried running this command:

armorydb.exe --db-type=DB_BARE --ram-usage=1 -–satoshi-datadir="X:\Other\BTC\Bitcoin" --datadir="X:\Other\BTC\Armory"

but it seems there is a syntax error with the -–satoshi-datadir="X:\Other\BTC\Bitcoin" part but I just can't see it.

Given your custom folders, it should be:

X:\Other\BTC\Armory\databases

You don't have to use that folder, you can point to another one using the --dbdir command line argument as well.

OK, will do. Just to clarify - the database folder I should delete is under "Armory\databases", correct?

Create a fresh db folder, run armorydb against that with --db-type=DB_BARE --ram-usage=1. Once it's done building, start the client and let it scan.

The Errors recorded in log before the crash look like:

-ERROR - 1447113712: (..\lmdb_wrapper.cpp:152) Returning dirty key ref

Log file opened at 1480059815: X:\Other\BTC\Armory\armorycpplog.txt
-ERROR - 1480060049: (..\SocketObject.cpp:438) POLLERR error in readAndWrite

Hmm... armoryDB.exe is just crashing now right after headers scan. Any idea? The error right before the crash seem to be always somewhat different.

That's what I am doing - the databases folder was deleted so Armory is building it from scratch. It seems to be working OK now, in 12 minutes the database should be built it says.

Armory's db is matched to the copy of the blockchain it was built upon. You cannot split the 2. This means in your case you should rebuild your DB from scratch.

Update: It seems to be building the database now, I restarted Armory 3 times, each time a different problem with armoryDB.exe, but now it's building so it looks OK. Quite sensitive though...

Thanks everyone for the help! I was able to finally get the BTC database synchronized. Bitcoin Core is working. Unfortunately, Armory is not. After armoryDB.exe opens its command prompt window, Armory crashes with error "tried to use invalid lmdb iterator".

At first there was a problem with database version mismatch so I deleted the "databases" folder under Armory, then the new error happened. Any suggestions? I will post the log in a short while if I can save it before Armory crashes.

https://bitnodes.21.co/nodes/leaderboard/ should be helpful.

I believe at this point you should take the discussion to Core specialists. I'm not too sure what is the bast place to get that info, I only know of the dev channels personally. If anything, a post in D&TD or Technical Support will put you on the right path:

https://bitcointalk.org/index.php?board=6.0

https://bitcointalk.org/index.php?board=4.0

How do I find those? I tried Googling it before but most of the time it was just old info.

In my opinion, this is a major Bitcoin issue though. I do realize most users will never use Bitcoin Core but still, there if there is lack of reliable nodes, it has to cause problems. A year or so ago this was working smoothly.

Then you should consider finding a list of strong well known nodes (explorers, miners, high speed ones) and add them to your bitcoin.conf by IP just to finish bootstrapping.

The drive in the laptop is 480GB SSD but I moved the Bitcoin as well as Armory databases to my Synology NAS which has multiple 3TB HDDs connected in RAID6. When the DBs were on the SSD, the laptop was basically unusable.

Bad nodes is all I get to be honest. Or no nodes. Right now there is even no response listed for most of them. From time to time I do get a good node and transfer even 1GB in a few hours, then it disappears and I am left with the bad ones again.

Well, the bitcoind process is currently consuming 1-3% of CPU time. It does occupy the NAS quite a lot though, and my NAS is capable of 100MB/s+ writing.