mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-05-09 05:35:30 +02:00
[GH-ISSUE #374] [Bug]: Prints Starting without user input #236
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
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#236
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 @hollycroftlabs on GitHub (Feb 14, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/374
Originally assigned to: @maziggy on GitHub.
Bug Description
I have a small test setup - 1 printer - 1 file. I submitted a print from the file menu yesterday that finished successfully. The archive reflects this successful print.
Since then that file has been sent to the printer twice without any input from me and the queue in the front end is empty.
Expected Behavior
No repeat prints without user input
Steps to Reproduce
N/A
Printer Model
P1S
Bambuddy Version
0.1.9
Printer Firmware Version
01.09.01.00
Installation Method
Docker
Operating System
Linux (Ubuntu/Debian)
Relevant Logs / Support Package
Screenshots
No response
Additional Context
No response
Checklist
@maziggy commented on GitHub (Feb 14, 2026):
As already agreed on Discord, please ttry to reproduce the issue and send us a support package.
@hollycroftlabs commented on GitHub (Feb 14, 2026):
Ok, i printed something this afternoon, i started debug mode and then it started a print on its own at 17:48. I have the logs (attached)
bambuddy-support-20260214-211416.zip
@maziggy commented on GitHub (Feb 15, 2026):
The log only covers 20:58-21:14?!
@maziggy commented on GitHub (Feb 15, 2026):
The log rotated. Can you please check if the rotated logfiles still have the time range around 17:48?
@hollycroftlabs commented on GitHub (Feb 15, 2026):
Doesn't appear so, it was 4/5 hours between the successful completion of the last print before it start printing again. Im printing again today so will try and catch it.
How often does the log rotate?
@maziggy commented on GitHub (Feb 15, 2026):
Depends on the number of logs created ;)
@DIYofThings commented on GitHub (Feb 15, 2026):
I am also hitting this issue on my P1S (China version, LAN mode, Bambuddy 0.1.9).
I found a very specific behavior regarding how to stop it:
It seems the printer "clings" to the file in the root directory until it's physically removed. Hope this helps the investigation!
@maziggy commented on GitHub (Feb 15, 2026):
This is very helpful! Thanks!!!
@maziggy commented on GitHub (Feb 16, 2026):
Seems only to happen with some printer models. JUst tested with H2D and X1C and coudn't reproduce. Anyway....we need to delete the file from printer after print has finished.
Let me see....
@maziggy commented on GitHub (Feb 16, 2026):
@DIYofThings can you please check again with branch 0.2.0b and let me know how it goes?
@DIYofThings commented on GitHub (Feb 16, 2026):
Hi @maziggy,
Thanks for the v0.2.0b update! I’ve been testing the new ghost print cleanup logic and found a small bug that affects users who have auto_archive disabled.
The Issue: In main.py, the on_print_complete function returns early if no archive record is found. Since the cleanup logic is currently placed after this check, it never executes for users who have archiving turned off.
Suggested Fix: Moving the cleanup block to the very beginning of on_print_complete (before the early return) ensures it runs regardless of the archiving setting.
I also found that adding a small retry loop (3 attempts with a 2s delay) and checking for both .3mf and .gcode extensions improves reliability significantly, as the printer sometimes still "locks" the file system for a few seconds after the job ends.
I've verified this "robust" approach locally on my P1S and it successfully eliminates the ghost prints even with archiving disabled.
Thanks again for the great work!
@maziggy commented on GitHub (Feb 17, 2026):
Very good catch! Applied patch to branch 0.0.2b as you suggested. Thanks!
@kainpl commented on GitHub (Mar 30, 2026):
I found an alternative solution for the ghost print issue. Instead of deleting the 3MF file from the SD card root after a print, move it to /cache/ using FTP RENAME. The printer's firmware doesn't scan /cache/ for auto-start on boot, but the file remains accessible in the printer's "History" screen.
Through testing I also discovered that the ghost print problem isn't purely about the file being present on SD - there's a firmware state component. Even if you delete the file immediately after print completion, a manual reboot will still trigger a ghost print attempt (the printer tries to start the now-missing file and fails). This appears to be tied to the printer's internal MQTT state which persists until all post-print tasks complete (likely nozzle cooldown).
Once enough time passes after completion, the state clears and reboot no longer triggers a ghost print.
So the reliable approach is: after print completion, move the 3MF from / to /cache/ via FTP RENAME. This way even an immediate reboot won't cause a ghost print - the firmware's internal state may still reference the file, but since the root directory is empty, there's nothing to auto-start. And the file safely sits in /cache/ accessible from History if needed.
@maziggy commented on GitHub (Mar 31, 2026):
From the firmware perspective, what's the difference between deleteing the file, or moving it to another location? If the firmware still references the file and tries to print it after power cycle, I think it doesn't matter if you deleted it, or moved it away.
Or did i miss something?
@kainpl commented on GitHub (Mar 31, 2026):
As I mentioned above - even if the file is deleted immediately after print completion, a manual reboot will still trigger a ghost print attempt (the printer tries to start the now-missing file and fails). This appears to be tied to the printer's internal MQTT state, which persists until all post-print tasks complete (likely nozzle cooldown). So from that perspective alone - yes, you're right, deleting vs. moving makes no difference.
However, you're overlooking the farm use case. Sometimes we need to restart a print directly from the printer itself, rather than having to pick up the finished print, walk to the office/another room, and re-launch the job from there. So while the logic is sound, it creates a practical inconvenience for farm operators.
@maziggy commented on GitHub (Apr 1, 2026):
The /cache/ move is a clever workaround, but not all printer models have a /cache/ folder, and reworking the file cleanup logic to handle model-specific directory support adds complexity we'd rather avoid. The ghost print issue itself is resolved, so I'll keep this closed. If there's demand for a "keep file on printer for reprints" feature down the line, we can revisit it as a separate request.
@froust-company commented on GitHub (May 2, 2026):
i have this isse even though i deleted all of the cache folder, every time i start the printer it still tries to start this print but because file is not there it gives me SD card data damaged error. it's A1 and last bambuddy version
@maziggy commented on GitHub (May 2, 2026):
Please open a new issue and attach a support package.