That was it. I forgot to remove the watchtower container when I added the last node to the docker command. All good now.
1 Like
Thanks ! Working like a charm.
No surge confirmed for april
Hasnât been reported back to your node just yet. Stay tuned.
5 posts were split to a new topic: Je comprend pas les paiements reçu en fÊvrier pour le mois de janvier
New version works great for April payouts but I recognized a small visual âannoyanceâ:
The corresponding values of normal payout and surge applied are not below their corresponding value.
2 Likes
I had already caught this in another screenshot posted by someone else. Apparently not all python versions apply the number format the same way. That percentage should have been rounded. Iâve fixed it on my end already but didnât think itâd be worth an update. This should be a round percentage again anyway after the stefan-benten satellite reports paystub data back. Either way, it will be fixed in the next release.
1 Like
Awesome, thanks.
Iâm using python 3.7.3 so this is unexpected.
Traceback (most recent call last):
File âC:\Users\Storj\Desktop\storj_earnings-master\earnings.pyâ, line 278, in
for data in con.execute(query):
sqlite3.OperationalError: no such table: h.paystubs
how to resolve this?
You need heldamount.db as well with this version.
1 Like
Some minor bug fixes in a small release today. No new functionality.
@kevink: The layout should now be fixed.
@Darthsaiber: The script should now give a more human readable output if that particular db file is missing.
ERROR: heldamount.db not found at: "C:\Users\brightsilence\storage" or "C:\Users\brightsilence".
Enter the correct path for your Storj config directory as a parameter.
Example: python .\earnings.py "C:\Users\brightsilence"
Changelog
v9.2.1 - Minor bug fixes
- Fix in how percentages are displayed which could cause layout issues on some systems
- Fixed an issue where the script checked for the wrong filename of heldamount.db leading to the script throwing a non-user friendly error message if this db is not found (Thanks @karaliux for the PR)
- Fixed an instance where local time was used instead of UTC
1 Like
This appeared to me when running version 0.9.2.1 in a separate folder.
C:\Users\DarthSaiber\Desktop>earnings.py
File "C:\Users\DarthSaiber\Desktop>earnings.py", line 6
<!DOCTYPE html>Iâm not sure what you downloaded, but itâs definitely not the script file.
Please try this:
wget https://raw.githubusercontent.com/ReneSmeekes/storj_earnings/master/earnings.py -outfile earnings.py
1 Like
I downloaded the file from Github.
Now I have downloaded it from your link and that does work well.
To download from the GitHub instead of cloning, you should use either Download button there or click on the script and switch to the RAW format, then download.
2 Likes
Looks like your node is very new. Itâs not kept at 0, but it starts really slow. The reason for this is that vetting checks whether data on the network is still there and not corrupt. So the more data you have the more audits you get. New nodes need to collect some data first before they get audited. So no worries, it might take a while now, but the process speeds up over time. Expect it to take about a month. Could be faster on some satellites and slower on others.
2 Likes
I´m vetted 148 in one satellite, while in others only have passed 30 audits? kind of weird being that different
1 Like
Nope, just depends on how much data your node holds for each satellite. Perfectly normal.
2 Likes
Easy way to run this on multiple nodes on same physical server?
Say i have /mnt/hdd1 /mnt/hdd2 and /mnt/hdd3 as 3 different nodes.
I tried python earnings.py /mnt/*/ but doesnât work.
No that wonât work. A shell script that runs it on all three nodes is the best you can do.
1 Like