Great, thank you both. Much appreciated.
Hm not sure what happened to the post that I added here yesterday, maybe I offended someone with my comment.
I'm going to largely repost (yet simplify) what I've put up and summarize it here because not only did tis same problem happen to me but the cause in my case was pretty simple. I think that I finally have it under control.
So there are two problems here.
First I've run both bitcoin-qt and ltecoin-qt on 3 different machines but only on the Intel machines (i5 & i7 laptops) do I have any problems running either. I ran into this 'network" "lockup" problem specifically and that brings in a 2nd problem, that the GUI hides a lot of what is happening, that right off the top you can solve by running the daemon directly.
But there are a few things that contribute to the GUi not running correctly.
First as some have undoubedly told you in readme files here and other places, your computer has to be in good shape to run a full node without any problems. In my case I'm missing the specified laptop power supply and running a 3rd party 60W supply vs the 90W that's specified (from the mfg). It's been running fine on everything else but bitcoin full node.
This leads to the consequences, that the ACPI doesn't work correctly which is a major issue for other software as well.
Third is that the system need to be setup to run "cool" not "ultra-fast". Check your bios ACPI config if you have problems that look like they are coming from a hot system.
Next are the power-control settings themselves, mine is still not responding correctly to the power settings (in Ubuntu 24.04), I spent a long time and a lot of effort trying various recommendations...none of them worked...I gave up and wrote a little sleep loop in a Bash script that I can use to monitor how long the "fix that I am about to explain" runs before it has issues and causes the OS to log-out my session (which is where the lockup comes from if it isn't about setting it up to use one seed server, as in this thread above)...your computer has to be setup correctly to run a full-node, and there is this dirty little secret about switching power on and off to external drives, which the ACPI also does...again...check your bios settings for ACPI thoroughly.
So about this "scanning network" error with the bitcoin-qt
Two bits of background info first. BTC is a VERY INTENSIVE coin to process. It's taken 800GB to catch up with it so far, I'm still at about 98% sync and I've been struggling to get this computer synched for two weeks now. So there are some relevant bits to this problem that you should know about, but ultimately you will find out that running the bitcoind directly solves a lot of problems and exposes a lot of the inner workings of a full node.
No matter if you have this problem or not.
Find out where your data directory is. Because it will be the key to running a full node successfully.
If your gui appears to "lock up" and you have made the mistake of selecting "run node at startup" so you cannot do anything but watch it lock up. Kill the bitcoin-qt in System Manager and run the daemon directly.
You will need a bash line like this to do so:
$ /bitcoin-28.0/bin/bitcoind -datadir=[path to datadir to use]
It will be the folder that CONTAINS the blockchain folder, the wallet folder(s) (which have the same name as the wallet name) and likely a copy of the bitcoin.conf file (that the GUI opens when you click the "open configuration file" button).
If the daemon (through the GUI) was last run and shut down with the wallet(s) open but you have the right data folder then you will see the wallets named on the screen log after the daemon starts. If it was not open but you have the right data folder, then it will show a [] where the wallet name should be.
If you have the WRONG data folder then it will start a new sync in the btcoind default folder and the "progress=0.xxxxx " will be low, near zero. Use Ctnl-C to kill it, find the right data folder and fix the call or you'll start an entirely new copy of the btc blockchain and bitcoin.conf in the default locations (somewhere under ~/.bitcoin I guess). It is good to know the data folder location because you can use it for administrative work on the full node.
So assuming that you have all that right, you should see a couple of pages of text and then the verify section where it steps from 0% to 100% of the downloaded blockchain, and then starts to load new blockchain data, from 0MB (in steps of roughly 1.5MB, whatever MB you've set for the cache size in the GUI or directly in the bitcoin.conf file) into what I assume is some sort of transfer-cache (the "progress=0.xxxxx" will be appropriate for your level of sync). That is the daemon getting new blockchain data from other full nodes, which it then checks-over and then adds to the blockchain folder in the data folder. That means that your system is working fine as far as the network config goes. When it fills the transfer-cache allocation it will add all of that data to the blockchain folder.
That means a very sudden burst of data is read from the daemons' transfer-cache, processed and sent to the blockchain folder.
And this is likely where things will go wrong if you have any issues with sufficient current to the drive that holds the data folder.
Luckily the transfer cache is stored on the drive so if your daemon / computer goes into sleep mode anyway (like mine just did) all of that transfer-cache data will still be there and restarting the daemon after the sleep-mode transition will proceed normally, flush that cache and carry on as before. If your problem is that it fills the cache and then goes into sleep mode or logs you out of your session when that flush starts, or before it finishes, your problem is a power problem between the computer and that drive.
It's not really going into sleep mode. I just had it running for 90 minutes or more and it logged me out while I was writing this. It's suffering a power brownout that triggers the ACPI to do dumb things. If yours is like mine, "once the battery power drops to 50% it will disable power to the USB ports". That is where my system disk is connected, and that is causing the OS to attempt to drive the computer into standby. As soon as it starts to do that the power comes right back up and the OS will leave your session logged-out. If it actually shuts the OS down, your problem is a little worse than mine is now.
I expect that this won't be fully solved until I get the proper power-supply for this laptop.
For now I will try setting that cache back to the default size of 512kB or smaller (down to 10MB. So the cache-flushes aren't so long. Hopefully then they won't be enough to cause it to kill the user session...and it was, and it just crashed a lot faster.
The other option is to make the cache huge so it gets the blockchain data and then kills the user session. At least get that painfully-slow part out of the way.
yes there are -dbcache=[450] (in kB) and -maxmempool=[300] flags
But what I really want to do is make the transfer-cache small so it makes a lot of small transfers instead of a few big transfers. Short of that, at least download the rest of the whole blockchain so I can do the transfer on another computer.
I could also copy all of the bitcoin full-node related data to another computer that is properly powered
which would probably be fine if you've pruned your copy of the blockchain adequately. But that's why I run on external drives in the first place. Easier to just switch the computers or the external drives. Reason #1 why I don't run Windows. If running btcoind on an ext drive connected to computer A is giving you trouble, the answer might be to find another PC which can take the drive, and either has the same OS and mount the ext drive into that OS (run the daemon with the appropriate path to the data folder) or just boot off the ext drive. Advantage: Ubuntu! Looks like that's what I'm going to have to do for now.
So anyway. Just wanted to note another problem that can cause this "synch network" lockup, with an associated solution.
Never sit there and watch the GUI startup screen without checking System Manager to see if the sw is actually doing anything.
If it's not actually doing anything, kill it and run the daemon instead using the -datadir= flag to use the same data folder as the GUI version. The daemon will show you more than you want to know about what it is doing.
