jaonewguy 8 hours ago
Even with fcf_measures and stop_timestamp, unsure how we would make this more accurate since subsequent resumes don't persist a new start_timestamp. Maybe we need to persist a list of resume_timestamps or something...
ronaldlam 4 hours ago
Damn you're right. A new start_timestamp definitely seems like the way to go.
ronaldlam 4 hours ago
Hmm so i guess we may want an new column because we still have the start_timestamp as part of the PK. I guess the simplest fix is just to add a new col and take int(time.now()) as the entry. What do you think about this?
jaonewguy 3 hours ago
Lol I don't know, it would require a list of start timestamps and a list of stop timestamps I feel. To get true "uptime".
Otherwise, if we are just concerned with uptime, maybe we calculate the difference between each start and stop time in each bots session and persist that into a column as a number of seconds. Then each session just adds onto it? We won't get the exact timestamps of each start and stop though.
ronaldlam 25 minutes ago
So we could have the new col be part of the PK of the metrics table, so that each run_autotrageur invocation will create a new record. That way we avoid the list of start/stop timestamps and still get the whole picture.
From #267: