The total always shows current data as far as I can tell. I understood what you said, but there is no way we can check that now. We’ll have to assume it’s now fixed. But I would still expect the held amount to be listed like this for the earlier months.
Earnings calculator (Update 2022-12-08: v12.3.0 - Now compatible with node version 1.62+ - Detailed earnings info and health status of your node, including vetting progress)
This value is 0 regardless if past month.
The issue I mentioned in my first point earlier was that total held amount kept increasing after Jan 2020, even though held amount rate was 0%. Unfortunately I did not screenshot this as evidence after I ran GE.
Right, like I said, the total always shows the current value. Only that top overview shows historic information. So…
I meant there.
But yeah, the issue you had seems to be fixed, so nothing to do now.
Yea, too late now.
Moving on to May 2020 earnings script paid is lower than dashboard, any ideas why?
Compensation for lost payout for saltlake in the previous month due to delays in processing.
Just wanted to point out this post.
Typo aside, this user asks what’s wrong when his suspension score is at 100%. This is why I flipped it around. If you name the score after the negative effect, people assume high numbers are bad.
Edit: another example:
And now here:
Just a small update today. Storj seems to have switched to using 720 hour months to align with exactly 30 days, instead of the actual average hours per month of ~730. Effectively this means we get paid for $1.50 for storing data 30 days instead of for storing data an average calendar month. This means we’re making slightly more than the earnings calculator was displaying. This has now been fixed and numbers should better align with what’s shown on the web dashboard. In my case the numbers are now exactly the same across web dashboard and earnings calculator.
v9.3.1 - Change hours per month to 720
- Storj has started to use 720 hours per month in calculating payout, this update changes the earnings calculator to use the same
hm… storj 1.12.3
Thanks for the heads up. Unfortunately my nodes are all on docker, so it’ll be a while until I get this update and can provide an update to the earnings calculator. Apologies for the slight delay, but I’ll get to it when I can.
The docker container for v1.12.3 is available at storjlabs/storagenode:6f6b9b10-v1.12.3-go1.14.7
Looking forward to the update!
This issue has now been fixed with todays release. I apologize for the inconvenience and the delay for those who got this node update earlier than I did. It sucks to have to wait for a fix. But to make up for it I implemented some new goodies. We now have uptime as recorded by the satellites with the new uptime tracking system. With more verbose warnings for different scenarios that may cause issues. I’ve also reshuffled the layout a little bit to make sure the longer status line doesn’t get in the way of the important stuff.
Please note that the warning for stefan-benten is likely because that satellite wasn’t updated and doesn’t report back uptime as it’s about to be phased out. You can safely ignore this for now. That’s the downside of reporting stats that haven’t been officially exposed to end users yet.
Here’s a few examples of the more detailed warning messages.
Enjoy the new version!
v9.4.0 - Uptime is back
- Fix for changes to databases with node release v1.12
- Uptime scores are now included
- Status display for uptime suspension and under review
- More verbose warnings display what should be looked at
- Layout changes for readability
Please note, there is currently a bug that prevents the uptime to be updated in the first 30 days. This is on the storagenode end. So I don’t expect this will show correct information in the first month.
Additionally this new update requires node version v1.12 or later. The database changes made to the node were not backwards compatible.
Big THANK YOU for the update!
Node Version: v1.12.3
script version = “9.4.0”
Traceback (most recent call last):
File “earnings.py”, line 229, in
con.execute(‘ATTACH DATABASE ? AS su;’,tSU)
sqlite3.OperationalError: attempt to write a readonly database
After stop,rm,start node script working, 2 hours and error.
If script run as SU working
I wouldn’t expect that error to begin with, as the script only reads from the databases. I just tried making them read only and the script ran fine for me.
Nice update. Good addition with the uptime scores. Also good to see that it’s showing to be expected results for the current month on Stefan-Benten satellite. Looks like it’s not communicating with the nodes anymore as my uptime is showing 0%
I see this on 2 of 3 nodes I have. All the other satellites are 100%…?
Status: WARNING: Uptime low >Audit[0.0% DQ|0.0% Susp] >Up[0.0%]
This was included in the update post.
OH - thanks @BrightSilence - I missed that.
Runing the last versión of the script on an 1.12.3v storj node…
python earnings.py /path/to/storj/data 2020-09
File “earnings.py”, line 6
SyntaxError: invalid syntax