You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been running v2 for more than a year without any issue. It's been great, nice work! (400 days uptime!)
I made a small change to the goveebttemplogger.cpp to adjust the colors in the SVG output files.
I successfully rebuilt, reinstalled and relaunched the daemon. Unfortunately it's been stuck using nearly 100% of a core for more than an hour. I see from the README that "The causes the program to take longer to start up as it will attempt to read all of the old logged data into an internal memory structure as it starts." Wondering if it's going to finish in a reasonable amount of time, or if there's some exponential slowdown that I need to find another solution for.
Any suggestions?
The syslog looks like this:
Oct 6 15:24:16 buster systemd[1]: Starting GoveeBTTempLogger service...
Oct 6 15:24:16 buster systemd[1]: Started GoveeBTTempLogger service.
Oct 6 15:24:16 buster goveebttemplogger[4131]: [2024-10-06T22:24:16] Reading: /var/www/html/goveebttemplogger/gvh-titlemap.txt
Oct 6 15:24:16 buster goveebttemplogger[4131]: [2024-10-06T22:24:16] GoveeBTTempLogger Version 2.20230901-1 Built on: Oct 6 2024 at 15:14:30
Oct 6 15:24:16 buster goveebttemplogger[4131]: [2024-10-06T22:24:16] Reading: /var/www/html/goveebttemplogger/gvh-A4C1381A352C-2023-09.txt
Oct 6 16:04:07 buster goveebttemplogger[4131]: [2024-10-06T23:04:07] Reading: /var/www/html/goveebttemplogger/gvh-A4C1381A352C-2023-10.txt
Oct 6 16:04:59 buster goveebttemplogger[4131]: [2024-10-06T23:04:59] Reading: /var/www/html/goveebttemplogger/gvh-A4C1381A352C-2023-11.txt
Oct 6 16:05:52 buster goveebttemplogger[4131]: [2024-10-06T23:05:52] Reading: /var/www/html/goveebttemplogger/gvh-A4C1381A352C-2023-12.txt
Oct 6 16:06:47 buster goveebttemplogger[4131]: [2024-10-06T23:06:47] Reading: /var/www/html/goveebttemplogger/gvh-A4C1381A352C-2024-01.txt
Oct 6 16:07:42 buster goveebttemplogger[4131]: [2024-10-06T23:07:42] Reading: /var/www/html/goveebttemplogger/gvh-A4C1381A352C-2024-02.txt
Oct 6 16:08:01 buster goveebttemplogger[4131]: [2024-10-06T23:08:01] Reading: /var/www/html/goveebttemplogger/gvh-A4C1381A352C-2024-03.txt
Oct 6 16:08:17 buster goveebttemplogger[4131]: [2024-10-06T23:08:17] Reading: /var/www/html/goveebttemplogger/gvh-A4C1381A352C-2024-04.txt
Oct 6 16:08:58 buster goveebttemplogger[4131]: [2024-10-06T23:08:58] Reading: /var/www/html/goveebttemplogger/gvh-A4C1381A352C-2024-05.txt
Oct 6 16:09:44 buster goveebttemplogger[4131]: [2024-10-06T23:09:44] Reading: /var/www/html/goveebttemplogger/gvh-A4C1381A352C-2024-06.txt
Oct 6 16:10:31 buster goveebttemplogger[4131]: [2024-10-06T23:10:31] Reading: /var/www/html/goveebttemplogger/gvh-A4C1381A352C-2024-07.txt
Oct 6 16:11:22 buster goveebttemplogger[4131]: [2024-10-06T23:11:22] Reading: /var/www/html/goveebttemplogger/gvh-A4C1381A352C-2024-08.txt
Oct 6 16:11:50 buster goveebttemplogger[4131]: [2024-10-06T23:11:50] Reading: /var/www/html/goveebttemplogger/gvh-A4C1381A352C-2024-09.txt
Oct 6 16:12:33 buster goveebttemplogger[4131]: [2024-10-06T23:12:33] Reading: /var/www/html/goveebttemplogger/gvh-A4C1381A352C-2024-10.txt
Oct 6 16:12:39 buster goveebttemplogger[4131]: [2024-10-06T23:12:39] Reading: /var/www/html/goveebttemplogger/gvh-A4C138DB1B37-2024-01.txt
Oct 6 16:12:39 buster goveebttemplogger[4131]: [2024-10-06T23:12:39] Reading: /var/www/html/goveebttemplogger/gvh-A4C138E43FC8-2023-09.txt
and that's the last entry for more than half an hour.
It finally finished after about an hour and 35 minutes. Not the end of the world, but maybe a place for some optimization one day.
I was running on a Pi4 and it was taking an hour to startup. That's why I developed the cache file option. When using a cache file in addition to the log file, it only works hard to integrate the new data logged since the cache was last written.
I've been running v2 for more than a year without any issue. It's been great, nice work! (400 days uptime!)
I made a small change to the goveebttemplogger.cpp to adjust the colors in the SVG output files.
I successfully rebuilt, reinstalled and relaunched the daemon. Unfortunately it's been stuck using nearly 100% of a core for more than an hour. I see from the README that "The causes the program to take longer to start up as it will attempt to read all of the old logged data into an internal memory structure as it starts." Wondering if it's going to finish in a reasonable amount of time, or if there's some exponential slowdown that I need to find another solution for.
Any suggestions?
The syslog looks like this:
and that's the last entry for more than half an hour.
And my log directory looks like this:
The text was updated successfully, but these errors were encountered: