[GH-ISSUE #737] [Bug]: Sending print files from file manager to printer does not reliable trigger the print to start for that file

Author

Owner

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

Need a support package -> https://wiki.bambuddy.cool/features/system-info/?h=debug#enable-debug-logging

@maziggy commented on GitHub (Mar 17, 2026): Need a support package -> https://wiki.bambuddy.cool/features/system-info/?h=debug#enable-debug-logging

BreizhHardware commented

Author

Owner

@piatho commented on GitHub (Mar 17, 2026):

Thanks for your swift reply. Attached the support package. One attempt was 5:20pm on two printers. It seems that the log unveils an issue on deleting a file

2026-03-17 17:20:40,217 WARNING [backend.app.services.bambu_ftp] Failed to delete /PRODUCT____20260310_PRODUCTXXL_1PC_v2.3mf: 550

@piatho commented on GitHub (Mar 17, 2026): Thanks for your swift reply. Attached the support package. One attempt was 5:20pm on two printers. It seems that the log unveils an issue on deleting a file `2026-03-17 17:20:40,217 WARNING [backend.app.services.bambu_ftp] Failed to delete /PRODUCT____20260310_PRODUCTXXL_1PC_v2.3mf: 550 `

BreizhHardware commented

Author

Owner

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

What the logs show:

MQTT connection to both printers is alive and healthy (status updates flow continuously)
FTP upload succeeds (file confirmed on SD card with 226 response)
Print command is sent via MQTT with QoS 1 (broker-acknowledged delivery)
Both printers silently ignore the command — no state change, no error response

So the file reaches the printer and the print command is delivered, but the printer just doesn't act on it.

Before we can investigate further, I need your help with a few things:

1. Developer Mode — your support package shows developer_mode: null for both printers. Developer Mode must be enabled on each printer (Settings → Network → Developer Mode). Without it, MQTT commands may be silently ignored by the firmware. This is the most likely cause.
2. Docker network mode — you're running in Docker bridge mode with a /16 subnet. Please switch to network_mode: host as per documentation. Bridge mode can cause subtle issues with MQTT keepalives and connection tracking, especially for long-lived connections.
3. Debug logs during the failure — the support package only has ~4 minutes of debug logging. Could you:
- Enable debug logging before triggering the issue
- Send a print to one printer
- Wait to confirm it doesn't start
- Then generate the support package immediately

This way we'll see the full MQTT exchange including any printer response to the print command.

The developer_mode: null is the strongest lead — please check that first and let me know.

@maziggy commented on GitHub (Mar 17, 2026): **What the logs show:** - MQTT connection to both printers is alive and healthy (status updates flow continuously) - FTP upload succeeds (file confirmed on SD card with 226 response) - Print command is sent via MQTT with QoS 1 (broker-acknowledged delivery) - Both printers silently ignore the command — no state change, no error response So the file reaches the printer and the print command is delivered, but the printer just doesn't act on it. Before we can investigate further, I need your help with a few things: **1. Developer Mode** — your support package shows developer_mode: null for both printers. Developer Mode must be enabled on each printer (Settings → Network → Developer Mode). Without it, MQTT commands may be silently ignored by the firmware. This is the most likely cause. **2. Docker network mode** — you're running in Docker bridge mode with a /16 subnet. Please switch to network_mode: host as per documentation. Bridge mode can cause subtle issues with MQTT keepalives and connection tracking, especially for long-lived connections. **3. Debug logs during the failure** — the support package only has ~4 minutes of debug logging. Could you: - Enable debug logging before triggering the issue - Send a print to one printer - Wait to confirm it doesn't start - Then generate the support package immediately This way we'll see the full MQTT exchange including any printer response to the print command. The developer_mode: null is the strongest lead — please check that first and let me know.

BreizhHardware commented

Author

Owner

@piatho commented on GitHub (Mar 17, 2026):

Thanks for the check.

Developer_mode is definitely turned on. Without it turned on, no communication works for me. No clue why it is read as "null".
Switching to network mode "host" brings some known and some unknown challenges to my setup. I am a hesitant to change this. I have acknowledge limitations here as per the documentation with regards to auto detections. Thats fine for me.

Your analysis an also the observation that depended on the printer status, it sometimes works and sometimes not, i suspect that that the printer somehow enter a sleep mode that they do not accept commands.

Currently i am printing based on SD card. Will run a longer log period when i start the next prints, but the log starts around 4:30 and the issue can be observed shortly after and again ~45mins after. What log duration do you need?

Can the issue be related to a failed attempt to overwrite a file of the same name on the SD card. I am actally start one and the same file a couple of times. Eventually Bambulab is locking a file after a print ended for some time which is why i cannot send the same file name again?

@piatho commented on GitHub (Mar 17, 2026): Thanks for the check. - **Developer_mode** is definitely turned on. Without it turned on, no communication works for me. No clue why it is read as "null". - Switching to network mode "host" brings some known and some unknown challenges to my setup. I am a hesitant to change this. I have acknowledge limitations here as per the documentation with regards to auto detections. Thats fine for me. Your analysis an also the observation that depended on the printer status, it sometimes works and sometimes not, i suspect that that the printer somehow enter a sleep mode that they do not accept commands. Currently i am printing based on SD card. Will run a longer log period when i start the next prints, but the log starts around 4:30 and the issue can be observed shortly after and again ~45mins after. What log duration do you need? Can the issue be related to a failed attempt to overwrite a file of the same name on the SD card. I am actally start one and the same file a couple of times. Eventually Bambulab is locking a file after a print ended for some time which is why i cannot send the same file name again?

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Mar 18, 2026):

