starred/bambuddy-maziggy-1

Fork 0

mirror of https://github.com/maziggy/bambuddy.git synced 2026-05-09 08:25:54 +02:00

[GH-ISSUE #1136] [Bug]: Printing from archive makes references to wrong 3mf file in mqtt, causing MicroSD Read/Write exceptions #815

New issue

Closed

opened 2026-05-07 00:14:01 +02:00 by BreizhHardware · 4 comments

BreizhHardware commented

2026-05-07 00:14:01 +02:00

Owner

Originally created by @smandon on GitHub (Apr 26, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1136

Originally assigned to: @maziggy on GitHub.

Component

Bambuddy

Bug Description

I have an issue sometimes when trying to print from archives. After the file is sent to the printer the print never starts and I immediately get MicroSD Read/Write exception errors (0500-4003). The SD card isn't the issue as I tested with multiple cards and they all work perfectly fine when printing directly to the printer from bambu studio.
After looking at the debug logs, I can see references to a different 3mf file in mqtt's "gcode_state" lines, in particular the "gcode_file" just before the error occurs. The file referenced is part of a different unrelated archive.
When it starts happening the error always appears whatever I try to print. It works again normally if I restart the container.

Expected Behavior

The print should start normally when printing from archives.

Steps to Reproduce

slice and print to the virtual printer from bambu studio (review mode)
go to archives to review and archive the new added file
click the reprint button on the archive
select printer and set print options
go to printers and watch for errors

Printer Model

P1S

Bambuddy Version

0.2.3.2

SpoolBuddy Version

No response

Printer Firmware Version

No response

Installation Method

Docker

Operating System

Linux (Other)

Relevant Logs / Support Package

bambuddy-support-20260426-133312.zip

Screenshots

No response

Additional Context

The original filename used when I logged is Cable_Organiser_Cable_Clip.3mf, which is correctly used when sending via FTP and when sending the mqtt print command. I can also confirm the file is written on the SD card. But later in the logs mqtt communications make references to a different file named "WARIO_Wall_decor_-_NO_AMS.3mf" which is from a different archive.

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 @smandon on GitHub (Apr 26, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1136 Originally assigned to: @maziggy on GitHub. ### Component Bambuddy ### Bug Description I have an issue sometimes when trying to print from archives. After the file is sent to the printer the print never starts and I immediately get MicroSD Read/Write exception errors (0500-4003). The SD card isn't the issue as I tested with multiple cards and they all work perfectly fine when printing directly to the printer from bambu studio. After looking at the debug logs, I can see references to a different 3mf file in mqtt's "gcode_state" lines, in particular the "gcode_file" just before the error occurs. The file referenced is part of a different unrelated archive. When it starts happening the error always appears whatever I try to print. It works again normally if I restart the container. ### Expected Behavior The print should start normally when printing from archives. ### Steps to Reproduce 1. slice and print to the virtual printer from bambu studio (review mode) 2. go to archives to review and archive the new added file 3. click the reprint button on the archive 4. select printer and set print options 5. go to printers and watch for errors ### Printer Model P1S ### Bambuddy Version 0.2.3.2 ### SpoolBuddy Version _No response_ ### Printer Firmware Version _No response_ ### Installation Method Docker ### Operating System Linux (Other) ### Relevant Logs / Support Package [bambuddy-support-20260426-133312.zip](https://github.com/user-attachments/files/27099289/bambuddy-support-20260426-133312.zip) ### Screenshots _No response_ ### Additional Context The original filename used when I logged is Cable_Organiser_Cable_Clip.3mf, which is correctly used when sending via FTP and when sending the mqtt print command. I can also confirm the file is written on the SD card. But later in the logs mqtt communications make references to a different file named "WARIO_Wall_decor_-_NO_AMS.3mf" which is from a different archive. ### 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-07 00:14:01 +02:00

closed this issue
added the
bug
label

BreizhHardware commented

2026-05-07 00:14:02 +02:00

Author

Owner

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

Firmware version?

@maziggy commented on GitHub (Apr 26, 2026): Firmware version?

BreizhHardware commented

2026-05-07 00:14:02 +02:00

Author

Owner

@smandon commented on GitHub (Apr 26, 2026):

It the latest for the P1S: 01.10.00.00

@smandon commented on GitHub (Apr 26, 2026): It the latest for the P1S: 01.10.00.00

BreizhHardware commented

2026-05-07 00:14:02 +02:00

Author

Owner

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

"network_mode_hint": "bridge"

FIrst of all I would strongly suggest to switch to Docker network mode host - as per the docs.

Confirmed root cause from your support package — paho-mqtt's client-side QoS 1 queue. When the printer's command channel goes half-broken, Bambuddy's 15s dispatch deadline expires and it force-closes the socket to trigger paho's auto-reconnect. But same client instance, same client_id, same QoS 1 queue — so the project_file for your new archive plus any stale project_file/resume/stop from previous stuck dispatches all replay together on the next connection. Printer latches onto whichever stale path it processes last, can't find the file on its SD card, and emits 0500_4003. Container restart is the only thing that wipes paho's in-process queue, which is why that's been the only fix.

Fix is to do a full paho client teardown on stale reconnect (DISCONNECT + loop_stop + fresh mqtt.Client with new client_id) instead of just closing the socket.

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 26, 2026): > "network_mode_hint": "bridge" FIrst of all I would strongly suggest to switch to Docker network mode host - as per the docs. --- Confirmed root cause from your support package — paho-mqtt's client-side QoS 1 queue. When the printer's command channel goes half-broken, Bambuddy's 15s dispatch deadline expires and it force-closes the socket to trigger paho's auto-reconnect. But same client instance, same client_id, same QoS 1 queue — so the project_file for your new archive plus any stale project_file/resume/stop from previous stuck dispatches all replay together on the next connection. Printer latches onto whichever stale path it processes last, can't find the file on its SD card, and emits 0500_4003. Container restart is the only thing that wipes paho's in-process queue, which is why that's been the only fix. Fix is to do a full paho client teardown on stale reconnect (DISCONNECT + loop_stop + fresh mqtt.Client with new client_id) instead of just closing the socket. 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-07 00:14:02 +02:00

Author

Owner

@smandon commented on GitHub (Apr 26, 2026):

"network_mode_hint": "bridge"
FIrst of all I would strongly suggest to switch to Docker network mode host - as per the docs.

I can't use the host mode because of port already used, instead I'm using a macvlan network.

Confirmed root cause from your support package — paho-mqtt's client-side QoS 1 queue. When the printer's command channel goes half-broken, Bambuddy's 15s dispatch deadline expires and it force-closes the socket to trigger paho's auto-reconnect. But same client instance, same client_id, same QoS 1 queue — so the project_file for your new archive plus any stale project_file/resume/stop from previous stuck dispatches all replay together on the next connection. Printer latches onto whichever stale path it processes last, can't find the file on its SD card, and emits 0500_4003. Container restart is the only thing that wipes paho's in-process queue, which is why that's been the only fix.

Fix is to do a full paho client teardown on stale reconnect (DISCONNECT + loop_stop + fresh mqtt.Client with new client_id) instead of just closing the socket.

Available/Fixed in branch dev and available with the next release or daily build. Please let me know if it works for you now.

Thanks, I'll try a daily build.

If you find Bambuddy useful, please consider giving it a ⭐ on GitHub — it helps others discover the project!

@smandon commented on GitHub (Apr 26, 2026): > > ``` > > "network_mode_hint": "bridge" > > ``` > > FIrst of all I would strongly suggest to switch to Docker network mode host - as per the docs. > I can't use the host mode because of port already used, instead I'm using a macvlan network. > Confirmed root cause from your support package — paho-mqtt's client-side QoS 1 queue. When the printer's command channel goes half-broken, Bambuddy's 15s dispatch deadline expires and it force-closes the socket to trigger paho's auto-reconnect. But same client instance, same client_id, same QoS 1 queue — so the project_file for your new archive plus any stale project_file/resume/stop from previous stuck dispatches all replay together on the next connection. Printer latches onto whichever stale path it processes last, can't find the file on its SD card, and emits 0500_4003. Container restart is the only thing that wipes paho's in-process queue, which is why that's been the only fix. > > Fix is to do a full paho client teardown on stale reconnect (DISCONNECT + loop_stop + fresh mqtt.Client with new client_id) instead of just closing the socket. > > Available/Fixed in branch dev and available with the next release or daily build. Please let me know if it works for you now. > Thanks, I'll try a daily build. > If you find Bambuddy useful, please consider giving it a ⭐ on [GitHub](https://github.com/maziggy/bambuddy) — it helps others discover the project!

BreizhHardware referenced this issue

2026-05-07 00:16:08 +02:00

[PR #816] [CLOSED] Reapply extend currencies with Ukrainian Hryvnia #1124

BreizhHardware referenced this issue

2026-05-07 00:16:10 +02:00

[PR #830] [MERGED] v0.2.2.2 #1129