Looks like your storage_usage.db is corrupt. If you’re running on a copy of the db’s, try stopping your node before copying.
I believe python 2.7.x should still work just fine, your error is not related to that. But I’ve stopped testing on 2.x versions.
Ah sorry, my bad. This so called Linux is a QNAP NAS and is notoriously bad in keeping binaries and packages up to date. It opens just fine on real computer
No worries. Please don’t use this script over any SMB/NFS connections. As with the node itself, that could cause corruption of the db’s due to sqlite issues over those protocols.
Turns out @punyelroo’s issue wasn’t an issue at all, but actually a correction of a prior issue with the less reliable first contact data. The node was actually 13 months old and the new method shows that correctly. So all good news.
I finished v9.1.0 and it is now available with information on returns of held back amount for graceful exit and month 15 payouts. Since the stefan-benten satellite is 15 months old this month, the payout we will receive in June should include returns of held back amount for a good number of nodes who have been around since then! So this feature is just in time for those SNOs.
I have this error with new version
$ python /volume1/scripts/earnings.py /volume1/Storjv3/data
Traceback (most recent call last):
File “/volume1/scripts/earnings.py”, line 6, in
from statistics import mean
ImportError: No module named statistics
Interesting, works for me on synology. Could you try with python3 instead of python in the command?
it’s ok now but I don’t understand why I didn’t have Python to install anymore, I had to reinstall it
Up until now your script worked fine with python 2.7 on Ubuntu 18.04, the last update doesn’t. Running it with python3 works.
Even though it still works on the python 2.7 version I’m running. I think it’s really time to move on. I have already stopped testing and removed python 2.7 as an officially supported version a while back.
Systems with both versions installed can usually invoke python 3.x by using python3 instead of python. If you only have python 3.x installed just using python would work just fine.
A great job @BrightSilence as always!
Do you think it would be possible to extend the monthly parameter to manage other intervals?
I have in mind something like:
2019 to get the data of the year
2019-07:2020-02 to have the data from July to February
2019:2020 for the data of 2 years
* to get all the data
It would be cool to also have a parameter to export the data in tabular format to be able to consume them elsewhere, maybe a spreadsheet, and made some statistics
Both ideas are probably possible, but I gotta be honest, it’s not likely I’ll implement those. I’m trying to avoid making this thing impossible to manage due to feature creep.
While part of the data is collected using a time window. Some of it is actually month specific, especially with the new data in the paystubs table. So it’s not just a matter of looking at a different time window, I would have to work around quite a lot of complications to make that work.
As for consuming the data elsewhere, I would point to either the API or the databases themselves. Those are kind of built for that kind of stuff, while this output is more akin to a report.
Just pipe the output through some grep and awk commands.
I have decided to resume publishing a Docker image for this script. I will publish an armhf version soon.
@BrightSilence, Thank you so much for your updates!
This version requires “statistics” module on my side (debian and raspbian nodes).
For who migh be interested, you can install it by running the following commands:
apt update && apt install python-pip : might be necessary on raspbian if pip is not installed yetpip install statisticsSince several people ran into this issue I decided to remove the dependency. I only used it to be able to type mean(x) instead of sum(x)/len(x). I thought statistics was included in all installs, but since it’s not, that really isn’t acceptable for something with such a simple workaround. Caught a bug in totals calculations for held back amounts restored as well.
hello,
just downloaded the latest version from github and followed the procedure, stop the node and copy the 4 dbs before running the script. I am not receiving any traffic since today.
got an error line 282 no such table: h.paystubs
thx for your help
The traffic has stopped for everyone, that’s not related. You also need to copy the heldamount.db with this latest version.
I’ve been kicking myself a little bit today after I found out the actual date a node joined a satellite is actually stored in the reputation.db. So all the earlier workarounds weren’t needed. This must be a recent addition as I’m sure it wasn’t there before, but it likely was when I implemented the previous solution. I switched to using this accurate join date to calculate the month number the node is in and added display of this date. Turns out there were some discrepancies when the node had months without any payout. It is now no longer calculated, but simply based on the actual date the satellite uses as well.
Additionally I’ve added lots of status information that can impact payouts.
Since these all indicate issues with your node (with the exception of graceful exit), I hope you won’t ever encounter these messages. But if something went wrong, it’s better to know!
On one of my nodes I get the following error
Traceback (most recent call last):
File "/usr/local/bin/storagenode_earnings.py", line 278, in <module>
for data in con.execute(query):
sqlite3.OperationalError: no such column: suspended
This is the node I started last.
Is there any chance this node is running an old version?