mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-05-09 08:25:54 +02:00
[GH-ISSUE #315] [Bug]: Archive Issues | Timelapse & Calibration Tests #198
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#198
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 @jjjonesjr33 on GitHub (Feb 9, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/315
Originally assigned to: @maziggy on GitHub.
Bug Description
The archive displayed the wrong timelapse for my most recent print.
Expected Behavior
To show the correct timelaps.
Steps to Reproduce
I have multiple timelapses still on the printer. When the current print finishes, it pulls a previous timelapse instead of the one that just completed.
Printer Model
H2C
Bambuddy Version
v0.1.9b
Printer Firmware Version
01.01.03.00
Installation Method
Docker
Operating System
Docker
Relevant Logs / Support Package
Screenshots
Archive: Cascade Connect - A Self Sorting Connect 4 - Plate 4
Timelaps:
Screenshot:
Additional Context
No response
Checklist
@jjjonesjr33 commented on GitHub (Feb 10, 2026):
To add to this issue, it archived my calibration tests.
@jjjonesjr33 commented on GitHub (Feb 10, 2026):
So can confirm with the timelaps, that is still an issue. It seems to randomly pick in order what is stored on the machine vs using the latest timelaps.
For example, these were my last two prints that were sucessful
but you can see in the timelapes it pulls the first two
@maziggy commented on GitHub (Feb 10, 2026):
Yeah....I'm sure that has something to do with printer's system time. The problem is, that the firmware doesn't set system time via NTP if using LAN only mode (I already opened a bug with Bambu Lab for this). Since we cannot use the timestamp to look up the correct timelapse file, i added some workarounds. Let me check....
@jjjonesjr33 commented on GitHub (Feb 10, 2026):
Random thoughts ...
With the way the timelapses are stored and labeled on the device, do you think it’s possible to have it just pick the most recent file instead of using the system time?
latest print
The one before it
The file names do increment sequentially—so could it just use that to find the latest one?
@maziggy commented on GitHub (Feb 10, 2026):
Fixed in branch 0.1.9b.
Will push a new Docker image once all your issues are fixed ;)
@jjjonesjr33 commented on GitHub (Feb 10, 2026):
Awesome, thank you! If anyone asks, I appreciate you. 😄 haha
@maziggy commented on GitHub (Feb 10, 2026):
docker pull ghcr.io/maziggy/bambuddy:0.1.9b2
@jjjonesjr33 commented on GitHub (Feb 10, 2026):
I'll check this in the morning once it finishes the current print.
@jjjonesjr33 commented on GitHub (Feb 10, 2026):
Well it finished, but didn't pull a timelaps or a screenshot now
I have another print going so once its done I'll check it since you just bumped us to v0.1.9
@maziggy commented on GitHub (Feb 11, 2026):
Identified and fixed a race condition.
ghcr.io/maziggy/bambuddy:0.2.0b1
@maziggy commented on GitHub (Feb 15, 2026):
@jjjonesjr33 ?
@jjjonesjr33 commented on GitHub (Feb 15, 2026):
The only issue I seem to be seeing now is for failed prints / duplicates. Example:
First one is currently printing while the 2nd and 3rd failed.
There also seems to be a duplicate when one is completed and one is failed, but it doesn't tag it as a dupe.
@maziggy commented on GitHub (Feb 15, 2026):
Fixed in branch 0.2.0b. Please let me know how it goes.
@maziggy commented on GitHub (Feb 17, 2026):
@jjjonesjr33 ?
@jjjonesjr33 commented on GitHub (Feb 18, 2026):
@maziggy Sorry been away helping with family the past couple of days.
Still have that issue going on with where it's showing duplicates if mutiple prints are done instead of merging them. I don't think thats a bug at this point, but more of a way need to solve how dupes are shown in the software.
If there was a way to group it by model automaticly so you could see the order they were still in with the details but under one showing that would be a better way I think instead of the archive becoming over ran with dupes.
@maziggy commented on GitHub (Feb 19, 2026):
If you re-print an existing archive it should not create a new archive card for it.
Let me check....
@maziggy commented on GitHub (Feb 19, 2026):
What version do you used for testing?
Also how do you started the prints? Via slicer or Bambuddy?
@jjjonesjr33 commented on GitHub (Feb 19, 2026):
Via the slicer and I'm on the latest beta.
@maziggy commented on GitHub (Feb 19, 2026):
Latest beta in your case means what? :) Latest is 0.2.1b.
@jjjonesjr33 commented on GitHub (Feb 19, 2026):
Actually V0.2.0b. Docker hasn't said there was an update yet.
@maziggy commented on GitHub (Feb 19, 2026):
Just release 0.2.1b, but it's not tagged as latest.