Good news first: Your MQTT connection is healthy. Both printers are sending status updates every ~2 seconds continuously, so the connection is not stale or broken.

What the logs show:

The full sequence at 17:20 is:

FTP delete fails with 550 on both printers — this is harmless, the upload continues regardless
FTP upload succeeds on both printers (confirmed with 226 response)
Print command is sent via MQTT to both printers
Both printers silently ignore the command — no state change, no error, they just keep reporting FINISH

So file delivery and MQTT communication are working. The printer receives the command but chooses not to act on it.

The 550 delete error is not the cause — our code ignores a failed delete and proceeds with the upload. The file reaches the printer fine.

Something I noticed: Both print commands reference Metadata/plate_4.gcode inside the 3MF. This is auto-detected from the file. Most single-plate prints use plate 1. Could you please check:

How many plates does this 3MF have in your slicer? If it was sliced on plate 4 of a multi-plate project, the plate_4.gcode is correct. But if the file was re-exported and the internal plate numbering changed, the printer may silently reject the command because the referenced gcode path doesn't exist inside the file.
When it works (e.g. after "waking up" the printer), do you send the exact same file? Or a different one?
Could you try this test: When the issue occurs next, instead of disconnecting the AMS, try sending a different file (any small test print). If a different file works but the same file doesn't, the issue is file-specific. If no file works, the issue is printer-state-related.
Docker bridge and /16 subnet: Your Docker network uses a /16 subnet which is unusually large. What's your Docker network setup — is this a custom network? This shouldn't affect the current issue since MQTT is clearly working, but I want to rule it out.

@maziggy commented on GitHub (Mar 18, 2026): Good news first: Your MQTT connection is healthy. Both printers are sending status updates every ~2 seconds continuously, so the connection is not stale or broken. What the logs show: The full sequence at 17:20 is: 1. FTP delete fails with 550 on both printers — this is harmless, the upload continues regardless 2. FTP upload succeeds on both printers (confirmed with 226 response) 3. Print command is sent via MQTT to both printers 4. Both printers silently ignore the command — no state change, no error, they just keep reporting FINISH So file delivery and MQTT communication are working. The printer receives the command but chooses not to act on it. The 550 delete error is not the cause — our code ignores a failed delete and proceeds with the upload. The file reaches the printer fine. Something I noticed: Both print commands reference Metadata/plate_4.gcode inside the 3MF. This is auto-detected from the file. Most single-plate prints use plate 1. Could you please check: 1. How many plates does this 3MF have in your slicer? If it was sliced on plate 4 of a multi-plate project, the plate_4.gcode is correct. But if the file was re-exported and the internal plate numbering changed, the printer may silently reject the command because the referenced gcode path doesn't exist inside the file. 2. When it works (e.g. after "waking up" the printer), do you send the exact same file? Or a different one? 3. Could you try this test: When the issue occurs next, instead of disconnecting the AMS, try sending a different file (any small test print). If a different file works but the same file doesn't, the issue is file-specific. If no file works, the issue is printer-state-related. 4. Docker bridge and /16 subnet: Your Docker network uses a /16 subnet which is unusually large. What's your Docker network setup — is this a custom network? This shouldn't affect the current issue since MQTT is clearly working, but I want to rule it out.

