Stuck at 549722

[mhps]

t looks like the wallet is flushed when the wallet is updated (for example when a related transaction is received), not when blocks are received.

My wallet is flushing between 4sec - 2 min. 32bit win7. Here is an example on 64bit ubuntu server

getblocks -1 to 00000000000000000000 limit 500
2016-07-29 06:03:39 UTC Flushing wallet.dat
Flushed wallet.dat 41ms
connection timeout
trying connection 62.163.212.157:0 lastseen=-7350.8hrs
connection timeout
trying connection 62.83.230.224:2239 lastseen=-5490.7hrs
connection timeout
trying connection 121.98.67.160:2239 lastseen=-7395.3hrs
connection timeout
trying connection 213.152.161.40:2239 lastseen=-8394.3hrs
connection timeout
trying connection 1.36.150.180:2239 lastseen=-4375.2hrs
askfor block d6c93df87ed73067b13e   0
sending getdata: block d6c93df87ed73067b13e
askfor block d6c93df87ed73067b13e   1469772250000000
received block d6c93df87ed73067b13e313a21e117fc85d625cb57d5cffd0f4ba2c056044abb
SetBestChain: new best=d6c93df87ed73067b13e  height=556411  trust=1392319000609
 moneysupply(S)=187168.265 moneysupply(B)=0.00
ProcessBlock: ACCEPTED
getblocks -1 to 00000000000000000000 limit 500
2016-07-29 06:04:13 UTC Flushing wallet.dat
connection timeout
Flushed wallet.dat 26ms
trying connection 30.9.83.46:0 lastseen=-8863.4hrs
connection timeout
trying connection 219.137.137.118:2239 lastseen=-8963.1hrs
getblocks -1 to 00000000000000000000 limit 500
connection timeout
trying connection 62.4.15.180:2239 lastseen=-380492.3hrs
trying connection 86.207.100.176:2239 lastseen=-8659.4hrs
askfor block 12c411ed148a9837f7b0   0
sending getdata: block 12c411ed148a9837f7b0
received block 12c411ed148a9837f7b0a359aa09782eaf164aaa6116a988e79d9b1fcaa4c265
SetBestChain: new best=12c411ed148a9837f7b0  height=556412  trust=1392321050758
 moneysupply(S)=187168.276 moneysupply(B)=0.00
ProcessBlock: ACCEPTED
2016-07-29 06:04:29 UTC Flushing wallet.dat
Flushed wallet.dat 27ms
connection timeout

Flushing several times and it’s definately not doing any tx.

An easy way to make it happen less frequently would be to increase that number.

I will change it for the Pi as the wallet is mostly idle and the Pi uses several tens of sec doing a flush.

[sigmike]

Actually the wallet is also updated when a block is received, because it tracks the last known block. This line can be removed to prevent that.

[mhps]

That explains it.
I don’t want to totally stop the wallet from updating the last known block. I could add a counter to have the wallet updated every 10 blocks. But changing the 2 sec parameter seems cleaner.

[PinkyAndTheBrain]

my pi is stuck too ever since 5.0.1
what can i do about this?

[sigmike]

I ran some tests on a Raspberry Pi and indeed it fails to decode properly the downvotes. Until a fix is found the only option is to run it on another platform.

[mhps]

I ran some tests on a Raspberry Pi and indeed it fails to decode properly the downvotes.

Every new feeature comes with a high cost.

[backpacker]

Sorry for breaking software (

[sigmike]

Actually the fix was easy, it’s just a different default on ARM that I was not aware of.

Fix weight on Raspberry Pi

I’ll make a 5.0.2 release.

[sigmike]

I’ll make a 5.0.2 release.

Actually before that can someone get the 5.0-stable branch from the repository and confirm it’s able to sync the blockchain? You can download it there if you don’t use git: https://bitbucket.org/JordanLeePeershares/bcexchange/downloads?tab=branches

[GreatScott]

"version" : "v5.0.1-7-g6bbd070-beta",
"blocks" : 559210,

It’s working. Thanks, @sigmike

[mhps]

Actually the fix was easy

The costs also include many days off time of minting by many people and time spent in poking around before reporting. Generally we should stick to the KISS rule when more feature is requested.

Thans for the fix. But I won’t be able to use the Pi for a few weeks starting today so I can’t try the fix.

[backpacker]

from block 549723, guess who’s voting:

“reputations” : [
{
“address” : “8Yq1JGmKAm4qyitx6atpUz1QQqqFm5Ki19”,
“weight” : 1
},
{
“address” : “8eA3FVjGUE2KFDJy6qSQxZb3MZdoqLf3ZL”,
“weight” : -1
},
{
“address” : “8eA3FVjGUE2KFDJy6qSQxZb3MZdoqLf3ZL”,
“weight” : -1
}
],
“signerreward” : {
“count” : 5,
“amount” : 0.01
},

[mhps]

conveniently brought down all the pi nodes.

[Sabreiib]

How do you know his voting setting?

[LordanJee]

Maybe it’s time for

“reputations” : [
{
“address” : “8Yq1JGmKAm4qyitx6atpUz1QQqqFm5Ki19”,
“weight” : -1
}
],

[PinkyAndTheBrain]

thanks for the fix, it works

[mhps]

There’s already some code that prevents flushing if it was already done less than 2 seconds ago. An easy way to make it happen less frequently would be to increase that number. If you’re only minting this should be harmless since everything you do is recorded on the blockchain or orphaned. But if you actually use your wallet this is probably not a good idea.

I have tried this on my pi with 2.0.3. The Pi has been sync’ing the blockchain for a stale client. Before I made the change the Pi flushed the wallets every 60 - 80 sec; each flush taking about 60-70 sec. That means the client has been flushing all the time almost. Every minutes only 2-3 blocks were sync’ed.

After I changed it to 200 seconds, te client flushes every 20-30 minunts. Sync;ing was much faster – 1 block / sec. But I felt that the flushint interval was too long. So I changed it to 60sec. Now it takes about 2-3 min to make one flush.

Looks like the problem is largely solved.

[mhps]

I’ll make a 5.0.2 release

Could you please make it?

[sigmike]

Actually since it only affects the ARM architecture which is not part of the released binaries, a 5.0.2 release would be exactly the same as the 5.0.1 one except for the version number.

I’ve just tagged it though, so that you can download the official 5.0.2 source code here: https://bitbucket.org/JordanLeePeershares/bcexchange/downloads?tab=tags.

[mhps]

Thanks. I have compiled it and the client is downloading past 556000.