A testing-<sha> build has no Gitea releases (the testing workflow builds only
a Docker image), so the in-app update check must not fall through to the
stable path - which would wrongly offer a stable "update". handle_api_update_check
now short-circuits for a "testing" version with docker_only:true and nothing
to update (no Gitea round-trip at all), and handle_api_update_apply refuses
self-update on the testing channel the same way it already does for nightly.
Two new tests cover both. (Mirrors the same fix already on the testing
branch, applied here to the pre-refactor monolithic module.)
Found during a targeted code review, not from a user report:
- _run_jpeg_loop()/_run_h264_loop() operated directly on the shared
self._proc_jpeg/self._proc_h264 instance attributes in their cleanup,
unlike _run_mjpeg_loop() (already fixed for exactly this) which uses a
local `proc` reference. If a loop's task is cancelled - e.g. by
CameraCache.reset() after the printer rotates its stream URL on reboot -
while a new task has already started and assigned its own process to the
shared attribute, the cancelled task's cleanup killed the NEWER process
instead of its own, leaking its own ffmpeg child as an orphan. Applied
the same local-variable + identity-check pattern already used by
_run_mjpeg_loop.
- handle_api_settings_post and handle_api_update_apply were the only two
of ~84 handlers that called `await request.json()` without a try/except -
every other handler follows the established pattern of returning a clean
400 for a malformed body. A trivial malformed request to either endpoint
produced an unhandled 500 with a full traceback instead.
New tests in tests/test_camera_process_race.py,
tests/test_settings.py, and tests/test_update_check.py cover both.
Issue #103: the printer has no MQTT-level command to power off or enter
standby, so users on a separate-room setup have to physically walk over
or use a smart plug (e.g. Tasmota) manually. Added per-printer
power_on_url/power_off_url/power_status_url config (Settings > Power
Switch) and a power button with a live on/off indicator on each printer's
card in the Printers grid - plain HTTP GET calls, no Moonraker
device_power dependency.
Issue #104: the stable-release update check only ever requested the
single newest Gitea release (limit=1) regardless of type. Since
nightly/dev prereleases publish far more often than stable ones, that
newest release is almost always a prerelease, so the "not a prerelease"
filter found nothing and reported "no stable releases found" even
though a newer stable release existed further back in the list.
Fixed by requesting enough releases (limit=20) to look past a run of
prereleases.
Also fixes a related pre-existing bug surfaced while testing #103's
config: configparser's default string interpolation rejected any
config.ini value containing a literal '%' (ValueError: invalid
interpolation syntax) - this broke saving Tasmota-style power URLs
(cmnd=Power%20on) and would have broken any other value with a '%'
character. Fixed globally with interpolation=None on every
ConfigParser() instantiation in config_loader.py and
kobrax_moonraker_bridge.py.