BreizhHardware commented

Author

Owner

@piatho commented on GitHub (Mar 18, 2026):

Hi today i have tried to start print. I have started the printer and tried the following scenarios:

Print any file of my repository uploaded to file manager - none it working
Add any item to queue to be started asap. It stayed a while queued on the printer then it got reported "in printing" in the queue but it isn't actually printed
Print from archive - which works

Some observations:

In the "Schedule a print" popup on the /queue route, the printer is reported as "status = idle". At the same time, the same printer is reported in the /printer route as Status "Printing" with the subline "Ready to print"
I am not able to get the chamber light on (nothing happens), I am able to access the files of a printer as well as accessing the webcam (guess is is independent anyhow)
If i schedule a print (queue up) and restart the printer, the print starts after restart of the printer automatically

Docker setup is indeed wrong. I missed to specify the size of the network in my docker compose and that seems to create automatically such a big network: I will correct that anyhow later today.

Attached a new support package.

@piatho commented on GitHub (Mar 18, 2026): Hi today i have tried to start print. I have started the printer and tried the following scenarios: - Print any file of my repository uploaded to file manager - none it working - Add any item to queue to be started asap. It stayed a while queued on the printer then it got reported "in printing" in the queue but it isn't actually printed - Print from archive - which works Some observations: - In the "Schedule a print" popup on the /queue route, the printer is reported as "status = idle". At the same time, the same printer is reported in the /printer route as Status "Printing" with the subline "Ready to print" - I am not able to get the chamber light on (nothing happens), I am able to access the files of a printer as well as accessing the webcam (guess is is independent anyhow) - If i schedule a print (queue up) and restart the printer, the print starts after restart of the printer automatically Docker setup is indeed wrong. I missed to specify the size of the network in my docker compose and that seems to create automatically such a big network: I will correct that anyhow later today. Attached a new support package.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Mar 18, 2026):

Please answer my questions.

@maziggy commented on GitHub (Mar 18, 2026): Please answer my questions.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Mar 18, 2026):

I think you first need to change your network mode to host.

2026-03-18 12:14:25,143 WARNING [backend.app.services.bambu_ftp] FTP list_files timed out after 30.0s for /
2026-03-18 12:14:25,179 WARNING [backend.app.services.bambu_ftp] FTP connection timed out to [IP]: timed out
2026-03-18 12:14:49,940 WARNING [backend.app.services.bambu_mqtt] SERIAL Connection stale - no message for 66.2s
2026-03-18 12:15:09,185 WARNING [backend.app.services.bambu_ftp] FTP connection timed out to [IP]: timed out
2026-03-18 12:15:39,218 WARNING [backend.app.services.bambu_ftp] FTP connection timed out to [IP]: timed out
2026-03-18 12:15:39,219 WARNING [backend.app.services.bambu_ftp] FTP connection failed to [IP]
2026-03-18 12:16:11,259 WARNING [backend.app.services.bambu_ftp] FTP connection timed out to [IP]: timed out
2026-03-18 12:16:11,260 WARNING [backend.app.services.bambu_ftp] FTP connection failed to [IP]

