starred/bambuddy

Fork 0

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

[GH-ISSUE #477] [Bug]: Repeat print started without user input #299

New issue

Closed

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

BreizhHardware commented

2026-05-06 12:28:03 +02:00

Owner

Originally created by @hollycroftlabs on GitHub (Feb 21, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/477

Originally assigned to: @maziggy on GitHub.

Bug Description

If i send a print from the file manager - sometimes I get a repeat print ie. it repeats the print i just did exactly.

This is hard to reproduce as it doesnt happen all the time. It seems to be related to something happening on the printer - power cycles (not in my case) or errors received. I can see that at the time of the print start, the printer reported an AMS error (0700-0002). this was at exactly at the same time the printer started printed again.

Expected Behavior

No unexpected prints

Steps to Reproduce

Print from file manager
Wait
wait some more - it can be really inconsistent. My last unexepcted print was over 12 hours since the completion of the expected print.

Printer Model

P1S

Bambuddy Version

0.2.0

Printer Firmware Version

01.09.01.00

Installation Method

Docker

Operating System

Linux (Ubuntu/Debian)

Relevant Logs / Support Package

Sorry, it wasnt running at the time, but due to the time difference it really hard to get logs of - the application logs didnt go back far enough as the print happened in the middle of the night and in the morning it was already to late to get logs.

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

Originally created by @hollycroftlabs on GitHub (Feb 21, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/477 Originally assigned to: @maziggy on GitHub. ### Bug Description If i send a print from the file manager - sometimes I get a repeat print ie. it repeats the print i just did exactly. This is hard to reproduce as it doesnt happen all the time. It seems to be related to something happening on the printer - power cycles (not in my case) or errors received. I can see that at the time of the print start, the printer reported an AMS error (0700-0002). this was at exactly at the same time the printer started printed again. ### Expected Behavior No unexpected prints ### Steps to Reproduce 1. Print from file manager 2. Wait 3. wait some more - it can be really inconsistent. My last unexepcted print was over 12 hours since the completion of the expected print. ### Printer Model P1S ### Bambuddy Version 0.2.0 ### Printer Firmware Version 01.09.01.00 ### Installation Method Docker ### Operating System Linux (Ubuntu/Debian) ### Relevant Logs / Support Package ```shell Sorry, it wasnt running at the time, but due to the time difference it really hard to get logs of - the application logs didnt go back far enough as the print happened in the middle of the night and in the morning it was already to late to get logs. ``` ### Screenshots _No response_ ### Additional Context _No response_ ### Checklist - [x] I have searched existing issues to ensure this bug hasn't already been reported - [ ] I am using the latest version of Bambuddy - [x] My printer is set to LAN Only mode

BreizhHardware

2026-05-06 12:28:03 +02:00

closed this issue
added the
bug
label

BreizhHardware commented

2026-05-06 12:28:04 +02:00

Author

Owner

@leoschwarz commented on GitHub (Feb 21, 2026):

I was starting to think it was only me, I experienced ~~the same~~ a very similar issue... (edit: i think the difference is that in my case there was "user input" but nothing visible in the UI) No prints were showing in the queue, after failing to queue a print several times. Then at a random time it starts printing. I cancel after a few layers and an hour or two later it caused a print failure by trying to print over the partially printed plate again.

While I wish great success to this project, for me this was a hard no and immediate uninstall.

@leoschwarz commented on GitHub (Feb 21, 2026): I was starting to think it was only me, I experienced ~the same~ a very similar issue... (edit: i think the difference is that in my case there was "user input" but nothing visible in the UI) No prints were showing in the queue, after failing to queue a print several times. Then at a random time it starts printing. I cancel after a few layers and an hour or two later it caused a print failure by trying to print over the partially printed plate again. While I wish great success to this project, for me this was a hard no and immediate uninstall.

BreizhHardware commented

2026-05-06 12:28:04 +02:00

Author

Owner

@maziggy commented on GitHub (Feb 21, 2026):

Fixed in branch 0.2.1b2. May I ask you to test again please and give feedback?

The root cause was three bugs in the SD card cleanup logic:

Retry loop never retried — The post-print cleanup always exited after attempt 1 regardless of whether the delete succeeded, because delete_file_async returns False on failure instead of raising an exception. The retry branch was dead code.
No cleanup on failed print start — If the file was uploaded but start_print() failed, the file stayed on the SD card forever since on_print_complete never fires for a print that never started.
Silent failures — Cleanup failures were logged at DEBUG level, invisible in normal operation.

The AMS error (0700-0002) you saw likely triggered a firmware restart, which then auto-started the stale gcode file left on the SD card root.

@maziggy commented on GitHub (Feb 21, 2026): Fixed in branch 0.2.1b2. May I ask you to test again please and give feedback? The root cause was three bugs in the SD card cleanup logic: 1. Retry loop never retried — The post-print cleanup always exited after attempt 1 regardless of whether the delete succeeded, because delete_file_async returns False on failure instead of raising an exception. The retry branch was dead code. 2. No cleanup on failed print start — If the file was uploaded but start_print() failed, the file stayed on the SD card forever since on_print_complete never fires for a print that never started. 3. Silent failures — Cleanup failures were logged at DEBUG level, invisible in normal operation. The AMS error (0700-0002) you saw likely triggered a firmware restart, which then auto-started the stale gcode file left on the SD card root.

BreizhHardware commented

2026-05-06 12:28:04 +02:00

Author

Owner

@hollycroftlabs commented on GitHub (Feb 23, 2026):

Runnning 0.2.1b2 i had no repeat prints yesterday! Great stuff!

@hollycroftlabs commented on GitHub (Feb 23, 2026): Runnning 0.2.1b2 i had no repeat prints yesterday! Great stuff!