Steem 0.5.0 Release Candidate has broken my miners..

in #steem10 years ago

So there i was, all pleased with myself for updating well ahead of time for 0.5.0... I log into my miners this morning and... all broken.

So i restart them and it just sits at this.

Any ideas people?

2474353ms th_a witness.cpp:419 on_applied_block ] hash rate: 1 hps target: 27 queue: 95 estimated time to produce: 2236962 minutes

Sort:  

It probably means your miner has mined out a "ticket", then waiting for producing a block to claim the reward. To save your hashing power, setup multiple miners in one process.

By the way, I'm curious why this post got a lot of up-votes. Bots?

something similar has happend every update so far..
It was mining very nicely before the fork even after updating to 0.5.
Yet after the fork it just stopped producing at all.

I am rebuilding a fresh install now and just replaying the blockchain.
Just strange this always happens every update, each time the only fix was a complete fresh install.

You have checked the queue? If yes, or you already have multiple miners setup, it would be strange.
Both of my testing miners are running fine.

1536117ms th_a       witness.cpp:419               on_applied_block     ] hash rate: 5636 hps  target: 28 queue: 96 estimated time to produce: 793 minutes
1599491ms th_a       witness.cpp:419               on_applied_block     ] hash rate: 6001 hps  target: 27 queue: 95 estimated time to produce: 372 minutes

I have multiple miners yes, all of them are showing 1hps and hardly moving...
nothing showing on steemd.com/witnesses

Fresh install... no change..

2540459ms th_a       witness.cpp:419               on_applied_block     ] hash rate: 1 hps  target: 28 queue: 96 estimated time to produce: 4473924 minutes
2540475ms th_a       witness.cpp:419               on_applied_block     ] hash rate: 1 hps  target: 27 queue: 95 estimated time to produce: 2236962 minutes
2459988ms ntp        ntp.cpp:177                   read_loop            ] ntp_delta_time updated to -4185 us

I mean multiple miner=XXX in the config file or startup command.

I have the same problem, how to solve this ?
[solved] it's because of finding out a pow.

How did you compile steem? I just get stuck at 67% every time.

mv steem steemBAK
git clone https://github.com/steemit/steem.git
git submodule update --init --recursive
cmake -DENABLE_CONTENT_PATCHING=OFF .

What version of Boost is installed on your system? What version of gcc (output of gcc - v)?

It seems unlikely, but maybe there is an issue with your version of Boost that is somehow only triggered now in v0.5.0?
Manually compiling Boost 1.57 or 1.58 and pointing to it in the cmake step might be worth a shot.

Also, ENABLE_CONTENT_PATCHING is no longer necessary with v0.5.0. If you want a low memory node do -DLOW_MEMORY_NODE=ON.

And finally, go on the Slack #help channel if you want more direct interactive help.

On Arch the boost is 1.60.0 and gcc 6.1.1 (20160501)
On Ubuntu boost is 1.58.0 and gcc 5.3.1 (20160413)

I was able to compile earlier versions no problem on Arch.
Should I build the "master" branch or "v0.5.0"?

That's what I'm doing, but doesn't work on Ubuntu or Arch. Which distro are you using?

Can you post the error messages here?
Probably you need to do this before compiling:

git submodule update --init --recursive
Loading...

Mine was stuck like that at 1 hps for quite a while, probably around 30 mins, I kept it running like that and it later started working. I think all you need to do is wait.

Btw, My cli_wallet.exe doesn't work, It shows the transport error. Has anyone fixed it? I changed rpc-endpoint = 127.0.0.1:8090 at configuration but it still doesn't work.

been chugging away for a few hours now... still 1hps :(

hmmm Network problems can cause this as well. Have you checked your connections?

ok so just got one of them hashing finally, took about 2-3 hours of 1hps... seems it the network takes alot longer to get synced in with this version...

Alright, I am using Windows miners. I tried both Bitcube's and Arhag's versions. Both worked fine. But, The Bitcube miner gives lower hashing rate than the Arhag miner. So, I'm using the Arhag one.

My miner also got stuck with "1 hps" logs several times. And it definitely wasn't because my witnesses were all in the queue.
Didn't happen again since the hardfork date.