Unfortunately, yes, that is most likely the cause. Be happy you got this error and can most likely recover. If you get the “File is not a database” error, you have to start over with an empty db and lose stats. There is an instruction for that on the knowledge base as well in case you run into that.
1 Like
Another small feature update today, sparked by the recent mismatch in data usage on the node vs satellite reports. Apologies for the quick succession of updates instead of bundling, but because of recent issues around garbage collection a few new useful insights that could be added have come to light.
The script already reported the average disk use over the month as reported by the satellites, but that average can be significantly lower on growing nodes than what the satellite thinks you currently store. To get closer to that number, I’ve added a value calculated solely on the satellites last data usage report to get a more recent representation of stored data on your node (usually up to about a day or two old).
I also noticed that I’ve been using this a lot to see what the difference is between satellite reported data and node reported data, but that distinction has never been made visually clear. I’ve now added a column for that and reordered some columns to make it a little bit easier to read.
The new Disk Last Report is now the best value to compare against Disk Current Blobs, to find the discrepancy between what your node thinks it’s being paid for and what the satellite is actually paying you for. Hopefully the fixes on the way will quickly shrink this difference soon.
Changelog
v13.3.0 - Disk size last reported by satellites & reported by source
- Added Disk Size Last Report, which shows a disk size calculated on the most recent disk usage report sent by the satellites. This is the most accurate representation of how much the satellite currently thinks you store and pays you for.
- Added REPORTED BY column to show which values are calculated using local node data and which are calculated using reports from the satellites.
8 Likes
I would say that this is the last update in quick succession, but I can’t make any promises. As long as I can add useful insights, I will. This time, I’ve added 2 lines to show Uncollected Garbage and Total Unpaid Data. Both of these are derived from comparison of local node data against the most recent satellite reported data. Uncollected garbage gives an estimate of how much data your node has in blobs that was already removed on the satellite end, but not yet cleaned up by garbage collection.
The screenshot clearly shows why this information is important right now. This node stores 3.29TB of total unpaid data vs 8.47TB paid data. Storj Labs is already working on solutions for this.
Changelog
v13.4.0 - Uncollected Garbage & Total Unpaid Data
- Added Uncollected Garbage, which shows an estimate of how much data is stored in blobs, but hasn’t been collected by garbage collection. Uses Last Disk Report and Disk Current Blobs to calculate.
- Added Total Unpaid Data, which is the sum of Trash and Uncollected Garbage.
3 Likes
Just ran the latest script and on my oldest node, I somehow have “negative uncollected garbage”:
All of my other nodes on the same system report positive numbers.
Uncollected garbage is an estimate calculated by comparing the last storage report from the satellite against the local disk usage calculation of your node. The satellite data may be up to 2 days behind and the local storage usage calculation relies on the local file walker. So this can happen.
Causes in order of likelihood in my estimation:
- You’ve disabled the file walker at startup.
- More data has been removed than added to your node since the last reported disk usage from the satellite.
- Your node has lost data it shouldn’t have.
I would recommend to check how many folders do you have in the blobs folder in your data location. If more than 4, then please use How To Forget Untrusted Satellites.
1 Like
That would lead to more local data than the satellite reports though. A negative uncollected garbage suggests less local data than the satellite reports.
1 Like
Ah, it’s definitely the second one then - that particular node is full so nothing gets added to it. It’s a less-negative value today as well.
Looks like I do need to go through the forget satellites process on that one, though.
1 Like
It should help. At least it is helped my nodes 
Note to all users, there is currently a bug in the last version of the Earnings Calculator that causes wrong values for Disk Last Report and Uncollected Garbage when the satellite missed a day sending out storage usage reports. I have a fix underway, but ran into another issue posted here. EU1 sudden drop in storage usage reported by satellite (Not just the graph display issue this time, database shows unusual low data usage in the last report from the satellite)
If you see unusual low Disk Last Report compared to Disk Average So Far, please don’t use v13.4.0 to report this issue to Storj. I will try to get v13.4.1 out of the door soon after more clarification on the above issue.
5 Likes
Looks like our Storj friends are going to keep me busy. Just to get ahead of things, this calculator will break completely in an upcoming version of the storagenode.
When this commit goes life, it will break the calculator. storagenode: add bandwidth DB write cache · storj/storj@962ff04 · GitHub
As of now, I don’t know what version it’s going to be in and I’ll try to get ahead of it when it goes live on test nodes. But I can’t make any promises to have a new version available on time for production release. The changes seem fairly significant for the purposes of the calculator and may also result in different and possibly incorrect data even when I’ve made the required adjustments, at least for now. There is nothing I can do about that as that’s the result of Storj (rightfully) prioritizing performance optimization over 100% correct bandwidth usage reporting. See @littleskunk’s post here for why this is happening. Upcoming storage node improvements including benchmark tool - #22 by littleskunk
A lot is still unclear to me until I have a node running with this new version.
3 Likes
I mentioned this internally and had plans to update you on how this might break the earnings calculator. Glad you noticed it yourself
4 Likes
I appreciate that, @clement ! Thanks for the (intended) heads up. I had a feeling reading along with the topic on performance improvements that this might happen and @littleskunk’s last post prompted me to check the commits. For what it’s worth, the new table setup seems simpler and I’m happy I won’t have to check 2 tables in the future. It will probably also improve the performance of this calculator as a happy side effect. 
4 Likes
Good news, the new version that works with these changes is available as a prerelease version now and is marked as such on github. I will also not update the top post and subject of this thread until node version v1.104 begins rolling out to production nodes. I chose to skip the bugfix release v13.4.1 and merged those changes into this version.
Warning: Do not upgrade to v14.0.0 unless your node is already running v1.104 or above - this version is not backwards compatible with old node versions
With the warning out of the way, here is the changelog for this version.
Changelog
v14.0.0 - Compatibility with storagenode v1.104 and up
- Breaks compatibility with node versions v1.103 and below.
- Compatible with v1.104 and up
- Fix an issue with including empty records in satellite stats
- Add a note during first days of the month or when deviations are detected that satellite stats may be temporarily unreliable
4 Likes
Since node version v1.104 has started rolling out to nodes, I’ve marked version v14.0.0 as latest and updated the top post. Don’t update to this version until your node has updated to v1.104.
4 Likes
Just updated after the v1.104 rolled out to 1 of my nodes. Thx … working very well. Extremely valuable utility for me.
2 Likes
Really sorry to be a pain, but when I try running it on my Debian machine I get
Traceback (most recent call last):
File “earnings.py”, line 6, in
from datetime import datetime, timezone
ImportError: cannot import name timezone
Time and date are set correctly. Sorry if this is a very basic question… 
I’m afraid you’ll have to update your python version. If you already have python 3.2 or higher installed, try using python3 instead of python when calling the script or make sure python 3 is in your path.
I knew it would be something silly.
Thank you so much 
1 Like
Thanks for your efforts on this valuable tool.
with node v1.104.5 things stopped working with this error
Traceback (most recent call last):
File “earnings.py”, line 382, in
for data in con.execute(query):
sqlite3.OperationalError: near “(”: syntax error
Just pointing this out in case you have not noticed yourself.