[GH-ISSUE #1011] [Bug]: Archive replay prints may not emit the same printer events as Studio-submitted prints #711

New issue

Closed

opened 2026-05-07 00:13:04 +02:00 by BreizhHardware · 1 comment

BreizhHardware commented

2026-05-07 00:13:04 +02:00

Owner

Originally created by @PurseChicken on GitHub (Apr 17, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1011

Originally assigned to: @maziggy on GitHub.

Bug Description

When printing a file via Bambuddy's archive re-print feature, third-party tools that monitor the printer over MQTT (specifically OctoEverywhere, in my testing) report wildly wrong print durations on completion. The same file printed via Studio → Bambuddy proxy → printer reports correct durations.
My hypothesis is that Bambuddy's archive-reprint path submits the print to the printer using a different mechanism than a Studio-forwarded print, and the printer doesn't publish the same MQTT events (likely print.gcode_start_time or the equivalent state transition) that signal "a new print has started right now." Third-party tools that rely on those events to time the print see the printer enter a printing state but never receive a clean start signal, so they fall back to stale references.

Expected Behavior

Archive-replay prints should trigger the same printer-side MQTT events as Studio-submitted prints, so that third-party tools monitoring the printer can time the job correctly.

Steps to Reproduce

Controlled test with the same print file:

Print from Bambu Studio, with Bambuddy acting as the proxy printer (Studio → Bambuddy → P1S). OctoEverywhere reports correct duration (45 min actual, 45 min reported). ✅
Re-print the same file from Bambuddy's archive. OctoEverywhere reports wildly wrong duration (40 min actual, 1h 40m reported). ❌
Re-print the same file from archive again. Duration is wrong again, and the error appears to grow — on the second archive replay the reported duration was ~4 hours for a ~45 minute print. The "extra" time roughly matches the elapsed clock time since the previous archive replay of the same file, which suggests the printer (or something in the flow) may be reusing a stale start timestamp for repeat archive replays.

Printer Model

P1S

Bambuddy Version

v0.2.3b3

Printer Firmware Version

01.10.00.00

Installation Method

Other

Operating System

Linux (Ubuntu/Debian)

Relevant Logs / Support Package

No response

Screenshots

No response

Additional Context

I also filed a related report with OctoEverywhere, since there's an argument they should handle the missing start event more gracefully on their side. But I wanted to flag this here too because the cleaner fix is probably to make archive replays behave identically to Studio prints from the printer's perspective — that way any third-party integration benefits, not just OE.
Happy to test anything, capture MQTT traces, or provide more detail if useful.

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 @PurseChicken on GitHub (Apr 17, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1011 Originally assigned to: @maziggy on GitHub. ### Bug Description When printing a file via Bambuddy's archive re-print feature, third-party tools that monitor the printer over MQTT (specifically OctoEverywhere, in my testing) report wildly wrong print durations on completion. The same file printed via Studio → Bambuddy proxy → printer reports correct durations. My hypothesis is that Bambuddy's archive-reprint path submits the print to the printer using a different mechanism than a Studio-forwarded print, and the printer doesn't publish the same MQTT events (likely print.gcode_start_time or the equivalent state transition) that signal "a new print has started right now." Third-party tools that rely on those events to time the print see the printer enter a printing state but never receive a clean start signal, so they fall back to stale references. ### Expected Behavior Archive-replay prints should trigger the same printer-side MQTT events as Studio-submitted prints, so that third-party tools monitoring the printer can time the job correctly. ### Steps to Reproduce Controlled test with the same print file: Print from Bambu Studio, with Bambuddy acting as the proxy printer (Studio → Bambuddy → P1S). OctoEverywhere reports correct duration (45 min actual, 45 min reported). ✅ Re-print the same file from Bambuddy's archive. OctoEverywhere reports wildly wrong duration (40 min actual, 1h 40m reported). ❌ Re-print the same file from archive again. Duration is wrong again, and the error appears to grow — on the second archive replay the reported duration was ~4 hours for a ~45 minute print. The "extra" time roughly matches the elapsed clock time since the previous archive replay of the same file, which suggests the printer (or something in the flow) may be reusing a stale start timestamp for repeat archive replays. ### Printer Model P1S ### Bambuddy Version v0.2.3b3 ### Printer Firmware Version 01.10.00.00 ### Installation Method Other ### Operating System Linux (Ubuntu/Debian) ### Relevant Logs / Support Package _No response_ ### Screenshots _No response_ ### Additional Context I also filed a related report with OctoEverywhere, since there's an argument they should handle the missing start event more gracefully on their side. But I wanted to flag this here too because the cleaner fix is probably to make archive replays behave identically to Studio prints from the printer's perspective — that way any third-party integration benefits, not just OE. Happy to test anything, capture MQTT traces, or provide more detail if useful. ### 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-07 00:13:04 +02:00

closed this issue
added the
bug
label

BreizhHardware commented

2026-05-07 00:13:05 +02:00

Author

Owner

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

Your debugging is spot on!

Available/Fixed in branch dev and available with the next release or daily build. Please let me know if it works for you now.

If you find Bambuddy useful, please consider giving it a ⭐ on GitHub — it helps others discover the project!

@maziggy commented on GitHub (Apr 18, 2026): Your debugging is spot on! Available/Fixed in branch dev and available with the next release or daily build. Please let me know if it works for you now. ----- If you find Bambuddy useful, please consider giving it a ⭐ on [GitHub](https://github.com/maziggy/bambuddy) — it helps others discover the project!

BreizhHardware referenced this issue

2026-05-07 00:16:02 +02:00

[PR #711] [MERGED] [Fix]: Ensures AMS-HT devices are properly identified in Spoolman #1105