mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-05-09 08:25:54 +02:00
[GH-ISSUE #1014] [Bug]: Skip object not working on currently running prints #710
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
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-maziggy-1#710
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 @heffe2001 on GitHub (Apr 17, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1014
Originally assigned to: @maziggy on GitHub.
Bug Description
I have a machine that I needed to skip object on, but the skip options says it needs more than one object (the plate has at least 35 separate objects on it). This was working before the SD card read/write issues, but after loading the latest dev build, it's not working on any running print. Bambuddy is also not showing tumbnails on any files at this point also.
Expected Behavior
I should be able to click skip objects and get the popup showing the plate and objects that I can select to skip.
Steps to Reproduce
Not working on any of my printers at the moment, any print I send has the same issue currently.
Printer Model
A1
Bambuddy Version
v0.2.3b4
Printer Firmware Version
01.07.02.00
Installation Method
Docker
Operating System
Linux (Ubuntu/Debian)
Relevant Logs / Support Package
bambuddy-support-20260417-171227.zip
Screenshots
Additional Context
No response
Checklist
@maziggy commented on GitHub (Apr 18, 2026):
Show me your print file please. Did you grouped the objects in slicer? If so, the firmware treats it as a single object.
@heffe2001 commented on GitHub (Apr 18, 2026):
I went to archive to download the file, and it's telling me "No 3MF file available - the file could not be downloaded from the printer when the print was recorded", which I'm sure is why it can't skip objects. The file was sent through Bambu Studio, and each major part was seperate (it was 2 Raki-box flexi leachie gecko's, so 2 body, 2 tails, 2 top and 2 bottom heads). It looks like the only files that have been able to be downloaded from the printers have been very small files, nothing that has any sort of size are showing up in archive aside from showing that they printed. No images on any of those larger files either. This is on both A1's and P1S printers.
If I send a file to a virtual printer (A1 in this case) and THEN send the print from there, it appears to work correctly, but it looks like if I send it directly to the printer, Bambuddy is having issues copying the file from the printer so it can monitor it. Which way should I be sending files, directly to the printers, or to archive, THAN to whatever printer I want to send it to?
Also, thumbnails do show up correctly on the printer with the sent files, but not on Bambuddy.
@heffe2001 commented on GitHub (Apr 18, 2026):
File is too large for the system to handle, so I stuck it up on my dropbox. All the files that it says it can't download from the printers ARE on the SD cards on the machines.
https://www.dropbox.com/scl/fi/13wujm19joe141l1gzgex/leachie_100-8mm.gcode.zip?rlkey=izikzyiufo7qgfait4h1aagbf&dl=0
@maziggy commented on GitHub (Apr 18, 2026):
From a sliced file I cannot see if objects are grouped or not.
@heffe2001 commented on GitHub (Apr 18, 2026):
I know for sure that they aren't grouped or merged, each section is it's own object. The body's are seperate from the tails, and heads (they all can be moved independantly from each other). Nothing's changed on these files since before I used any farm management (Bambudy or BFM), and have always allowed me to skip bad sections. I'm testing sending a print from archive now (uploaded to a virtual printer, archived, then sent to the same printer that I couldn't skip before), and I suspect it will work then. I DO notice that the upload is taking forever to send, so could it be having timeouts while attempting to download a print that was sent directly to the printer and failing, causing the issue? Just for completeness, I'm running the Bambuddy server on a VM on Proxmox, with 8 cores, 16g memory, and 512g storage dedicated to it, running Ubuntu 25.10.
@maziggy commented on GitHub (Apr 18, 2026):
Yes
@heffe2001 commented on GitHub (Apr 18, 2026):
A file sent to archive directly, then sent to the printer has the skip option just fine. I'm going to bump up the timeout to the next setting and try sending one directly to a printer, and see if it works.
@heffe2001 commented on GitHub (Apr 18, 2026):
Stuck one of the printers on it's own wifi network (I have a few around here), just to make sure it wasn't having to compete with other machines bandwidth usage, with the same results (can't skip, file doesn't download to the server). I DID turn on debug logging before I started the transfer, so whatever is happening should be logged this time.
bambuddy-support-20260418-150946.zip
@maziggy commented on GitHub (Apr 18, 2026):
You have a network problem. Logs are full with
@heffe2001 commented on GitHub (Apr 18, 2026):
Yeah, I noticed that. That's one reason I moved that one printer over to a new Wifi.. I just noticed that once a file is sent to the printers, that printer becomes unresponsive to bambu studio also for a few seconds...
@heffe2001 commented on GitHub (Apr 18, 2026):
Looks like someone (or multiple someones, lol), have turned up several new wireless connections in our neighborhood, and have several bands absolutely saturated on the 2.4ghz networks.. I made some adjustments (well, my Unifi setup did, lol), and as of now, it appears I'm getting a more stable connection on the wireless (I was getting a massive amount of interference on the 2.4ghz band). I'll monitor it and see if it improves. DAMN I wish they'd have made these things with ethernet ports...
@heffe2001 commented on GitHub (Apr 19, 2026):
My connections are pretty stable at the moment, so I sent another file to oen of my other A1's, and it's doing the same thing. I see in the log files where the system says the file fails, but right above that, it says that the file was downloaded successfully?
INFO: 192.168.0.45:49228 - "GET /api/v1/queue/?status=pending HTTP/1.1" 200 OK
INFO: 192.168.0.45:64328 - "GET /api/v1/pending-uploads/count HTTP/1.1" 200 OK
2026-04-18 22:41:01,904 INFO [backend.app.services.bambu_ftp] Successfully downloaded //Rock_Stone_Boulder.gcode.3mf to /app/data/archive/temp/Rock_Stone_Boulder.gcode.3mf (8681710 bytes)
2026-04-18 22:41:01,905 INFO [backend.app.services.bambu_ftp] FTP mode cached for 192.168.0.148: prot_p
INFO: 192.168.0.45:54044 - "GET /api/v1/pending-uploads/count HTTP/1.1" 200 OK
INFO: 192.168.0.45:53938 - "GET /api/v1/queue/?status=pending HTTP/1.1" 200 OK
INFO: 192.168.0.45:53938 - "GET /api/v1/pending-uploads/ HTTP/1.1" 200 OK
INFO: 192.168.0.45:63215 - "GET /api/v1/queue/?status=pending HTTP/1.1" 200 OK
INFO: 192.168.0.45:53938 - "GET /api/v1/pending-uploads/count HTTP/1.1" 200 OK
INFO: 192.168.0.45:53938 - "GET /api/v1/printers/developer-mode-warnings HTTP/1.1" 200 OK
INFO: 192.168.0.45:53938 - "GET /api/v1/queue/?status=pending HTTP/1.1" 200 OK
INFO: 192.168.0.45:49589 - "GET /api/v1/pending-uploads/count HTTP/1.1" 200 OK
INFO: 192.168.0.45:49589 - "GET /api/v1/pending-uploads/ HTTP/1.1" 200 OK
INFO: 192.168.0.45:51615 - "GET /api/v1/pending-uploads/count HTTP/1.1" 200 OK
INFO: 192.168.0.45:49589 - "GET /api/v1/queue/?status=pending HTTP/1.1" 200 OK
INFO: 127.0.0.1:49610 - "GET /health HTTP/1.1" 200 OK
INFO: 192.168.0.45:65273 - "GET /api/v1/queue/?status=pending HTTP/1.1" 200 OK
INFO: 192.168.0.45:60495 - "GET /api/v1/pending-uploads/count HTTP/1.1" 200 OK
INFO: 192.168.0.45:60495 - "GET /api/v1/pending-uploads/ HTTP/1.1" 200 OK
INFO: 192.168.0.45:52208 - "GET /api/v1/pending-uploads/count HTTP/1.1" 200 OK
INFO: 192.168.0.45:60495 - "GET /api/v1/queue/?status=pending HTTP/1.1" 200 OK
INFO: 192.168.0.45:53243 - "GET /api/v1/queue/?status=pending HTTP/1.1" 200 OK
INFO: 192.168.0.45:59973 - "GET /api/v1/pending-uploads/count HTTP/1.1" 200 OK
INFO: 192.168.0.45:59973 - "GET /api/v1/pending-uploads/ HTTP/1.1" 200 OK
INFO: 192.168.0.45:59973 - "GET /api/v1/support/debug-logging HTTP/1.1" 200 OK
INFO: 192.168.0.45:63763 - "GET /api/v1/queue/?status=pending HTTP/1.1" 200 OK
INFO: 192.168.0.45:63316 - "GET /api/v1/pending-uploads/count HTTP/1.1" 200 OK
INFO: 192.168.0.45:63316 - "GET /api/v1/printers/developer-mode-warnings HTTP/1.1" 200 OK
INFO: 192.168.0.45:63316 - "GET /api/v1/queue/?status=pending HTTP/1.1" 200 OK
INFO: 192.168.0.45:50764 - "GET /api/v1/pending-uploads/count HTTP/1.1" 200 OK
INFO: 192.168.0.45:50764 - "GET /api/v1/pending-uploads/ HTTP/1.1" 200 OK
2026-04-18 22:41:47,606 WARNING [backend.app.services.bambu_ftp] FTP download timed out after 60.0s for //Rock_Stone_Boulder.gcode.3mf
2026-04-18 22:41:47,606 INFO [backend.app.services.bambu_ftp] Download 3MF from //Rock_Stone_Boulder.gcode.3mf attempt 2/4 returned failure
2026-04-18 22:41:47,606 INFO [backend.app.services.bambu_ftp] Download 3MF from //Rock_Stone_Boulder.gcode.3mf will retry in 3.0s...
INFO: 192.168.0.45:50764 - "GET /api/v1/queue/?status=pending HTTP/1.1" 200 OK
So according to those logs, it downloaded it sucessfully to /app/data/archive/temp/Rock_Stone_Boulder.gcode.3mf, but 'times out' and fails after finishing?
@maziggy commented on GitHub (Apr 19, 2026):
Please upload a support package -> https://wiki.bambuddy.cool/features/system-info/?h=debug#enable-debug-logging
@heffe2001 commented on GitHub (Apr 19, 2026):
I upgraded to the latest daily (0.2.4b1) and sent another print to that printer, and had another download failure. I'm not seeing those messages about resets of failures to resolve, etc. Still not getting a sucessful downloads on files with any size to them.. I sent a small print to one of the other A1's last night (about a 30 minute print, so very small file), and it DID sucessfully download that one. I wish I'd have left these logs running a bit longer, so it could have caught more of the download failures.
bambuddy-support-20260419-150138.zip
@heffe2001 commented on GitHub (Apr 19, 2026):
I am also seeing errors detecting AMS serial numbers throughout the logs (it's probably logged in the support log above too):
@heffe2001 commented on GitHub (Apr 19, 2026):
Sent a print to another printer, and got a slightly different result, as it says the file doesn't exist on the printer (550 error), even though it's currently printing now, shows a thumbnail, etc.
Just as a fyi, I've been using all these same printers on Farm Manager for about 3 months, with few issues. I know, it's not a equal comparison, but never had the SD card read/write issues, prior to moving to Bambuddy (could that be part of the cause, do I need to reformat my SD cards on the printers that aren't working correclty?).
bambuddy-support-20260419-154838.zip
EDIT For whatever reason, I didn't realize if I set the virtual printers as 'archive & queue', I could get the same functionality as you get from BFM. Allows me to go to the page and select which printer to send it to, and also archives it. Since this is basically the process we came from prior, I'll probably just use this method and bypass sending directly to the printer (unless it's a quick one-off print anyway).
@maziggy commented on GitHub (Apr 20, 2026):
Found the zombie-thread race that explains the "Successfully downloaded" log followed by a "timed out" failure. download_file_async runs the blocking FTP RETR in a thread pool via asyncio.wait_for, which can't cancel the thread on timeout. On your slow WiFi the download took ~77s total against your 60s ftp_timeout, so:
The archive pipeline got None and created a fallback row with no 3MF data — which is why Skip-Object couldn't find the 35 objects even though the file was on disk
Fix on dev: the post-timeout grace now waits on a threading.Event the worker sets when it genuinely finishes, bounded by max(min(ftp_timeout, 30), 0.5) seconds. For your 60s ftp_timeout that's a 30s grace — enough to salvage a download that's 10–30s over the timeout without stalling a truly stuck connection. Attempt 1 should now succeed on its own rather than triggering contending retries.
Glad the archive-and-queue VP workaround is working for you in the meantime.
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!