mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-05-09 00:08:34 +02:00
[GH-ISSUE #1210] [Bug]: Printing from USB gives unkown filament #878
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#878
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 @DrogerTie on GitHub (May 4, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1210
Originally assigned to: @maziggy on GitHub.
Component
Bambuddy
Bug Description
When I start a print from the printer itself, it does not show correctly in archives. The 3MF is on the USB stick and can be started going thru the menu of the printer. Happens on H2D and H2C. I have both. both are running on latest firmware.
Expected Behavior
I expect the bambuddy view the print in Archives correctly when starting it thru the printer menu. This scrambles the statistics as it now shows as unknown filament.
Steps to Reproduce
1 go to main menu of the printer
2 select start printing
3 go to USB
4 select file and start print
Printer Model
H2C
Bambuddy Version
v0.2.3.2
SpoolBuddy Version
No response
Printer Firmware Version
01.01.05.00
Installation Method
Docker
Operating System
Linux (Ubuntu/Debian)
Relevant Logs / Support Package
bambuddy-support-20260504-202217.zip
Screenshots
Additional Context
No response
Checklist
@maziggy commented on GitHub (May 5, 2026):
I see what's happening at the Bambuddy side but I need a bit more from your printer to be sure.
When the print started, Bambuddy did find 14 3MF files in the FTP root, but my logs only show the first 5 names. So I can't tell whether your USB-printed file is one of the other 9 (and we have a filename-matching bug) or genuinely missing (USB prints don't replicate to FTP on this firmware).
While a USB-stick print is running on the H2C, could you connect to the printer's FTP and paste the full root listing? Replace
<PRINTER_IP> with the printer's IP and <ACCESS_CODE> with the LAN access code shown on the printer.
Linux / macOS (lftp):
Linux / macOS (curl):
Windows (FileZilla works fine — just connect and screenshot the root):
Host: ftpes://<PRINTER_IP>
Port: 990
User: bblp
Pass: <ACCESS_CODE>
Encryption: "Require explicit FTP over TLS"
What I'm looking for: the exact filename for the running USB print as the printer's FTP shows it. If it's in the listing, this is a
matching-bug fix on our side. If it's not, we'll dig into where the firmware actually puts USB-print files.
Same question if it's easier to test on your H2D too — same FTP behavior expected for both.
If you also want to spot-check your H2D quickly to confirm USB prints do appear on FTP root, the same lftp one-liner against your printer IP while a USB print is mid-flight will answer it in a few seconds — useful for narrowing the scope before the reporter replies.
@DrogerTie commented on GitHub (May 5, 2026):
roger@Openclaw:~ $ curl -k --ftp-ssl --user "bblp:XXXXXXX" "ftps://XXXXXXXXX:990/"
Warning: --ftp-ssl is an insecure option, consider --ssl-reqd instead
-rwxr-xr-x 1 1002 1002 598025 Mar 18 22:50 Frame_for_Hueforge_various_dimensions..gcode.3mf
drwxr-xr-x 2 1002 1002 16384 Mar 06 2021 System Volume Information
drwxr-xr-x 3 1002 1002 16384 Apr 24 00:52 ipcam
drwxr-xr-x 3 1002 1002 16384 Mar 19 07:13 timelapse
-rwxr-xr-x 1 1002 1002 16 Apr 23 22:36 verify_job
roger@Openclaw:~ $ curl -k --ftp-ssl --user "bblp:XXXXXXXX" "ftps://XXXXXXXXX:990/"
Warning: --ftp-ssl is an insecure option, consider --ssl-reqd instead
-rwxr-xr-x 1 103 107 8297845 Mar 30 00:17 Canister_Set.gcode.3mf
-rwxr-xr-x 1 103 107 3268939 Mar 29 07:33 Fidget_Cube_Toy_Angled.gcode.3mf
-rwxr-xr-x 1 103 107 3568230 Mar 28 20:03 Frame_(Layered_Sculptures_or_Hueforge).gcode.3mf
-rwxr-xr-x 1 103 107 202036 Mar 31 04:24 Frame_for_Hueforge_various_dimensions..gcode.3mf
-rwxr-xr-x 1 103 107 683505 Mar 31 08:15 Glow_Glasses.gcode.3mf
-rwxr-xr-x 1 103 107 927469 Mar 31 11:46 Minimalistic_Phone_Stand_.gcode.3mf
-rwxr-xr-x 1 103 107 2361189 Mar 30 22:06 PayWand_-Tap_to_Pay_magic_payment_wand.gcode.3mf
-rwxr-xr-x 1 103 107 3378720 Mar 28 13:20 Segment_1.gcode.3mf
-rwxr-xr-x 1 103 107 4673011 Mar 29 05:26 Sensory_Fidget_Cubes.gcode.3mf
drwxr-xr-x 2 103 107 8192 May 03 2026 System Volume Information
-rwxr-xr-x 1 103 107 2322108 Mar 29 18:38 The_Amazing_Digital_Circus-Door_Icons.gcode.3mf
-rwxr-xr-x 1 103 107 510649 Mar 29 02:26 Ultraschallbild_Deko_für_Mütter.gcode.3mf
-rwxr-xr-x 1 103 107 249307 Mar 29 21:16 Wall_mounting_for_AMS+AMS_2_Pro&_AMS_HT.gcode.3mf
-rwxr-xr-x 1 103 107 3702588 Mar 28 16:30 baby adriaans_plate_2.gcode.3mf
drwxr-xr-x 3 103 107 8192 Mar 31 18:34 ipcam
drwxr-xr-x 3 103 107 8192 Mar 31 18:24 timelapse
-rwxr-xr-x 1 103 107 16 Mar 31 11:46 verify_job
-rwxr-xr-x 1 103 107 2109356 Mar 29 06:05 一体打印_能重复螺旋的方形穿越_解压玩具_TD1方形.gcode.3mf
only Now when I try it running it from a USB stick, it all works on every printer and it shows in the archive. so frustrating. I will wait till the prints are ready and try another one that was a problem yesterday.
bambuddy-support-20260505-175152.zip
@maziggy commented on GitHub (May 5, 2026):
Good news — your latest log shows it working end-to-end on the H2C:
The H2D was mid-print when the log started so I don't have a fresh on_print_start event for it in this package. Two questions to close this out:
The "unknown filament" rows in your screenshot — are those new archives you noticed since updating, or older ones that were already in your library? My guess is they pre-date some earlier fix and just haven't been retroactively repaired.
If you spot a fresh USB-print archive coming in as "unknown filament" on either machine, grab a support package right after that print starts (within a minute or two) — the on_print_start log line is where I can see the FTP filename it found vs. what was on the printer, and that's the data I'm missing here.
@DrogerTie commented on GitHub (May 5, 2026):
The screenshot was in my first post is from 26th of april, But this one was from yesterday:
I wil try and start this one again today and see what happens now.
Wierd you say it shows it was mid-print cause I am sure I started the debog logging before starting all my prints. it was running for a few minutes cause I needed to get things ready. It was then running for 30m or so when I downloaded the log.
How do we repair retroactively?
I will monitor the archive. I will start the debug-logging the next few prints in the hope It will happen so you can get a better log for debugging. I will also try and start one from the internal memory and maybe this will trigger the error?
@DrogerTie commented on GitHub (May 5, 2026):
got two failed archives now. I printed the phone stand on the H2D thru the internal memory of the printer, not with the USB.
The H2C was thru the USB and it was the chinese named fidget.
the log was running for a good 3 min before starting both. I ended it after 12m when both machines where printing.
bambuddy-support-20260505-191328.zip
@maziggy commented on GitHub (May 6, 2026):
Did you follow the install instructions?
@DrogerTie commented on GitHub (May 6, 2026):
I did not. I just turned it on and will monitor my next prints and if the archives are filed correctly. Still these prints are already on my USB from before using bambuddy. So are you saying when using the internal memory it will always fail to archive it correctly? The chinese named fidget is on my USB as .3mf, which I expect to archive correctly so idk why it fails