@maziggy commented on GitHub (Mar 18, 2026): I think you first need to change your network mode to host. >2026-03-18 12:14:25,143 WARNING [backend.app.services.bambu_ftp] FTP list_files timed out after 30.0s for / >2026-03-18 12:14:25,179 WARNING [backend.app.services.bambu_ftp] FTP connection timed out to [IP]: timed out >2026-03-18 12:14:49,940 WARNING [backend.app.services.bambu_mqtt] [[SERIAL]] Connection stale - no message for 66.2s >2026-03-18 12:15:09,185 WARNING [backend.app.services.bambu_ftp] FTP connection timed out to [IP]: timed out >2026-03-18 12:15:39,218 WARNING [backend.app.services.bambu_ftp] FTP connection timed out to [IP]: timed out >2026-03-18 12:15:39,219 WARNING [backend.app.services.bambu_ftp] FTP connection failed to [IP] >2026-03-18 12:16:11,259 WARNING [backend.app.services.bambu_ftp] FTP connection timed out to [IP]: timed out >2026-03-18 12:16:11,260 WARNING [backend.app.services.bambu_ftp] FTP connection failed to [IP]

BreizhHardware commented

Author

Owner

@piatho commented on GitHub (Mar 18, 2026):

How many plates does this 3MF have in your slicer? If it was sliced on plate 4 of a multi-plate project, the plate_4.gcode is correct. But if the file was re-exported and the internal plate numbering changed, the printer may silently reject the command because the referenced gcode path doesn't exist inside the file.
I have currently not access to raw file but i have tested with various files. My files typically have n plates of which i export individual plates as gcode to be uploaded to Bambuddy. It is well possible that i had plate 4 here to be the one in use
When it works (e.g. after "waking up" the printer), do you send the exact same file? Or a different one?
I have not replied here earlier since i noticed that that "waking up" does not always works - it seems unrelated. But i tried usually 2-3 times with the same file before trying with some others too
Could you try this test: When the issue occurs next, instead of disconnecting the AMS, try sending a different file (any small test print). If a different file works but the same file doesn't, the issue is file-specific. If no file works, the issue is printer-state-related.
Its file-independant
Docker bridge and /16 subnet: Your Docker network uses a /16 subnet which is unusually large. What's your Docker network setup — is this a custom network? This shouldn't affect the current issue since MQTT is clearly working, but I want to rule it out.
I have changed the network now to /24. I cannot change to host mode since Bambuddy is part of a wider set of containers that run my enterprise. Bambuddy is sort of the PLC to the printers

2026-03-18 12:14:25,179 WARNING [backend.app.services.bambu_ftp] FTP connection timed out to [IP]: timed out
is caused because i restarted the printer.

@piatho commented on GitHub (Mar 18, 2026): 1. How many plates does this 3MF have in your slicer? If it was sliced on plate 4 of a multi-plate project, the plate_4.gcode is correct. But if the file was re-exported and the internal plate numbering changed, the printer may silently reject the command because the referenced gcode path doesn't exist inside the file. `I have currently not access to raw file but i have tested with various files. My files typically have n plates of which i export individual plates as gcode to be uploaded to Bambuddy. It is well possible that i had plate 4 here to be the one in use` 2. When it works (e.g. after "waking up" the printer), do you send the exact same file? Or a different one? `I have not replied here earlier since i noticed that that "waking up" does not always works - it seems unrelated. But i tried usually 2-3 times with the same file before trying with some others too` 3. Could you try this test: When the issue occurs next, instead of disconnecting the AMS, try sending a different file (any small test print). If a different file works but the same file doesn't, the issue is file-specific. If no file works, the issue is printer-state-related. `Its file-independant` 4. Docker bridge and /16 subnet: Your Docker network uses a /16 subnet which is unusually large. What's your Docker network setup — is this a custom network? This shouldn't affect the current issue since MQTT is clearly working, but I want to rule it out. `I have changed the network now to /24. I cannot change to host mode since Bambuddy is part of a wider set of containers that run my enterprise. Bambuddy is sort of the PLC to the printers` `2026-03-18 12:14:25,179 WARNING [backend.app.services.bambu_ftp] FTP connection timed out to [IP]: timed out` is caused because i restarted the printer.

BreizhHardware commented

Author

Owner

@Fangio92 commented on GitHub (Mar 18, 2026):

