mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-05-09 05:35:30 +02:00
[GH-ISSUE #1190] [Bug Report] After i put one time file in queue, it starts this print every time when i turn #860
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#860
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 @maziggy on GitHub (May 2, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1190
Originally assigned to: @maziggy on GitHub.
After i put one time file in queue, it starts this print every time when i turn on the printer, i already deleted it from que, deleted files from backup folder on the printer, but it's still trying to start the print every time i turn on printer.
Reporter Contact
Email:
System Information
Logs (sanitized): bambuddy.log
Submitted via BamBuddy Bug Report
@froust-company commented on GitHub (May 2, 2026):
I don't know how how to generate support files from the bambuddy, can't find system information section but i will add some info to the comments.
Steps to Reproduce:
So nothing superordinary i just uploaded sliced 3mf file to the bambuddy and put it to schedule to start print after previous print will be finished, but i think this is where issue started, i checked this checkbox "Only start if previous print succeeded" but after previous print ended queued print didn't start, so i deleted this schedule and added print to the schedule again with unchecked checkbox and only after that it send it to print. And after this print ended it now tries to start this print every time i turn it on.
Printer: A1
Bambuddy Version: v0.2.3.2
Printer Firmware Version: 01.07.02.00
Installation Method: Docker
OS: Windows
You can see in log where it sends file to print:
2026-05-02 11:17:06,848 DEBUG [backend.app.services.bambu_mqtt] [[SERIAL]] gcode_state: IDLE -> IDLE, file: @SolomonHaki_A1v2.3mf, subtask: _SolomonHaki_A1v2@froust-company commented on GitHub (May 2, 2026):
@maziggy I'm sorry, but could you please hide or remove my email, i didn't know this will be public
@maziggy commented on GitHub (May 2, 2026):
The bubble text exactly describes what's happening.
@maziggy commented on GitHub (May 2, 2026):
Please upload a support package -> https://wiki.bambuddy.cool/features/system-info/?h=debug#enable-debug-logging
You find the system page at the bottom of the sidebar.
@froust-company commented on GitHub (May 2, 2026):
bambuddy-support-20260502-115418.zip
The gcode is "@SolomonHaki....3mf"
Thanks for patience and fast response man
@maziggy commented on GitHub (May 2, 2026):
First of all I would strongly suggest to use Netwrk mode host - as per the docs!
@maziggy commented on GitHub (May 2, 2026):
@maziggy commented on GitHub (May 2, 2026):
I added a troubleshooting note for this exact pattern so other users hit it too: Printer Looks Like It's Trying to Re-Start the Last Print After Power-On.
Short version of why this isn't Bambuddy: your Bambu firmware keeps the last gcode_file / subtask_name in its MQTT status payload forever after a print finishes — those fields are still there on every power-on, even when idle. The touchscreen displays them too. Bambuddy only acts on a real state transition (IDLE → PREPARE/RUNNING), and your log doesn't show one for SolomonHaki after you deleted the queue item on 2026-04-28.
The thing your log does show on every power-on is 0500_C010 — the Bambu HMS code for MicroSD card read/write exception. That's almost certainly what's keeping the touchscreen in a "last print is staged" state.
Try this in order — most cases get fixed at step 1 or 2: