starred/bambuddy

Fork 0

mirror of https://github.com/maziggy/bambuddy.git synced 2026-05-09 05:35:30 +02:00

[GH-ISSUE #1131] [Bug]: Camera Stream Freezing after 5-15 seconds of streaming #812

New issue

Closed

opened 2026-05-06 12:33:05 +02:00 by BreizhHardware · 3 comments

BreizhHardware commented

2026-05-06 12:33:05 +02:00

Owner

Originally created by @mrnoisytiger on GitHub (Apr 25, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1131

Originally assigned to: @maziggy on GitHub.

Component

Bambuddy

Bug Description

The camera stream appears to freeze reliably after about 5-15 seconds of streaming playback. Playback is otherwise smooth and unaffected while the camera stream is functioning. Clicking "reconnect" or restarting the stream results in playback starting again before freezing shortly after.

Expected Behavior

The camera should not freeze.

Steps to Reproduce

Click Camera Stream on a printer that is actively printing.
Wait 5-15 seconds.
The camera stream will freeze.

Printer Model

H2D

Bambuddy Version

v0.2.4b1-nightly

SpoolBuddy Version

No response

Printer Firmware Version

No response

Installation Method

Docker

Operating System

Linux (Ubuntu/Debian)

Relevant Logs / Support Package

bambuddy-support-20260425-154213.zip

Screenshots

No response

Additional Context

No response

Checklist

I have searched existing issues to ensure this bug hasn't already been reported
I am using the latest version of Bambuddy
My printer is set to LAN Only mode
My printer has Developer Mode enabled

Originally created by @mrnoisytiger on GitHub (Apr 25, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1131 Originally assigned to: @maziggy on GitHub. ### Component Bambuddy ### Bug Description The camera stream appears to freeze reliably after about 5-15 seconds of streaming playback. Playback is otherwise smooth and unaffected while the camera stream is functioning. Clicking "reconnect" or restarting the stream results in playback starting again before freezing shortly after. ### Expected Behavior The camera should not freeze. ### Steps to Reproduce 1. Click Camera Stream on a printer that is actively printing. 2. Wait 5-15 seconds. 3. The camera stream will freeze. ### Printer Model H2D ### Bambuddy Version v0.2.4b1-nightly ### SpoolBuddy Version _No response_ ### Printer Firmware Version _No response_ ### Installation Method Docker ### Operating System Linux (Ubuntu/Debian) ### Relevant Logs / Support Package [bambuddy-support-20260425-154213.zip](https://github.com/user-attachments/files/27089845/bambuddy-support-20260425-154213.zip) ### Screenshots _No response_ ### Additional Context _No response_ ### Checklist - [x] I have searched existing issues to ensure this bug hasn't already been reported - [x] I am using the latest version of Bambuddy - [x] My printer is set to LAN Only mode - [x] My printer has Developer Mode enabled

BreizhHardware

2026-05-06 12:33:05 +02:00

closed this issue
added the
Closed due to inactivity

bug
labels

BreizhHardware commented

2026-05-06 12:33:06 +02:00

Author

Owner

@maziggy commented on GitHub (Apr 26, 2026):

I went through bambuddy.log and the post‑fanout sessions on 2026‑04‑25 don't show any backend RTSP/ffmpeg
errors: no RTSP read timeout, no RTSP stream ended, no ffmpeg failed, and snapshot captures work the whole time. ffmpeg always exits via SIGTERM when you close the stream, never on its own. So whatever is freezing the picture is not a printer disconnect that we're currently catching.

To narrow this down to "stale frames out of ffmpeg" vs. "browser MJPEG decoder choking on H2D 1080p/15fps", could you grab three things on the next reproduction?

Let it stay frozen for 60+ seconds without clicking anything, then download a fresh support pack. We need to see whether RTSP read timeout for ... (stream_id=1-fanout) shows up after 30s of no frames. If it does → the printer's RTSP stream is stalling silently and we should reconnect at the backend. If it doesn't → ffmpeg is still producing JPEGs and the freeze is downstream.
Chrome DevTools → Network → the /printers/<id>/camera/stream row: while the image is frozen, watch the row's "Size" column. Is it still growing (KB ticking up), or is it stuck? Screenshot if possible.
Try lower fps: open the camera page and add ?fps=5 to the URL (e.g. /printers/1/camera?fps=5). If it stops freezing at 5 fps, it's the multipart‑MJPEG bitrate path in the browser, not the printer.

Also useful: browser + version (Chrome / Firefox / Safari, exact version) and OS, since this class of bug tends to be browser‑specific.

@maziggy commented on GitHub (Apr 26, 2026): I went through `bambuddy.log` and the post‑fanout sessions on 2026‑04‑25 don't show any backend RTSP/ffmpeg errors: no `RTSP read timeout`, no `RTSP stream ended`, no `ffmpeg failed`, and snapshot captures work the whole time. ffmpeg always exits via SIGTERM when *you* close the stream, never on its own. So whatever is freezing the picture is not a printer disconnect that we're currently catching. To narrow this down to "stale frames out of ffmpeg" vs. "browser MJPEG decoder choking on H2D 1080p/15fps", could you grab three things on the next reproduction? 1. **Let it stay frozen for 60+ seconds** without clicking anything, then download a fresh support pack. We need to see whether `RTSP read timeout for ... (stream_id=1-fanout)` shows up after 30s of no frames. If it does → the printer's RTSP stream is stalling silently and we should reconnect at the backend. If it doesn't → ffmpeg is still producing JPEGs and the freeze is downstream. 2. **Chrome DevTools → Network → the `/printers/<id>/camera/stream` row**: while the image is frozen, watch the row's "Size" column. Is it still growing (KB ticking up), or is it stuck? Screenshot if possible. 3. **Try lower fps**: open the camera page and add `?fps=5` to the URL (e.g. `/printers/1/camera?fps=5`). If it stops freezing at 5 fps, it's the multipart‑MJPEG bitrate path in the browser, not the printer. Also useful: browser + version (Chrome / Firefox / Safari, exact version) and OS, since this class of bug tends to be browser‑specific.

BreizhHardware commented

2026-05-06 12:33:06 +02:00

Author

Owner

@mrnoisytiger commented on GitHub (Apr 27, 2026):

Thanks for the additional steps! See the responses below!

bambuddy-support-20260426-205948.zip

It is continuing to grow even when the camera image is completely frozen, as if data is still being streamed.

I'm trying to get a stream at a lower FPS, but I do not appear to be able to change it. I'm going to https://bambu.redacted.com/camera/1?fps=1, but FPS continues to visually be 15fps and continues to freeze. I've tried your suggested path of https://bambu.redacted.com/printers/1/camera?fps=1, but I am getting a blank screen instead.

I am getting this issue on Edge 147.0.3912.72 and Firefox 147.0.2 equally. I am also getting this on Mobile Safari 26.4, so I suspect it is not a browser-related issue.

@mrnoisytiger commented on GitHub (Apr 27, 2026): Thanks for the additional steps! See the responses below! 1. [bambuddy-support-20260426-205948.zip](https://github.com/user-attachments/files/27109431/bambuddy-support-20260426-205948.zip) 2. It is continuing to grow even when the camera image is completely frozen, as if data is still being streamed. <img width="1617" height="1305" alt="Image" src="https://github.com/user-attachments/assets/509c3ecb-8f76-412c-adb7-f23652522eec" /> 3. I'm trying to get a stream at a lower FPS, but I do not appear to be able to change it. I'm going to `https://bambu.redacted.com/camera/1?fps=1`, but FPS continues to visually be 15fps and continues to freeze. I've tried your suggested path of `https://bambu.redacted.com/printers/1/camera?fps=1`, but I am getting a blank screen instead. I am getting this issue on Edge 147.0.3912.72 and Firefox 147.0.2 equally. I am also getting this on Mobile Safari 26.4, so I suspect it is not a browser-related issue.

BreizhHardware commented

2026-05-06 12:33:06 +02:00

Author

Owner

@maziggy commented on GitHub (Apr 27, 2026):

Thanks for the test results — they actually nail down where the freeze is not.

Quick correction on my earlier suggestions:

The route I gave you (/printers/1/camera) was wrong, sorry. The correct path is /camera/1. But even there, ?fps=1 would not have done anything: the camera page hard-codes fps=15 in the request and does not read the URL parameter. That is a small frontend bug I will fix so we have a working knob — but it is not the root cause.

Available/Fixed in branch dev and available with the next release or daily build.

What the support pack tells us:

Six days of logs, zero RTSP timeouts, zero ffmpeg failures, zero stream restarts.
The camera/snapshot endpoint (which spawns a fresh ffmpeg per request, independent of the live stream pipeline) was being hit every ~12 seconds during your freeze window on 2026-04-26 20:50–20:52, and the returned JPEG byte counts were all different (249k, 285k, 220k, 207k, 275k, 261k, 207k, 227k, 269k, 288k). If the camera were truly stuck, those would be near-identical.

So the printer, RTSP, and ffmpeg pipeline are healthy at the moment your dashboard image freezes. The bytes that keep flowing in DevTools are real, distinct frames — they just are not landing in the browser as a swap.

The redacted hostname (bambu.redacted.com) suggests you are reaching Bambuddy through a reverse proxy with HTTPS. That is by far the most common cause of this exact symptom: long-running multipart/x-mixed-replace MJPEG over HTTP/2 (Cloudflare, modern nginx, Caddy, Traefik) often buffers chunks at the proxy layer until the browser sees a partial multipart boundary and stops advancing, while bytes keep accumulating on the wire.

Could you share:

What reverse proxy or HTTPS termination you have in front of Bambuddy (Cloudflare Tunnel, nginx-proxy-manager, Caddy, Traefik, etc.) and whether HTTP/2 is enabled there?
A direct-to-Bambuddy test: from a machine on the same LAN as the Bambuddy host, open http://:/camera/1 (no proxy, no TLS) for 5–10 minutes and let me know if the image freezes there too. If it does not freeze direct-to-LAN but does through bambu.redacted.com, the proxy is the cause.
During a freeze, hit https://bambu.redacted.com/api/v1/printers/1/camera/snapshot?t=$(date +%s) a few times (or just open it in a new tab and add a query bust). If the snapshot returns fresh, different images while the stream is frozen, that confirms the upstream is fine and the issue is purely in the streaming response path.

Quick mitigations to try if it does turn out to be H2 buffering:

Cloudflare: bypass the camera path with a Cache Rule -> Bypass and disable Argo, or proxy /api/v1/printers/*/camera/stream directly to Bambuddy from a local nginx instead of going through Cloudflare.
nginx: set proxy_http_version 1.1; proxy_buffering off; proxy_cache off; proxy_request_buffering off; and force HTTP/1.1 on the upstream side. Also chunked_transfer_encoding on;.
Caddy: reverse_proxy ... { transport http { versions 1.1 } flush_interval -1 }.

@maziggy commented on GitHub (Apr 27, 2026): Thanks for the test results — they actually nail down where the freeze is not. Quick correction on my earlier suggestions: - The route I gave you (/printers/1/camera) was wrong, sorry. The correct path is /camera/1. But even there, ?fps=1 would not have done anything: the camera page hard-codes fps=15 in the request and does not read the URL parameter. That is a small frontend bug I will fix so we have a working knob — but it is not the root cause. Available/Fixed in branch dev and available with the next release or daily build. What the support pack tells us: - Six days of logs, zero RTSP timeouts, zero ffmpeg failures, zero stream restarts. - The camera/snapshot endpoint (which spawns a fresh ffmpeg per request, independent of the live stream pipeline) was being hit every ~12 seconds during your freeze window on 2026-04-26 20:50–20:52, and the returned JPEG byte counts were all different (249k, 285k, 220k, 207k, 275k, 261k, 207k, 227k, 269k, 288k). If the camera were truly stuck, those would be near-identical. So the printer, RTSP, and ffmpeg pipeline are healthy at the moment your dashboard image freezes. The bytes that keep flowing in DevTools are real, distinct frames — they just are not landing in the browser as a swap. The redacted hostname (bambu.redacted.com) suggests you are reaching Bambuddy through a reverse proxy with HTTPS. That is by far the most common cause of this exact symptom: long-running multipart/x-mixed-replace MJPEG over HTTP/2 (Cloudflare, modern nginx, Caddy, Traefik) often buffers chunks at the proxy layer until the browser sees a partial multipart boundary and stops advancing, while bytes keep accumulating on the wire. Could you share: 1. What reverse proxy or HTTPS termination you have in front of Bambuddy (Cloudflare Tunnel, nginx-proxy-manager, Caddy, Traefik, etc.) and whether HTTP/2 is enabled there? 2. A direct-to-Bambuddy test: from a machine on the same LAN as the Bambuddy host, open http://<bambuddy-host>:<port>/camera/1 (no proxy, no TLS) for 5–10 minutes and let me know if the image freezes there too. If it does not freeze direct-to-LAN but does through bambu.redacted.com, the proxy is the cause. 3. During a freeze, hit https://bambu.redacted.com/api/v1/printers/1/camera/snapshot?t=$(date +%s) a few times (or just open it in a new tab and add a query bust). If the snapshot returns fresh, different images while the stream is frozen, that confirms the upstream is fine and the issue is purely in the streaming response path. Quick mitigations to try if it does turn out to be H2 buffering: - Cloudflare: bypass the camera path with a Cache Rule -> Bypass and disable Argo, or proxy /api/v1/printers/*/camera/stream directly to Bambuddy from a local nginx instead of going through Cloudflare. - nginx: set proxy_http_version 1.1; proxy_buffering off; proxy_cache off; proxy_request_buffering off; and force HTTP/1.1 on the upstream side. Also chunked_transfer_encoding on;. - Caddy: reverse_proxy ... { transport http { versions 1.1 } flush_interval -1 }.