Hello. I have the same issue. I sliced 3-4 plates and uploaded them to Bambuddy and tried to print them after a print that was already running, and it behaves the same. I did not try restarting Bambuddy or anything else. Latest Bambuddy version, Docker with network mode: host. I don't have logs right now, but I will try to provide them later.

@Fangio92 commented on GitHub (Mar 18, 2026): Hello. I have the same issue. I sliced 3-4 plates and uploaded them to Bambuddy and tried to print them after a print that was already running, and it behaves the same. I did not try restarting Bambuddy or anything else. Latest Bambuddy version, Docker with network mode: host. I don't have logs right now, but I will try to provide them later.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Mar 19, 2026):

What's happening:

FTP upload succeeds (226 response confirmed)
Print command is sent via MQTT with QoS 1 (broker-acknowledged)
The printer continues sending status updates every ~2 seconds (connection is alive and healthy)
The printer silently ignores the command — no state change, no error response
When prints eventually start, they start after a FINISH → IDLE transition (likely from touchscreen interaction), not from a BambuBuddy command

BambuBuddy is doing its part correctly — the file is delivered and the command is sent in the right format. But something causes the printer to not act on it. I haven't been able to reproduce this on my H2D and X1C, so it may be model-specific, firmware-specific, or related to a specific printer state that I haven't hit yet.

About developer_mode: null: This is not related. Your P1S firmware version doesn't include the fun bitmask in push_status messages, so BambuBuddy can't detect the setting. It doesn't mean developer mode is off.

What I'm doing on the BambuBuddy side:
I've added print command verification — after sending a print command, BambuBuddy now monitors whether the printer actually responds within 15 seconds. If not, a diagnostic warning is logged. This will make it much easier to trace the issue in future support packages and help narrow down the root cause.

What would help me investigate further:

If you're able to reproduce it, try triggering a print from BambuBuddy and then immediately check if other MQTT commands work (e.g. chamber light toggle). If those also fail, the issue is broader than just the print command.

@Fangio92 — could you share your printer model and firmware version? That would help narrow down whether this is specific to certain hardware/firmware combinations.

@maziggy commented on GitHub (Mar 19, 2026): What's happening: - FTP upload succeeds (226 response confirmed) - Print command is sent via MQTT with QoS 1 (broker-acknowledged) - The printer continues sending status updates every ~2 seconds (connection is alive and healthy) - The printer silently ignores the command — no state change, no error response - When prints eventually start, they start after a FINISH → IDLE transition (likely from touchscreen interaction), not from a BambuBuddy command BambuBuddy is doing its part correctly — the file is delivered and the command is sent in the right format. But something causes the printer to not act on it. I haven't been able to reproduce this on my H2D and X1C, so it may be model-specific, firmware-specific, or related to a specific printer state that I haven't hit yet. About developer_mode: null: This is not related. Your P1S firmware version doesn't include the fun bitmask in push_status messages, so BambuBuddy can't detect the setting. It doesn't mean developer mode is off. What I'm doing on the BambuBuddy side: I've added print command verification — after sending a print command, BambuBuddy now monitors whether the printer actually responds within 15 seconds. If not, a diagnostic warning is logged. This will make it much easier to trace the issue in future support packages and help narrow down the root cause. What would help me investigate further: - If you're able to reproduce it, try triggering a print from BambuBuddy and then immediately check if other MQTT commands work (e.g. chamber light toggle). If those also fail, the issue is broader than just the print command. @Fangio92 — could you share your printer model and firmware version? That would help narrow down whether this is specific to certain hardware/firmware combinations.

BreizhHardware commented

Author

Owner

@piatho commented on GitHub (Mar 19, 2026):

Thanks for the input. during my tests yesterday and the day before, it noticed that in case a print was not started, also other actions that include a post call such as chamber light were kindly ignored. I will do further tests this evening to see if i can produce further evidence.

Version v0.2.2 seems to be still the most recent, correct?

@piatho commented on GitHub (Mar 19, 2026): Thanks for the input. during my tests yesterday and the day before, it noticed that in case a print was not started, also other actions that include a post call such as chamber light were kindly ignored. I will do further tests this evening to see if i can produce further evidence. Version v0.2.2 seems to be still the most recent, correct?

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Mar 19, 2026):

