Fix stat widgets freezing permanently after a transient sensor error

[axectly]

Problem

A stat widget can freeze permanently while the rest of the program keeps running fine. It happens at random, after minutes or hours, and nothing is written to log.log.

Three things combine:

1. A scheduled job that raises kills its thread for good. Each stat is scheduled in its own thread with its own sched.scheduler (library/scheduler.py). An exception raised by the job propagates out of scheduler.run(), the thread exits and that widget is never updated again. The traceback is invisible in the packaged Windows executable, because threading.excepthook writes to sys.stderr, which is None there.

2. ping3 returns None instead of a number. On a ping timeout, Ping.stats() raises at int(delay). The None is also stored in the line graph history, and DisplayLineGraph() calls math.isnan() on every stored value, which raises on None for as long as the value stays in the buffer.

3. int() is called on values that are math.nan. Sensors already use math.nan to report "no value" — LibreHardwareMonitor does it for CPU load and fan speed when it cannot read them — but the display helpers convert with int(), which raises ValueError. For display_themed_percent_radial_bar() and display_themed_percent_value() the conversion happens before the SHOW check inside the called function, so the stat crashes even when the widget is hidden. This looks like the cause of #718.

Observed on Windows 11 / Python 3.13, HW_SENSORS: AUTO (LHM), Wi-Fi connection, PING: 8.8.8.8.

Cause 2, during a short network outage:

[ERROR] Scheduled job 'PingStats' failed, skipping this cycle
Traceback (most recent call last):
  File "library\scheduler.py", line 195, in PingStats
    stats.Ping.stats()
  File "library\stats.py", line 936, in stats
    value=int(delay),
TypeError: int() argument must be a string, a bytes-like object or a real number, not 'NoneType'

and then, on the following cycles, once the network was back:

  File "library\stats.py", line 946, in stats
    display_themed_line_graph(theme_data['LINE_GRAPH'], cls.last_values_ping)
  File "library\lcd\lcd_comm.py", line 458, in DisplayLineGraph
    if not math.isnan(value):
TypeError: must be real number, not NoneType

Cause 3, twice in one day, with RADIAL not even shown in the theme:

[ERROR] Scheduled job 'CPUPercentage' failed, skipping this cycle
Traceback (most recent call last):
  File "library\stats.py", line 284, in percentage
  File "library\stats.py", line 208, in display_themed_percent_radial_bar
ValueError: cannot convert float NaN to integer

(the [ERROR] Scheduled job ... lines come from this PR; without it the thread dies silently at the first traceback)

Changes

• library/scheduler.py: wrap the scheduled call in try/except, log the failure and keep going — the next run is already scheduled at that point, so the stat just skips one cycle. Logging is rate-limited to one message per second per job, because QueueHandler runs every millisecond and a permanently failing job would otherwise flood log.log (which rotates at 1 MB).
• library/stats.py: normalize a missing ping delay to math.nan and skip, for that cycle, the widgets that need a number. save_last_value() maps None to math.nan as well, so no sensor returning None can poison a graph history — math.nan is already this code's "no data" marker, see last_values_list().
• library/stats.py: skip drawing in the display helpers when the value is None or nan, instead of letting int() raise.

The changes are complementary: the last two remove the two known ways a stat can raise, the first one makes sure that any remaining one only costs a cycle instead of the whole thread, and becomes visible in the log.

SystemExit and KeyboardInterrupt derive from BaseException and are not caught, so the clean shutdown path in main.py is unaffected.

Tested on a Turing 5" (rev C) with Windows 11 and Python 3.13.

---

🤖 Generated with Claude Code