Product
Bambuddy
Area
Archives / library / files
Bug Description
Bambuddy detected the start of Desktop_Goose.gcode.3mf at 22:49:45 and immediately attempted to locate the source file. The printer’s file service was not answering over TLS, so Bambuddy gave up and created fallback archive 83.
The failure was temporary. Approximately four minutes later, Bambuddy’s cover-retrieval path connected successfully over FTPS and downloaded the complete 8,956,942-byte Desktop_Goose.gcode.3mf into /app/data/archive/temp. It successfully read the file, detected plate 2, and extracted the correct thumbnail for display on the active printer card.
Despite now possessing and successfully parsing the complete source file, Bambuddy did not associate it with fallback archive 83 or run the normal archive processing. The archive remained an empty shell with no thumbnail, file size, filament usage, layer information, or other slicer metadata. No warning was displayed on the Archives page.
The printer-side TLS failure explains why the file was unavailable during the initial archive attempt. It does not explain why the archive remained incomplete after Bambuddy subsequently downloaded and parsed the exact file it needed.
Expected Behavior
A temporary FTPS/TLS failure during print startup should not permanently prevent the print from being archived.
When the printer’s file service becomes available again, Bambuddy should retry retrieval for the existing fallback archive. If another process, such as cover retrieval, successfully downloads the complete .gcode.3mf, Bambuddy should reuse that file, associate it with the fallback archive, and run the standard archive-processing workflow.
Steps to Reproduce
- Send a sliced .gcode.3mf from Bambu Studio to a P1S and start the print.
- During print startup, have the printer’s FTPS/TLS file service fail temporarily.
- Bambuddy detects the print start but cannot retrieve the source file and creates a fallback archive.
- Allow the printer’s file service to recover.
- Bambuddy’s cover-retrieval path reconnects and downloads the complete .gcode.3mf.
- Bambuddy successfully reads the file and extracts the correct plate thumbnail.
- Open the archive created at print start.
- The archive remains an empty shell rather than being recovered from the downloaded file.
Troubleshooting steps already taken
- Replaced the printer’s SD card.
- Power-cycled the printer.
- Reproduced the problem repeatedly with a 22.7 MB print.
- Reduced the job to one object and an 8.5 MB file.
- Enabled bed leveling to give the printer and Bambuddy additional startup time.
- Monitored the printer with continuous ping.
- Watched Bambu Studio and Bambuddy simultaneously.
- Confirmed that the clean 8.5 MB reproduction had no connection dropout.
- Confirmed that a small 43.8 KB cube archived immediately and completely.
- Reviewed the Docker logs.
- Checked troubleshooting guide - Printer is in the same room as the router and most prints work fine - nothing is blocking the port
The different file sizes initially made this look like a size-related problem. The logs instead show that Bambuddy gave up during a brief FTPS/TLS availability window, then successfully downloaded the complete file several minutes later without recovering the archive.
Printer Model
None
Bambuddy Version
1
SpoolBuddy Version
1.2.5.3
Printer Firmware Version
1.07.00.00
Installation Method
Docker
Operating System
Docker
Support Package (.zip) and / or relevant logs
Docker logs:
2026-08-25T02:49:45.729399358Z 2026-08-24 22:49:45,729 INFO [backend.app.services.bambu_mqtt] [-] [01P00A3B1200579] PRINT START detected - file: Desktop_Goose.gcode.3mf,
subtask: Desktop_Goose, is_new: True, is_file_change: False
2026-08-25T02:49:45.731703227Z 2026-08-24 22:49:45,731 INFO [backend.app.services.usage_tracker] [-] [UsageTracker] PRINT START printer 1: mapping=None, tray_now=2,
last_loaded_tray=2
2026-08-25T02:49:45.731795993Z 2026-08-24 22:49:45,731 INFO [backend.app.services.usage_tracker] [-] [UsageTracker] PRINT START printer 1 AMS 0: T0(type=PLA,
color=E5E1E6FF, now=?, tar=?), T1(type=PLA, color=00AE42FF, now=?, tar=?), T2(type=PLA, color=FF6A13FF, now=?, tar=?), T3(type=PLA, color=25282AFF, now=?, tar=?)
2026-08-25T02:49:45.739221396Z 2026-08-24 22:49:45,739 INFO [backend.app.main] [-] [CALLBACK] Print start detected - filename: Desktop_Goose.gcode.3mf, subtask:
Desktop_Goose
2026-08-25T02:49:45.740241874Z 2026-08-24 22:49:45,740 INFO [backend.app.main] [-] Trying filenames: ['Desktop_Goose.gcode.3mf', 'Desktop_Goose.3mf']
2026-08-25T02:49:45.742493595Z 2026-08-24 22:49:45,742 WARNING [backend.app.main] [-] Giving up on the 3MF for printer 1: its file service is not answering over TLS
2026-08-25T02:49:45.742582406Z 2026-08-24 22:49:45,742 WARNING [backend.app.main] [-] Could not find 3MF file for print: Desktop_Goose.gcode.3mf
2026-08-25T02:49:45.745593881Z 2026-08-24 22:49:45,745 INFO [backend.app.main] [-] Created fallback archive 83 for Desktop_Goose (no 3MF available)
2026-08-25T02:50:04.229465645Z 2026-08-24 22:50:04,229 INFO [backend.app.api.routes.printers] [f1462685] Trying to download cover for 'Desktop_Goose' from 172.25.12.149
(trying 8 paths)
2026-08-25T02:53:42.243632443Z 2026-08-24 22:53:42,243 INFO [backend.app.api.routes.printers] [8c66c061] Trying to download cover for 'Desktop_Goose' from 172.25.12.149
(trying 8 paths)
2026-08-25T02:53:43.055146067Z 2026-08-24 22:53:43,054 INFO [backend.app.services.bambu_ftp] [-] FTP connected successfully to 172.25.12.149 (model=P1S, prot_c=False)
2026-08-25T02:54:39.714076491Z 2026-08-24 22:54:39,713 INFO [backend.app.services.bambu_ftp] [-] Successfully downloaded /Desktop_Goose.gcode.3mf to
/app/data/archive/temp/cover_1_Desktop_Goose.gcode.3mf (8956942 bytes)
2026-08-25T02:54:39.719340546Z 2026-08-24 22:54:39,719 INFO [backend.app.api.routes.printers] [8c66c061] Cover: detected plate 2 from 3MF contents
Screenshots
No response
Additional Context
The Connection Diagnostic identified this as the known “Secure file-transfer handshake failed” condition. Bambuddy’s documentation explains that it pauses file transfers to the affected printer for five minutes following a failed handshake:
https://wiki.bambuddy.cool/reference/troubleshooting/#secure-file-transfer-handshake-failed
The printer had already been power-cycled before this reproduction, but the TLS/file-service problem recurred. The print itself continued normally, and the final reproduction did not experience a Bambu Studio, Bambuddy, or printer-control connection dropout.
A small 43.8 KB test print archived immediately and completely. The failure was reproduced with both a 22.7 MB job and the 8,956,942-byte job documented here. The later successful download proves that the file existed on the printer and was accessible to Bambuddy after the temporary TLS failure cleared.
A bounded retry should be scheduled after a transient TLS failure or any active FTP cooldown. More importantly, when a later process successfully downloads the complete .gcode.3mf, Bambuddy should associate it with the existing fallback archive and run the normal metadata, thumbnail, and filament-usage processing. The complete file should not remain stranded in archive/temp after it has already been downloaded and parsed.
This is similar to #2856 but mine is the unhandled P1S/transient-TLS version of the same broader recovery problem.
Final checks
Product
Bambuddy
Area
Archives / library / files
Bug Description
Bambuddy detected the start of Desktop_Goose.gcode.3mf at 22:49:45 and immediately attempted to locate the source file. The printer’s file service was not answering over TLS, so Bambuddy gave up and created fallback archive 83.
The failure was temporary. Approximately four minutes later, Bambuddy’s cover-retrieval path connected successfully over FTPS and downloaded the complete 8,956,942-byte Desktop_Goose.gcode.3mf into /app/data/archive/temp. It successfully read the file, detected plate 2, and extracted the correct thumbnail for display on the active printer card.
Despite now possessing and successfully parsing the complete source file, Bambuddy did not associate it with fallback archive 83 or run the normal archive processing. The archive remained an empty shell with no thumbnail, file size, filament usage, layer information, or other slicer metadata. No warning was displayed on the Archives page.
The printer-side TLS failure explains why the file was unavailable during the initial archive attempt. It does not explain why the archive remained incomplete after Bambuddy subsequently downloaded and parsed the exact file it needed.
Expected Behavior
A temporary FTPS/TLS failure during print startup should not permanently prevent the print from being archived.
When the printer’s file service becomes available again, Bambuddy should retry retrieval for the existing fallback archive. If another process, such as cover retrieval, successfully downloads the complete .gcode.3mf, Bambuddy should reuse that file, associate it with the fallback archive, and run the standard archive-processing workflow.
Steps to Reproduce
Troubleshooting steps already taken
The different file sizes initially made this look like a size-related problem. The logs instead show that Bambuddy gave up during a brief FTPS/TLS availability window, then successfully downloaded the complete file several minutes later without recovering the archive.
Printer Model
None
Bambuddy Version
1
SpoolBuddy Version
1.2.5.3
Printer Firmware Version
1.07.00.00
Installation Method
Docker
Operating System
Docker
Support Package (.zip) and / or relevant logs
Screenshots
No response
Additional Context
The Connection Diagnostic identified this as the known “Secure file-transfer handshake failed” condition. Bambuddy’s documentation explains that it pauses file transfers to the affected printer for five minutes following a failed handshake:
https://wiki.bambuddy.cool/reference/troubleshooting/#secure-file-transfer-handshake-failed
The printer had already been power-cycled before this reproduction, but the TLS/file-service problem recurred. The print itself continued normally, and the final reproduction did not experience a Bambu Studio, Bambuddy, or printer-control connection dropout.
A small 43.8 KB test print archived immediately and completely. The failure was reproduced with both a 22.7 MB job and the 8,956,942-byte job documented here. The later successful download proves that the file existed on the printer and was accessible to Bambuddy after the temporary TLS failure cleared.
A bounded retry should be scheduled after a transient TLS failure or any active FTP cooldown. More importantly, when a later process successfully downloads the complete .gcode.3mf, Bambuddy should associate it with the existing fallback archive and run the normal metadata, thumbnail, and filament-usage processing. The complete file should not remain stranded in archive/temp after it has already been downloaded and parsed.
This is similar to #2856 but mine is the unhandled P1S/transient-TLS version of the same broader recovery problem.
Final checks