[GH-ISSUE #374 ] [Bug]: Prints Starting without user input #235

Author

Owner

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

As already agreed on Discord, please ttry to reproduce the issue and send us a support package.

@maziggy commented on GitHub (Feb 14, 2026): As already agreed on Discord, please ttry to reproduce the issue and send us a support package.

BreizhHardware commented

bambuddy-support-20260214-211416.zip

Author

Owner

@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)

@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](https://github.com/user-attachments/files/25318550/bambuddy-support-20260214-211416.zip)

BreizhHardware commented

Author

Owner

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

The log only covers 20:58-21:14?!

@maziggy commented on GitHub (Feb 15, 2026): The log only covers 20:58-21:14?!

BreizhHardware commented

Author

Owner

@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?

@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?

BreizhHardware commented

Author

Owner

@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?

@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?

BreizhHardware commented

Author

Owner

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

Depends on the number of logs created ;)

@maziggy commented on GitHub (Feb 15, 2026): Depends on the number of logs created ;)

BreizhHardware commented

Author

Owner

@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:

The ghost print starts automatically every time I power cycle (Off/On) the printer, even if the previous job was already finished or canceled.
I tried clearing the /cache/ folder on the SD card, but it did not help. The printer still starts the job again on the next boot.
The only way I could stop the ghost print loop was to manually delete the source file (.3mf / .gcode) from the root of the SD card.

It seems the printer "clings" to the file in the root directory until it's physically removed. Hope this helps the investigation!

@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: - The ghost print starts automatically every time I power cycle (Off/On) the printer, even if the previous job was already finished or canceled. - I tried clearing the /cache/ folder on the SD card, but it did not help. The printer still starts the job again on the next boot. - The only way I could stop the ghost print loop was to manually delete the source file (.3mf / .gcode) from the root of the SD card. It seems the printer "clings" to the file in the root directory until it's physically removed. Hope this helps the investigation!

BreizhHardware commented

Author

Owner

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

This is very helpful! Thanks!!!

@maziggy commented on GitHub (Feb 15, 2026): This is very helpful! Thanks!!!

BreizhHardware commented

Author

Owner

@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): 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....

BreizhHardware commented

Author

Owner

@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?

@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?

BreizhHardware commented

Author

Owner

@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!

@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!

BreizhHardware commented

Author

Owner

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

Very good catch! Applied patch to branch 0.0.2b as you suggested. Thanks!

@maziggy commented on GitHub (Feb 17, 2026): Very good catch! Applied patch to branch 0.0.2b as you suggested. Thanks!

BreizhHardware commented

Author

Owner

@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.

@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.

BreizhHardware commented

Author

Owner

@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?

@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?

BreizhHardware commented

Author

Owner

@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.

@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.

BreizhHardware commented

Author

Owner

@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.

@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.

BreizhHardware commented

Author

Owner

@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

@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

BreizhHardware commented