starred/bambuddy

Fork 0

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

[GH-ISSUE #1006] [Bug]: Print does not start automatically #705

New issue

Closed

opened 2026-05-06 12:32:05 +02:00 by BreizhHardware · 6 comments

BreizhHardware commented

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

Owner

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

Originally assigned to: @maziggy on GitHub.

Bug Description

Hello,

When I want to start prints, the file is sent to the printers but the print does not start automatically. I have to start it manually.

This happens when the printers have been turned on for some time, or when I have not restarted Buddy for a while.

This is the case with A1, P1, and X1 printers.

I am running under Docker on my NAS (Ugreen DXP4800 Plus).

Expected Behavior

When I send the file to the printer, whether from the file manager or the archives, the print starts automatically.

Steps to Reproduce

Keep the Bambuddy server open.
Start prints on the printer without turning it off between each one.
After a while, sending a file no longer starts the machine automatically.

Printer Model

Bambuddy Version

latest

Printer Firmware Version

01.07.01

Installation Method

Docker

Operating System

Docker

Relevant Logs / Support Package

bambuddy-support-20260417-134316.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 @Maxtrim3D on GitHub (Apr 17, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1006 Originally assigned to: @maziggy on GitHub. ### Bug Description Hello, When I want to start prints, the file is sent to the printers but the print does not start automatically. I have to start it manually. This happens when the printers have been turned on for some time, or when I have not restarted Buddy for a while. This is the case with A1, P1, and X1 printers. I am running under Docker on my NAS (Ugreen DXP4800 Plus). ### Expected Behavior When I send the file to the printer, whether from the file manager or the archives, the print starts automatically. ### Steps to Reproduce 1. Keep the Bambuddy server open. 2. Start prints on the printer without turning it off between each one. 3. After a while, sending a file no longer starts the machine automatically. ### Printer Model A1 ### Bambuddy Version latest ### Printer Firmware Version 01.07.01 ### Installation Method Docker ### Operating System Docker ### Relevant Logs / Support Package [bambuddy-support-20260417-134316.zip](https://github.com/user-attachments/files/26823476/bambuddy-support-20260417-134316.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:32:05 +02:00

closed this issue
added the
bug
label

BreizhHardware commented

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

Author

Owner

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

Please first update to latest firmare version. 01.07.01 had massive issues.

@maziggy commented on GitHub (Apr 17, 2026): Please first update to latest firmare version. 01.07.01 had massive issues.

BreizhHardware commented

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

Author

Owner

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

Hy,

I try but it doesn't change anything with the 01.08.

@Maxtrim3D commented on GitHub (Apr 18, 2026): Hy, I try but it doesn't change anything with the 01.08.

BreizhHardware commented

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

Author

Owner

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

Your support bundle confirms what's happening: after the MQTT channel sits idle a while, it goes into a "half-broken" state where the printer is still pushing telemetry but our project_file command isn't being picked up. v0.2.2.2 only logs a warning on that case — two follow-up fixes (#936 and #887) that actually reconnect the session and recover the dispatch were merged after 0.2.2.2 and are only in the daily beta right now.

Could you switch to the daily beta (-daily tag, or follow the daily-beta install path in the docs) and see if the issue still reproduces? If it does, please capture a fresh support bundle when it happens — I'd expect to see a Forcing MQTT reconnect line in the log if the self-heal path fired.

Please let me now how it goes.

@maziggy commented on GitHub (Apr 18, 2026): Your support bundle confirms what's happening: after the MQTT channel sits idle a while, it goes into a "half-broken" state where the printer is still pushing telemetry but our project_file command isn't being picked up. v0.2.2.2 only logs a warning on that case — two follow-up fixes (#936 and #887) that actually reconnect the session and recover the dispatch were merged after 0.2.2.2 and are only in the daily beta right now. Could you switch to the daily beta (-daily tag, or follow the daily-beta install path in the docs) and see if the issue still reproduces? If it does, please capture a fresh support bundle when it happens — I'd expect to see a Forcing MQTT reconnect line in the log if the self-heal path fired. Please let me now how it goes.

BreizhHardware commented

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

Author

Owner

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

Almost certainly hitting the task_id int32 overflow — project_file command gets accepted (result: success) but the printer treats every dispatch as a continuation of the prior task because your task_id is "0" (v0.2.2.2) or a 13-digit epoch-millisecond number that firmware clamps to 2147483647 (v0.2.3). See #1042 for the full root-cause analysis. Fix merged in d0f35e5d on the dev branch (caps task_id at 2**31 - 1).

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 20, 2026): Almost certainly hitting the task_id int32 overflow — project_file command gets accepted (result: success) but the printer treats every dispatch as a continuation of the prior task because your task_id is "0" (v0.2.2.2) or a 13-digit epoch-millisecond number that firmware clamps to 2147483647 (v0.2.3). See #1042 for the full root-cause analysis. Fix merged in d0f35e5d on the dev branch (caps task_id at 2**31 - 1). 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 commented

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

Author

Owner

@Maxtrim3D commented on GitHub (Apr 28, 2026):

Hello,

I try to update to daily fix but with my docker on the nass, I can't except if I have the image file.

@Maxtrim3D commented on GitHub (Apr 28, 2026): Hello, I try to update to daily fix but with my docker on the nass, I can't except if I have the image file.

BreizhHardware commented

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

Author

Owner

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

Sorry, don't understand. Please explain.

@maziggy commented on GitHub (Apr 28, 2026): Sorry, don't understand. Please explain.

BreizhHardware referenced this issue

2026-05-06 12:35:01 +02:00

[PR #705] [CLOSED] [Feature] - Printer optional depreciation cost #1096