Topic: Bitcoin Core taking a long time to load. Been happening for about three weeks. (Read 2512 times)

Great, thank you both.  Much appreciated.

Remove the '<' and '>', since you are synced up now your node should build up an up to date list of peers anyway, so you might no longer need to do this.

I see you've already solved this issue, I recommend you follow the tips below it might increase your speed even faster, as well as for anyone else reading this who is running into a similiar issue.

* Defrag your hard drive, could be one of the reasons since Bitcoin core writes & reads a lot into HDD.
* Monitor your CPU & RAM Usage, ensure that you aren't hitting the max power, if you are then you know what you need to upgrade to gain better performance.
* Another case could be invalid sectors or a corrupt blockchain, but that's rather unlikely, if you suspect that's the case then for invalid sectors use chkdsk if using Windows, and if you think its a corrupt blockchain deleting it could solve it, I don't know if you can re-validate the blockchain to check for errors and fix them, but it might be possible.

Also in your case, connecting to peers was failing which was potentionally causing bitcoin core to take longer to start, check your firewall/AV and ensure its not blocking it, as well as your router's firewall, you might also have to port forward and check weither you are behind a double nat, if you are it could be another culprit.

I tried the -addnode command in Terminal but I get the following error:

/Applications/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt -addnode=<50.155.31.101:8333>

