In the end this tool is primarily built for me. And for my use case I have a requirement to keep the output compact. Therefor this will not be added to the tool by default. However, if you want to have this, you can add the following line after line 546 of the script.
Please copy as is and make sure that the indentation aligns exactly.
In future versions I will include this line commented out, so you can just remove the # at the start to include it.
Small fix today for an issue introduced with the last version that broke correct display of vetting progress. Thanks @Th3Van for reporting the issue and testing the new version!
Changelog
v13.0.1 - Fix issue with vetting status
Fix wrong display of vetting status introduced in v13.0.0
Having this issue on last version, work’s fine if run with sudo, I’ve checked pricing.db permissions are the same as other db but I don’t see pricing.db-shm and pricing.db-wal
Traceback (most recent call last):
File "earnings.py", line 307, in <module>
con.execute('ATTACH DATABASE ? AS p;',tP)
sqlite3.OperationalError: attempt to write a readonly database
Small update to fix inconsistent methods in calculating end of month estimates. Also improves end of month estimate for storage as separated out at the bottom.
Yes, the advertised payout rate from satellites hasn’t been updated yet. Pricing.db still lists old payout values. I’m still waiting for that to change to see the actual impact of my latest updates on production databases. They did mention it wouldn’t change before payouts for the previous month were finished, but those have been finished for a while now too.
Also, due to a bug mentioned here some storage values are now out of whack. I’m working on a workaround for that atm. Not that this is an issue with the calculator (rather it’s weird data in the node databases), but I’ve found a way to exclude that erroneous data from my calculations. Look for a new version for that soon.
As mentioned above, a small release to limit the impact of wrongly reported storage usage by satellites on displayed numbers for storage usage and end of month predictions.
Changelog
v13.0.3 - Work around erroneous storage usage reports
Implements workaround for erroneous storage usage reports by satellites to limit impact on storage usage and end of month estimate numbers
It took a while for satellites to report back the new payout rates. But this has now happened and the calculator works as expected. The top overview calculates the weighted average payout rate per type across satellites. And each individual satellite shows its own payout rate.
Perhaps it would at the moment. But there is no reason community satellites couldn’t use similar region names in the future. So I’d rather stick with the full names as they are listed in the nodes databases to avoid confusion.
Two small fixes today. As many node operators have used the forget-satellite feature to forget the decommissioned test satellites in order to clean up data, a fix was needed to make old months still visible. This data cleanup includes the cleanup of some of the satellite info in the node databases including reputation info and satellite names. This resulted in the script throwing an error when looking back at months in which these satellites were still active. The fix now shows the satellites correctly, however join date and age in months are no longer available. And the satellite name will be displayed using a hardcoded fallback in the script (shown with an asterisk at the end). The zkSync bonus has also been adjusted to reflect the recent change.
zkSync bonus has been adjusted to 3% to match recent change. (Note this will apply to older months as well)
Worked around missing data for satellites which have been forgotten using the forget-satellite function so you can still view data from old months, using fallback names for satellites
In looking for information on storage space used vs payout, i came across this thread. I was able to run everything successfully, and it appears this script is lining up with the payout report from the dashboard. So i guess my question is, is it usual for there to be a large discrepancy between Total Disk Space used value on the main dashboard page, and the Disk Average Month storage on the payout menu.
My month ending disk usage according to the main page going from Dec to March were
Dec 12.31 TB, January 14.38 TB, February 14.97 TB, March 15.93 TB. These amounts were documented at the end of the day for the las day of each of those months.
My disk usage payout for each of those months were Dec 10.25 TB, Jan 12.06 TB, Feb 11.85 TB, and March 12.95 TB.
Is this large of a difference expected or should i be looking for some kind of issue here?
There can certainly be discrepancies: but you may be comparing different numbers. Like if you started a month storing 100GB… and ended it storing 150GB… you wouldn’t expect a payout for that peak 150. Instead… assuming your space grew smoothly from 100->150 over the month your average would be closer to 125GB: it’s that monthly TBm number you get paid for.
@Roxor is right, additionally the Total disk space number is locally calculated by the node and includes trash and data not yet moved to trash by garbage collection as well, while the Disk average month is only the paid space as calculated by the satellite.
That all makes sense and i have generally treated it as being a month behind, as long as i have positive growth each month. It just seems weird that i ended January at 14.38 TB stored, have grown each month since, and 2 months later im barely being paid more than my December close out, and well below my January close out. But if thats to be expected then that’s cool. It just seemed like historically i would get disk usage payouts that were extremely close to the previous months final usage. Ie. i closed November ‘23 with 10.27 TB used and my December ‘23 payout was for 10.25 TB. That trend has been consistent for as far back as i can recall once i got past having funds held during my first 9 months.
At least the script still says 20 