Wait a few hours and use the next daily release.

@maziggy commented on GitHub (Mar 19, 2026): Wait a few hours and use the next daily release.

BreizhHardware commented

Author

Owner

@piatho commented on GitHub (Mar 22, 2026):

Hi
Still on release 0.2.2, i tested today again. Attached a new support package. Here is what i did:

Started the printer
Waited untill all AMS units have been updated and printers shown in bambuddy
Added a print file to the queue to be start asap
--> The UI was showing me the print file as next in queue once printer is ready for a few minutes on the /printer router. Then it got removed and stayed in they queue.
Triggered chamber light - No reaction
Started the same file again on the same printer - this time direct.
--> Nothing happens at first - then the a message came up that the printer could not parse. It stats to clear the message on the printer.
SInce therer is nothing to clear on the printer i hit "reconnect on Bambuddy"; the error got cleared
Started the print again, still no reaction
Started the same file with BambuStudio.
--> Print started instantly.

@piatho commented on GitHub (Mar 22, 2026): Hi Still on release 0.2.2, i tested today again. Attached a new support package. Here is what i did: - Started the printer - Waited untill all AMS units have been updated and printers shown in bambuddy - Added a print file to the queue to be start asap --> The UI was showing me the print file as next in queue once printer is ready for a few minutes on the /printer router. Then it got removed and stayed in they queue. - Triggered chamber light - No reaction - Started the same file again on the same printer - this time direct. --> Nothing happens at first - then the a message came up that the printer could not parse. It stats to clear the message on the printer. SInce therer is nothing to clear on the printer i hit "reconnect on Bambuddy"; the error got cleared - Started the print again, still no reaction - Started the same file with BambuStudio. --> Print started instantly.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Mar 22, 2026):

First of all I would highly recommend to use Docker network mode host. In the past we experienced very weird issues when it was not set to mode host.

When looking at your logs, I have the impression, that you are trying to print a non Gcode file from Bambuddy.

BambuStudio - working: Zepplin_Hugo_220mm_20260310_ZepplinXXL_1PC_v2.gcode_plate_4.gcode.3mf

Bambuddy - not working: Zepplin_Hugo_220mm_20260310_ZepplinXXL_1PC.3mf

Usually when exporting a sliced model from BambuStudio it get's the file extension *.gcode.3mf, whereas unsiced files exported from BambuStudio have extension *.3mf.

@maziggy commented on GitHub (Mar 22, 2026): First of all I would highly recommend to use Docker network mode host. In the past we experienced very weird issues when it was not set to mode host. When looking at your logs, I have the impression, that you are trying to print a non Gcode file from Bambuddy. BambuStudio - working: Zepplin_Hugo_220mm_20260310_ZepplinXXL_1PC_v2.gcode_plate_4.gcode.3mf Bambuddy - not working: Zepplin_Hugo_220mm_20260310_ZepplinXXL_1PC.3mf Usually when exporting a sliced model from BambuStudio it get's the file extension *.gcode.3mf, whereas unsiced files exported from BambuStudio have extension *.3mf.

BreizhHardware commented

Author

Owner

@piatho commented on GitHub (Mar 22, 2026):

Hi @maziggy
Thanks for the prompt reply.

First of all, i noticed that i relyed to much on your statement that the support page clean of sensible content. It does for example contain URLs and it does contain file names. I have thus removed my zip updated and cleaned myself. May i ask you to remove the file names mentioned in your comment as well

I have uploaded to Bambuddy only sliced single plates which have the file ending *.gcode.3mf.
I suspect when i start the print from Bambustudio, it does upload *.3mf files or the printer may convertig it? Need to step into the details of the logs myself to understand what happs here

