Alright. There’s clearly an issue here. This was reported in the testing thread but not everyone mentioned it, and I wasn’t able to reproduce it. So it was deemed to be environmental and limited. That doesn’t appear to be the case and it looks like it could affect all users with existing wallets, or wallets that meet a certain criteria. I’m not exactly sure yet until I can reproduce it… I’ve replaced 2.1.0 with 2.0.3 on the website, and I’ve added a warning to this topic title/unpinned it. We’ll figure it out.
Has anyone tried starting 2.0.3 after the failure of starting 2.1.0?
This is what I did.
Win 32 - used bootstrap to sync with new & clean wallet.
Once I completed the sync, I shut down, replaced wallets with wallet backups and started. It took longer to start up, but everything went ok.
I received ALP payments last night with the new 2.1.0 client.
Okay, thank you for that information. In any case, I made the decision to reduce exposure to 2.1 because having to go through all those extra steps is troublesome, and not representative of the kind of releases we want to deploy. I will work with the users reporting this issue and the devs to see what is causing this problem and we will resolve it.
Thank you, especially for the drive for quality.
I should be able to re-create this with some more detail, and the suggestion to run ‘repairwallet’ is appreciated. What does that command actually do?
There was no obvious error messages in the logs apart from the assertion failure around the wallet. The machine that has had trouble has both a very large wallet due to minting, as well as has had numerous unclean shutdowns due to loss-of-power. However upon restart, Nu 2.0.x always came up.
I will re-try the upgrade as time permits (and once I get a full blockchain again) and report back more detail.
I’ve uploaded 2.1.1-RC1 binaries here: https://bitbucket.org/JordanLeePeershares/nubit/downloads
Changes:
- the initial freeze should be fixed
- walletpassphrase doesn’t crash with large timeouts
- you can give a negative timeout to walletpassphrase to disable relocking
As I said here Tor connection worked fine when I tried. So please try with the speficied nodes and let me know if you still have problems connecting with Tor.
Tor connection worked fine here for v2.1.1-RC1.
That seems fixed indeed.
Syncing with the block chain still takes ages :[
I’m 3 days behind and waiting more then 10 minutes now for the Qt to be synced.
Agreed. Very slow indeed… =/
About the slow downloading comments. Did you guys already see this here…
Yes, but I am not talking about initial download. My wallet was synced already.
Ok, so whatever was done to improve the memory usage slows down the syncing of the blockchain. Is it possible to make it so that these memory changes/improvements can be disabled manually just until people can sync the full blockchain and then once it’s finish, they can be enabled again? Somebody downloading Nu for the first time would manually switch off these changes so that the blockchain downloads faster. Once it’s complete and finished downloading they can then switch them back on. Hopefully that made sense. Is that even possible or does it not work that way?
Has anyone else tried the 2.1.1 upgrade on a 2.0.3 data directory? I’d like to hear some more peoples experiences who had the hanging issue. Please make sure to make a copy of your 2.0.3 directory before attempting!
Has anyone else tried the 2.1.1 upgrade on a 2.0.3 data directory?
I did a complete rebuild, despite for the wallet and conf files.
Oh so you weren’t upgrading from a 2.0.3 data dir to 2.1.1?
No. Bootstrap + a lot of time.
I’m able to achieve massive increase of sync rate when I run my nud on the standard port.
I was running it on a custom port before, because I’m behind a VPN most of the time.
I actually saw my client send me = IPv6 address lines in the debug.log. Is that supported?
Excellent suggestion!
The core problem is downloading recent blocks, not early ones.
Following to hear if that “switch” option is possible for that issue…
I would like to report an issue with all versions from RC8 2.1, 2.1, and 2.1.1.
After few hours of having the client running I have a wrong balance displayed in the overview window it jumps up in the order of millions of NBT.
This issue does not affect the actual balance and if you try to send more than what you have available in the wallet you will get a window message saying that you do not have enough funds for the transfer.
Can you explain what process you used to upgrade to 2.1? If you run getinfo in the debug console what does it report?