mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-05-09 08:25:54 +02:00
[GH-ISSUE #1089] Feature: Camera stream fan-out — support multiple concurrent viewers per printer #775
Labels
No labels
A1
automated
automated
bug
bug
Closed due to inactivity
contrib
dependencies
dependencies
duplicate
enhancement
feedback
hold
invalid
Notes
P1S
pull-request
security
ThumbsUp
user-report
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/bambuddy-maziggy-1#775
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @swheettaos on GitHub (Apr 22, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1089
Originally assigned to: @maziggy on GitHub.
Problem
Currently each request to
/api/v1/printers/{id}/camera/streamopens anindependent connection to the physical printer:
ffmpegprocess per viewerMost Bambu Lab printers only support one simultaneous camera connection.
The second viewer gets a failed/empty stream while the first is connected.
Relevant code:
backend/app/api/routes/camera.py—_active_streamsis keyedby
stream_id(unique per viewer), notprinter_id. There is no sharedbroadcast mechanism.
Proposed Solution
Add an in-process fan-out broadcaster per printer: BamBuddy opens exactly
one upstream connection, buffers each frame, and pushes copies to N subscriber
queues. New viewers tap the existing connection; no new printer connection is made.
1. Broadcaster class (
backend/app/services/camera_fanout.py)2. Single upstream pump per printer
3. Updated stream endpoint
Expected Behaviour After Fix
Printer models affected
All models — most visibly A1, P1P, P1S (chamber image protocol) and P2S
(RTSP, single session). X1C may tolerate two connections on some firmware
versions but is still affected.
Implementation notes
QueueFullon slow viewers drops frames rather than blocking fast ones — correct behaviour for live videosubscriber_count() == 0to avoid holding an idle connection to the printer_last_frames[printer_id]for snapshot capture can be populated by the broadcaster pump instead of per-viewer generators, simplifying existing code@swheet-etr commented on GitHub (Apr 22, 2026):
I got around this by creating a seperate pod in my cluster that uses nginx with go2rtc sidecar and intercepts the api call (I have a seperate public URL for just viewing). It works but I'd rather not have to do that. Native support would be better.
the nginx also ensures only certian API's are accessible and also limits api calls to "get". I want a secure locked down anomymous "viewer" .. it works for me .. the only problem I had was the multi-user view stream on a P1S ..
THANK YOU for all the hard work on this!
@maziggy commented on GitHub (Apr 25, 2026):
Available/Fixed in branch dev and available with the next release or daily build. Please let me know if it works for you.
If you find Bambuddy useful, please consider giving it a ⭐ on GitHub — it helps others discover the project!