@piatho commented on GitHub (Mar 22, 2026): Hi @maziggy Thanks for the prompt reply. First of all, i noticed that i relyed to much on your statement that the support page clean of sensible content. It does for example contain URLs and it does contain file names. I have thus removed my zip updated and cleaned myself. May i ask you to remove the file names mentioned in your comment as well --- I have uploaded to Bambuddy only sliced single plates which have the file ending *.gcode.3mf. I suspect when i start the print from Bambustudio, it does upload *.3mf files or the printer may convertig it? Need to step into the details of the logs myself to understand what happs here

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Mar 22, 2026):

Regarding the content: I already stripped out all sensitive data. If I also do this for file names, then I would no longer be able to debug some of the most frequent bugs. Thus, the support-package function would be useless. And debugging without logs doesn't work.

@maziggy commented on GitHub (Mar 22, 2026): Regarding the content: I already stripped out all sensitive data. If I also do this for file names, then I would no longer be able to debug some of the most frequent bugs. Thus, the support-package function would be useless. And debugging without logs doesn't work.

BreizhHardware commented

Author

Owner

@piatho commented on GitHub (Mar 22, 2026):

I am sorry for bringing this chat in an off-topc dicussion her. Hope to have a qucika alignment here on a private message. pinged you on dicord :-)

In terms of the files, the messages are not making much sense to me, since my *.3mf. does have only 3 plates and the file name is a different one. The file in the log *v2.gcode_plate_4.gcode.3mf is a actually i file i uploaded to bambuddy but as *v2.gcode.3mf. If it refers to a "plate_4", this is likely a caching issue as a older version of the file might consted of 4 plates. I will try to clean the files completely, use a new naming pattern and see if that resolves the issue.

@piatho commented on GitHub (Mar 22, 2026): I am sorry for bringing this chat in an off-topc dicussion her. Hope to have a qucika alignment here on a private message. pinged you on dicord :-) In terms of the files, the messages are not making much sense to me, since my *.3mf. does have only 3 plates and the file name is a different one. The file in the log *v2.gcode_plate_4.gcode.3mf is a actually i file i uploaded to bambuddy but as *v2.gcode.3mf. If it refers to a "plate_4", this is likely a caching issue as a older version of the file might consted of 4 plates. I will try to clean the files completely, use a new naming pattern and see if that resolves the issue.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Mar 24, 2026):

All infos regarding the issue should go into the issue and not in private chats.

So what's the current status with latest version?

@maziggy commented on GitHub (Mar 24, 2026): All infos regarding the issue should go into the issue and not in private chats. So what's the current status with latest version?

BreizhHardware commented

Author

Owner

@Fangio92 commented on GitHub (Mar 28, 2026):

For me, v0.2.2.2 seems to have fixed the issue.

@Fangio92 commented on GitHub (Mar 28, 2026): For me, v0.2.2.2 seems to have fixed the issue.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Mar 30, 2026):

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

@maziggy commented on GitHub (Mar 30, 2026): ----- 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

Author

Owner

@piatho commented on GitHub (Mar 30, 2026):

Hi
i have still observed the issue in the latest firmware, but in my case it could also be that that the issue now it tied to a false message on my SD card been degraded. Every now an then i observe the message on the printer pager. Cleaning it, reconnect and restart printing works as far as i observed.

I will try to downgrade my firmware later this week to see if the "original" issue here is solved for me as well

@piatho commented on GitHub (Mar 30, 2026): Hi i have still observed the issue in the latest firmware, but in my case it could also be that that the issue now it tied to a false message on my SD card been degraded. Every now an then i observe the message on the printer pager. Cleaning it, reconnect and restart printing works as far as i observed. I will try to downgrade my firmware later this week to see if the "original" issue here is solved for me as well

BreizhHardware commented

Author

Owner

@Fangio92 commented on GitHub (Mar 30, 2026):

The printer failed to start when I tried a reprint. I restarted the containers and tried the same model again, and this time it worked. I also tried submitting the error log via the UI, but it keeps saying it failed. Any other way to get the logs?

@Fangio92 commented on GitHub (Mar 30, 2026): The printer failed to start when I tried a reprint. I restarted the containers and tried the same model again, and this time it worked. I also tried submitting the error log via the UI, but it keeps saying it failed. Any other way to get the logs?

BreizhHardware commented