-bash: syntax error near unexpected token `newline'

With the blockchain file updated on the other computer it seems to be opening consistently now.

I'm always happy to help! Has it worked now then?

Great!  Thank you so much for your help.  And everyone else too!

Yes, that is apparently the correct command to use documented here.
You can use either:
or
(from the command line from the bitcoin-qt.exe program - not from bitcoind which I normally accidentally do).
Hopefully this works for you!

Thanks for that analysis and info.  Much appreciated!

-connect= Connect only to the specified node(s)

Do I use the above to change the node?

This is the most significant part of the file then:
It looks like the most slow processes were in connecting to the peers:
Im unsure as to why a connection to a node would be refused.

However, that server is offline due to this

If possible try to change the peer that bitcoin core connects to when it loads (the default peer once it opens), select a peer from here that is close to you.


Unless Shorena is online and can advise you better?

Here's a copy of the debug log for the last startup of the program.   After opening it on my roommate's MacBook pro last night I let the blockchain update then closed the program.  It's after work today and I'm back on my computer.  This time Bitcoin core opened very quickly just like it used to.   Perhaps the issue lies with how my computer is updating the blockchain and closing files?  Thanks to everyone for the assistance!

from the debug file:
-----------------

2017-01-06 23:47:03 Bitcoin version v0.13.2
2017-01-06 23:47:03 InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1
2017-01-06 23:47:04 Default data directory /Users/ianmelnicsak/Library/Application Support/Bitcoin
2017-01-06 23:47:04 Using data directory /Volumes/SEAGATE 2TB/untitled folder 2
2017-01-06 23:47:04 Using config file /Volumes/SEAGATE 2TB/untitled folder 2/bitcoin.conf
2017-01-06 23:47:04 Using at most 125 connections (2560 file descriptors available)
2017-01-06 23:47:04 Using 2 threads for script verification
2017-01-06 23:47:04 Using BerkeleyDB version Berkeley DB 4.8.30: (April  9, 2010)
2017-01-06 23:47:04 Using wallet wallet.dat
2017-01-06 23:47:04 scheduler thread start
2017-01-06 23:47:04 init message: Verifying wallet...
2017-01-06 23:47:04 CDBEnv::Open: LogDir=/Volumes/SEAGATE 2TB/untitled folder 2/database ErrorFile=/Volumes/SEAGATE 2TB/untitled folder 2/db.log
2017-01-06 23:47:04 Bound to [::]:8333
2017-01-06 23:47:04 Bound to 0.0.0.0:8333
2017-01-06 23:47:04 Cache configuration:
2017-01-06 23:47:04 * Using 2.0MiB for block index database
2017-01-06 23:47:04 * Using 8.0MiB for chain state database
2017-01-06 23:47:04 * Using 290.0MiB for in-memory UTXO set
2017-01-06 23:47:04 init message: Loading block index...
2017-01-06 23:47:04 Opening LevelDB in /Volumes/SEAGATE 2TB/untitled folder 2/blocks/index
2017-01-06 23:47:05 Opened LevelDB successfully
2017-01-06 23:47:05 Using obfuscation key for /Volumes/SEAGATE 2TB/untitled folder 2/blocks/index: 0000000000000000
2017-01-06 23:47:05 Opening LevelDB in /Volumes/SEAGATE 2TB/untitled folder 2/chainstate
2017-01-06 23:47:06 Opened LevelDB successfully
2017-01-06 23:47:06 Using obfuscation key for /Volumes/SEAGATE 2TB/untitled folder 2/chainstate: 0000000000000000
2017-01-06 23:47:10 LoadBlockIndexDB: last block file = 731
2017-01-06 23:47:10 LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=53, size=52231321, heights=446361...446915, time=2017-01-03...2017-01-06)
2017-01-06 23:47:10 Checking all blk files are present...
2017-01-06 23:47:11 LoadBlockIndexDB: transaction index disabled
2017-01-06 23:47:11 LoadBlockIndexDB: hashBestChain=00000000000000000368447994eaab272102ae239197d12292e387bd3af3d95c height=446820 date=2017-01-06 03:39:22 progress=0.999677
2017-01-06 23:47:11 init message: Rewinding blocks...
2017-01-06 23:47:13 init message: Verifying blocks...
2017-01-06 23:47:13 Verifying last 6 blocks at level 3
2017-01-06 23:47:13 [0%]...[16%]...[33%]...[50%]...[66%]...[83%]...[99%]...[DONE].
2017-01-06 23:47:38 No coin database inconsistencies in last 7 blocks (16907 transactions)
2017-01-06 23:47:38  block index           33762ms
2017-01-06 23:47:38 init message: Loading wallet...
2017-01-06 23:47:38 nFileVersion = 130200
2017-01-06 23:47:38 Keys: 0 plaintext, 320 encrypted, 320 w/ metadata, 320 total
2017-01-06 23:47:38  wallet                  296ms
2017-01-06 23:47:38 mapBlockIndex.size() = 446980
2017-01-06 23:47:38 nBestHeight = 446820
2017-01-06 23:47:38 setKeyPool.size() = 99
2017-01-06 23:47:38 mapWallet.size() = 179
2017-01-06 23:47:38 mapAddressBook.size() = 140
2017-01-06 23:47:38 init message: Loading addresses...
2017-01-06 23:47:38 torcontrol thread start
2017-01-06 23:47:38 Loaded 62567 addresses from peers.dat  333ms
2017-01-06 23:47:38 init message: Loading banlist...
2017-01-06 23:47:39 init message: Starting network threads...
2017-01-06 23:47:39 dnsseed thread start
2017-01-06 23:47:39 upnp thread start
2017-01-06 23:47:39 net thread start
2017-01-06 23:47:39 init message: Done loading
2017-01-06 23:47:39 addcon thread start
2017-01-06 23:47:39 opencon thread start
2017-01-06 23:47:39 msghand thread start
2017-01-06 23:47:39 GUI: Platform customization: "macosx"
2017-01-06 23:47:39 GUI: PaymentServer::LoadRootCAs: Loaded  169  root certificates
2017-01-06 23:47:39 GUI: QObject::connect: No such slot RPCConsole::test() in qt/rpcconsole.cpp:668
2017-01-06 23:47:39 GUI: QObject::connect:  (receiver name: 'RPCConsole')
2017-01-06 23:47:39 ProcessMessages: advertising address 72.48.196.142:8333
2017-01-06 23:47:39 receive version message: /Satoshi:0.13.1/: version 70014, blocks=446963, us=72.48.196.142:54757, peer=1
2017-01-06 23:47:39 AdvertiseLocal: advertising address 72.48.196.142:8333
2017-01-06 23:47:41 UPnP: ExternalIPAddress = 72.48.196.142
2017-01-06 23:47:41 AddLocal(72.48.196.142:8333,3)
2017-01-06 23:47:41 UPnP Port Mapping successful.
2017-01-06 23:47:45 connect() to 87.120.37.230:8333 failed after select(): Connection refused (61)
2017-01-06 23:47:46 connect() to [2002:422a:8362::d4a8:4f6d:3696:6781]:8333 failed: No route to host (65)
2017-01-06 23:47:50 Loading addresses from DNS seeds (could take a while)
2017-01-06 23:47:51 129 addresses found from DNS seeds
2017-01-06 23:47:51 dnsseed thread exit

Can you post the content of the debug.log file please?

I just tried it on his MacBook Pro 2.7ghz with 8gb RAM.  It crashed just as the intro screen said "Done Loading" but opened after a minute or so. 

It wasn't doing this on my MacBook Air with 4GB RAM just three weeks ago, it's a recent development.

The RAM might not be the case then? I have a laptop running bitcoin core and the laptop only has a 6 year old (intensely used) 2.6GHz dual core processor with 2GB RAM and it runs fine. (Maybe your processor is the bottleneck instead (unless it's a quad core processor).

Thank you for that info.  I had a feeling that may be the case, 4GB RAM and a 1.3ghz processor.  Seems to go a little faster if I have all other programs closed when I try to load Bitcoin Core.  I'm testing this idea right now on my roommate's MacBook Pro with a 2.7ghz processor and 8GB RAM.

The problem is likely that you are using a lower power machine. Running Bitcoin Core requires a significant amount of CPU power and RAM. The macbook air is relatively low powered and thus will run slowly when starting up Bitcoin Core as a lot of processing happens on startup.

Hi-

Bitcoin Core recently started taking a long time to load.  Usually just takes a few minutes but lately it's taking 5-15 minutes.  Started about three weeks ago.  I've sometimes had to do a force quit and restart the loading process. 

MacBook Air running 10.12.1
bitcoin files are on a 2tb external drive.  this drive is only for bitcoin stuff, no other files or data.
running Bitcoin Core 0.13.1, updated to 0.13.2 but having the same problem.
wallet.dat file backed up to several other drives.

I double click on the Bitcoin Core application and the usual intro window pops up with the following info along the bottom:

Rewinding Blocks
Loading Blocks 1%
Loading Blocks 13%
Loading Blocks 33%
Loading Blocks 66%
Loading Blocks 83%
Loading Blocks 99%
Starting Network Threads
Done Loading

After it hits "Done Loading" it freezes up for anywhere between 5-15 minutes before opening.  The window continues to say "Done Loading" but the cursor turns into the little rainbow ball and if I click on the Bitcoin Core icon in the dock I have the option to force quit. 

If I just leave it alone eventually whatever is wrong will work itself out (5-15 minutes or so) and the program will open normally and is fully functional.  I have tried running the -rescan command but that didn't seem to help at all. 

I've tried to google this problem but I can't seem to find any posts that have a similar issue.  Has anyone else run into this?

Thanks