Bug: "Enable camera on print start" toggle is ignored (Camera always activates and forces itself back on) #50

New Issue

Alex_M · 2026-06-07T22:17:04+02:00

Alex_M commented

2026-06-07 22:17:04 +02:00

Hi again!

Since you guys are on fire with the fixes, I wanted to report another minor but stubborn bug regarding the camera management in the bridge settings.

In the KX-Bridge interface, there is a configuration toggle named "Enable camera on print start".

The Issue:
This setting is currently being ignored by the bridge logic. Even when the toggle is explicitly set to Disabled / OFF, the printer's native camera automatically activates the moment a new print job begins.

Furthermore, if I manually turn off the camera stream from the bridge web interface during a print, it doesn't stay off. After a few moments, it automatically forces itself back ON.

Possible Cause:
It feels like there is either a hardcoded override triggered by the print start event (perhaps tied to the native Anycubic MQTT print start sequence) that ignores the GUI config state, or a background keep-alive loop that continuously checks and forces the camera status back to enabled regardless of user interaction.

This behavior is a bit annoying if someone prefers to keep the native camera off to save bandwidth or hardware resources (especially since some of us are using secondary webcams for monitoring).

Let me know if you need any logs from the container when a print starts! Thanks again for your awesome work.

Hi again! Since you guys are on fire with the fixes, I wanted to report another minor but stubborn bug regarding the camera management in the bridge settings. In the KX-Bridge interface, there is a configuration toggle named "Enable camera on print start". The Issue: This setting is currently being ignored by the bridge logic. Even when the toggle is explicitly set to Disabled / OFF, the printer's native camera automatically activates the moment a new print job begins. Furthermore, if I manually turn off the camera stream from the bridge web interface during a print, it doesn't stay off. After a few moments, it automatically forces itself back ON. Possible Cause: It feels like there is either a hardcoded override triggered by the print start event (perhaps tied to the native Anycubic MQTT print start sequence) that ignores the GUI config state, or a background keep-alive loop that continuously checks and forces the camera status back to enabled regardless of user interaction. This behavior is a bit annoying if someone prefers to keep the native camera off to save bandwidth or hardware resources (especially since some of us are using secondary webcams for monitoring). Let me know if you need any logs from the container when a print starts! Thanks again for your awesome work.

viewit commented

2026-06-08 19:30:57 +02:00

Thanks for the detailed report — the root cause is now identified and fixed.

What was happening

There were two separate issues:

Camera forces itself back on after manual stop: The bridge web UI calls applyState() on every poll cycle (~2–3s). It had an auto-start condition: "if print is running and camera is not on → start camera." So every time you stopped the camera manually, the next poll would restart it. This had nothing to do with camera_on_print — it was a UI-level loop.
"Stream unavailable" error toast on manual stop: When camStop() cleared img.src, the browser fired the existing img.onerror handler for the still-open stream connection, which logged an error toast.

The fix (in progress, will be in the next release)

camStop() in the UI now sets a camUserStopped flag and clears img.onerror before resetting src — no more spurious error toast.
applyState() checks camUserStopped before auto-starting — camera stays off for the remainder of the print.
Flag resets automatically when the print ends, so the next print auto-starts the camera normally again.
As a belt-and-suspenders measure, handle_api_camera_stop() in the bridge backend also sets a _camera_user_stopped flag to block any backend-side auto-start triggers.

The camera_on_print toggle itself was working correctly all along — it controls the initial auto-start, not the keep-alive behavior.

Thanks for the detailed report — the root cause is now identified and fixed. **What was happening** There were two separate issues: 1. **Camera forces itself back on after manual stop:** The bridge web UI calls `applyState()` on every poll cycle (~2–3s). It had an auto-start condition: *"if print is running and camera is not on → start camera."* So every time you stopped the camera manually, the next poll would restart it. This had nothing to do with `camera_on_print` — it was a UI-level loop. 2. **"Stream unavailable" error toast on manual stop:** When `camStop()` cleared `img.src`, the browser fired the existing `img.onerror` handler for the still-open stream connection, which logged an error toast. **The fix (in progress, will be in the next release)** - `camStop()` in the UI now sets a `camUserStopped` flag and clears `img.onerror` before resetting `src` — no more spurious error toast. - `applyState()` checks `camUserStopped` before auto-starting — camera stays off for the remainder of the print. - Flag resets automatically when the print ends, so the next print auto-starts the camera normally again. - As a belt-and-suspenders measure, `handle_api_camera_stop()` in the bridge backend also sets a `_camera_user_stopped` flag to block any backend-side auto-start triggers. The `camera_on_print` toggle itself was working correctly all along — it controls the initial auto-start, not the keep-alive behavior.

viewit closed this issue

2026-06-09 13:13:45 +02:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: viewit/KX-Bridge-Release#50