https://wiki.bambuddy.cool/features/system-info/?h=debug#enable-debug-logging

Author

Owner

@maziggy commented on GitHub (Mar 30, 2026):

@maziggy commented on GitHub (Mar 30, 2026): https://wiki.bambuddy.cool/features/system-info/?h=debug#enable-debug-logging

BreizhHardware commented

bambuddy-support-20260330-141744.zip

Author

Owner

@Fangio92 commented on GitHub (Mar 30, 2026):

@Fangio92 commented on GitHub (Mar 30, 2026): [bambuddy-support-20260330-141744.zip](https://github.com/user-attachments/files/26349711/bambuddy-support-20260330-141744.zip)

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Mar 31, 2026):

Your printer if rejecting FTP connections.

2026-03-29 23:57:50,968 WARNING [backend.app.services.bambu_ftp] FTP connection failed to [IP]: [Errno 104] Connection reset by peer (type: ConnectionResetError)

Developer mode is enabled?

@maziggy commented on GitHub (Mar 31, 2026): Your printer if rejecting FTP connections. >2026-03-29 23:57:50,968 WARNING [backend.app.services.bambu_ftp] FTP connection failed to [IP]: [Errno 104] Connection reset by peer (type: ConnectionResetError) Developer mode is enabled?

BreizhHardware commented

Author

Owner

@Fangio92 commented on GitHub (Mar 31, 2026):

Developer mode is enabled.

@Fangio92 commented on GitHub (Mar 31, 2026): Developer mode is enabled.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Mar 31, 2026):

We need to find the reason, why your printer is refusing FTP connections. This is the key!

Firewall / iptables?

@maziggy commented on GitHub (Mar 31, 2026): We need to find the reason, why your printer is refusing FTP connections. This is the key! Firewall / iptables?

BreizhHardware commented

Author

Owner

@Fangio92 commented on GitHub (Mar 31, 2026):

Firewall no, iptables yes. What should I check in iptables?

@Fangio92 commented on GitHub (Mar 31, 2026): Firewall no, iptables yes. What should I check in iptables?

BreizhHardware commented

Author

Owner

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

Check the docker-compose.yml. All required ports are listed.

@maziggy commented on GitHub (Apr 1, 2026): Check the docker-compose.yml. All required ports are listed.

BreizhHardware commented

Author

Owner

@Fangio92 commented on GitHub (Apr 1, 2026):

Why then does reconnecting to MQTT help with my issue?

@Fangio92 commented on GitHub (Apr 1, 2026): Why then does reconnecting to MQTT help with my issue?

BreizhHardware commented

Author

Owner

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

I have no idea. Show me some more details about your system (network setup, OS logs, etc.).

@maziggy commented on GitHub (Apr 2, 2026): I have no idea. Show me some more details about your system (network setup, OS logs, etc.).

BreizhHardware commented

Author

Owner

@Fangio92 commented on GitHub (Apr 2, 2026):

Proxmox 9.16 -> Ubuntu 24.04.2 LTS Docker LXC. This is my docker compose: https://pastebin.com/nY8qh9Y3. One network 192.168.88.1/23, no VLANs, nothing special. P1S is connected via a TPLink router configured as an AP on a different wifi network than other devices. Connectivity is not an issue because the camera feed works great, and the signal strength is fine.

I am running backups of LXCs and VMs daily. Could that cause this issue? I again got the same problem with connecting to the printer when I wanted to resume print, after reconnecting to the MQTT, everything worked fine.

@Fangio92 commented on GitHub (Apr 2, 2026): Proxmox 9.16 -> Ubuntu 24.04.2 LTS Docker LXC. This is my docker compose: https://pastebin.com/nY8qh9Y3. One network 192.168.88.1/23, no VLANs, nothing special. P1S is connected via a TPLink router configured as an AP on a different wifi network than other devices. Connectivity is not an issue because the camera feed works great, and the signal strength is fine. I am running backups of LXCs and VMs daily. Could that cause this issue? I again got the same problem with connecting to the printer when I wanted to resume print, after reconnecting to the MQTT, everything worked fine.

BreizhHardware commented