2 Commits

Include renames

Author	SHA1	Message	Date
ChuckandClaude Opus 5.5	84afa9d64f	refactor: delete dead Python code in the core (and stop storing Wi-Fi passwords) (#608) ... * refactor(plugins): remove the no-op PluginHealthMonitor Its monitor loop did nothing (`if callbacks: pass`), register_health_check had no callers and api_v3.health_monitor was never read by any route. The live health data comes from PluginHealthTracker, which is untouched. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * refactor(store): drop the never-set uninstall tombstones Nothing in production called mark_recently_uninstalled, so the reconciler's was_recently_uninstalled check was always False. The persistent uninstall registry is what actually stops resurrection; the reconciler test now exercises that gate instead. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * refactor(common): delete unused config/display/game helpers, utils and error_handler Nothing in core, the web UI, scripts or the plugin monorepo imports config_helper, display_helper, game_helper, utils or error_handler; only their own tests did. The error_handler re-exports leave src.common's __all__; APIHelper, TextHelper, ScrollHelper, LogoHelper and the adaptive layout exports are unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * refactor(config): drop ConfigService's unused versioning and save API ConfigVersion, get_version/get_version_history/get_version_config, rollback, save_config, reload, get_plugin_config and the backward-compat load_config/get_config_path/get_secrets_path had no callers. The display controller only uses get_config, subscribe, unsubscribe and shutdown, plus the file watcher. Change detection now compares against the current checksum instead of the last history entry. The subscriber tests asserted `callback.called or True`; they now reload the way the watcher does and assert the notification. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * refactor(plugins): drop unread plugin state history and callbacks plugin_state.PluginStateManager kept a bounded per-plugin transition history that only get_state_history (tests only) read; get_state_info reports a separate lifetime count, which stays. set_error_info and record_display had no callers, and set_state_with_error's `error` argument only fed the history. The web-side state_manager.PluginStateManager loses subscribe_to_state_changes, _notify_callbacks, set_plugin_error and get_state_version, none of which had callers; with no subscribers the old-state copy in update_plugin_state went with them. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * refactor(plugins): remove unused PluginManager methods and attribute guards update_all_plugins was only called by a test (the display loop uses run_scheduled_updates); get_plugin_health_metrics, get_plugin_resource_metrics and get_plugin_state had no callers; and plugin_modules was written but never read. plugin_directories is now initialised in __init__, so the hasattr() guards around it go. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * refactor(plugins): remove unused executor, loader, store and package helpers - PluginExecutor.execute_safe: no callers. - PluginLoader._parse_semver: only its own tests; compatibility.parse_semver is the live copy and test_compatibility.py already covers it. - PluginStoreManager.get_installed_plugin_info: no callers. - PluginResourceMonitor._local: never read. - src.plugin_system.get_store_manager and __api_version__: no importers in core, scripts or the plugin monorepo. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(wifi): stop storing Wi-Fi passwords in wifi_config.json WiFiManager appended every joined network's SSID and password, in plaintext, to saved_networks in config/wifi_config.json, and nothing (web UI, backup restore, scripts) ever read them back: NetworkManager keeps its own credentials. The writes are gone, and loading the config now drops any saved_networks key and rewrites the file, so passwords already on disk are scrubbed. Also removes _check_dnsmasq_conflict (never called) and _detect_trixie, whose result only reached one log line, along with the NM_CONNECTIONS_PATHS constant only it used. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * refactor(display): remove unreachable and unused DisplayController code - _follower_rebuild_scroll_image: never called. - mode_duration (never read) and last_mode_change (write-only). - The `chosen_cap <= 0` branch: chosen_cap is either the minimum of caps already filtered to > 0 or DEFAULT_DYNAMIC_DURATION_CAP (180). - The `max_duration < min_duration` branch directly after `max_duration = max(min_duration, max_duration)`. - The circuit-breaker branch's `display_result = False` and `manager_to_display = None`: the first is overwritten a few lines later, the second is already None there. - The bool-to-bool conversion of execute_display's result, which is always a bool. - The `loaded_plugins` lookup in _update_modules: PluginManager has no such attribute, so it always fell through to `plugins`. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * refactor(vegas): remove unused config update, boundary finder and refresh VegasModeConfig.update had no callers outside its own tests (the coordinator rebuilds the config with from_config on a change); geometry.find_item_boundary and StreamManager._refresh_plugin_content had no callers at all. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * refactor(run): drop the debug block that pretended to import the plugin system In debug mode run.py put src/plugin_system itself on sys.path and printed "Plugin system import successful" without importing anything. Nothing imports plugin_system modules by bare name, so the path entry did nothing either. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test: delete tests that test nothing - test/plugins/test_{basketball_scoreboard,calendar,clock_simple, odds_ticker,soccer_scoreboard,text_display}.py skip everywhere the named plugins are not installed, including CI (LEDMATRIX_PLUGINS_DIR holds only the fixture plugin); test_plugin_matrix.py already covers every discovered plugin. Their PluginTestBase and the fixtures only it used (plugins_dir, mock_display_manager, mock_cache_manager, mock_plugin_manager, base_plugin_config in test/plugins/conftest.py) go with them. - test_plugin_system.py: test_discover_plugins (body was `pass`) and test_dependency_check (a comment), plus the test_plugin_manager fixture only the former requested. - test_display_manager.py: test_draw_image asserted that an image it had just assigned was not None. - test_display_controller.py: the rotation and schedule-override tests re-implemented the run-loop arithmetic inline and asserted on their own result without calling the controller. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test: expect one plugin_last_update success stamp after update_all_plugins EveryStampRecordsACompletion required at least two success-path stamps; the second was update_all_plugins, removed as test-only. The worker and synchronous paths share the remaining stamp in _execute_update_now, and the check that every stamp calls _note_update_completed is unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>	2026-09-23 12:36:26 -04:00
ChuckandClaude Opus 5	9cf30bbbef	fix(startup): bound the initial plugin update so the panel lights sooner (#456) ... * fix(startup): bound the initial plugin update so the panel lights sooner DisplayController.__init__ calls _update_modules() once to populate plugin data before the first frame. It walks every loaded plugin in turn, and each update blocks the calling thread for up to the executor's 30s timeout, so the uncapped total is the sum of every slow plugin on the system. The rig's own log: Initial plugin update completed in 82.255 seconds Initial plugin update completed in 55.123 seconds Initial plugin update completed in 25.975 seconds The panel shows nothing for all of it. Nothing is lost by stopping early. A plugin that has never updated is immediately due, so run_scheduled_updates() collects it seconds later -- with the display already running rather than blank. A deadline alone was not enough: it is checked before each plugin, so the last one to start could still block for the full 30s, and a 20s budget produced a 31.8s pass on the rig. The remaining budget is now passed down as that update's timeout too, with a floor so a plugin starting on the last sliver is not handed ~0s and recorded as having timed out for a slot it never had. Measured after: 20.006s. Found while profiling a scroll freeze with py-spy, which caught the main thread 9.34s inside execute_with_timeout's join. Worth being clear that this is startup latency, not the recurring stutter -- _update_modules has exactly one caller and runtime updates already run off the display thread. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Udr6MfaFLUPhX5Fgo67Jf5 * feat(display): show the device address on the startup screen That screen is what the panel holds for the whole initial plugin update, and on a headless Pi it is the only place the address appears without going looking for it -- so it now carries the address under "Initializing". The lookup connects a UDP socket, which sends no packets: it only asks the kernel which source address it would route from. That costs 0.03ms and works with the network down so long as a route exists. Deliberately not `hostname -I` plus a systemctl probe for AP mode, which is how the web launcher does it -- two subprocesses with multi-second timeouts, on the startup path this branch exists to shorten. Two things had to change for the address to be worth putting there. The text is now sized to fit rather than fixed at 8px: "Initializing" is 96px in PressStart2P, drawn at x=10, so it already ran off the side of a 64px panel before an address was added. It falls back to 4x6 where that does not fit, and both lines are centred. And the test pattern is punched out from behind the block, with the text drawn white rather than blue. The diagonal runs through the middle of the panel, which is exactly where this sits, and blue on black reads fine on a monitor but is marginal on a dim panel. An address that cannot be read off the wall is not worth showing. The rendering tests assert against pixels -- no green left behind the text at any supported size, enough lit pixels to be visible -- rather than against the geometry that produced them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Udr6MfaFLUPhX5Fgo67Jf5 * fix(display): keep the startup text blue -- it is a channel reference The test pattern lights one pure channel per element: red border, green diagonal, blue text. That is how a glance at the panel tells you whether led_rgb_sequence is right -- wire it BGR and the border comes up blue and the text red. Drawing the text white, as the previous commit did for contrast, lights all three channels and destroys the only blue reference on the screen. Reverted to blue, with the reason written down so it is not treated as a style preference again, and with tests that pin it: the text must be pure blue, nothing on the screen may be white, and all three primaries must be present. The punched-out backdrop stays. It only removes the diagonal from behind the glyphs, which costs nothing diagnostically -- the diagonal is still plainly visible across the rest of the panel -- and it is what makes the address readable at all. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Udr6MfaFLUPhX5Fgo67Jf5 * fix(startup): defer a plugin with too little budget, rather than clamp it The per-plugin timeout was clamped up to a floor, so a plugin that began with a sliver of budget left was granted the full floor and ran on past the deadline: a 20s budget could take 22. The floor existed to stop a plugin being handed a slot too short to use and then recorded as having timed out, which is a real concern, but clamping solved it by breaking the bound. Deferring solves both. Below the floor the plugin is left to the update tick, which was already the fate of everything after the deadline, so nothing new is lost -- a plugin that has never updated is immediately due. Above it, the timeout is the exact remainder, and the pass cannot outlast its deadline. Measured on the rig after the change: 20.002s, 5 plugins deferred. Also names an unused binding in the initializing-screen test. Both reported by CodeRabbit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Udr6MfaFLUPhX5Fgo67Jf5 --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-12 14:58:05 -04:00