[Bug]: Timelapse is being enabled by default

[agrisci]

Product

Bambuddy

Area

Camera / live view / timelapse

Bug Description

First of all, thank you for the great work — this software has really enhanced my printing experience!
The issue started in version v0.2.4.6. Timelapse appears to be enabled by default (even though it is disabled in the default print options), which results in bad prints for me, as the nozzle travels to the purge/wiper at the end of each layer. This is confirmed by my Home Assistant history.

When I sent the same print directly from Orcaslicer to the printer, the timelapse behavior did not occur.

Expected Behavior

Printing should continue uninterrupted, without the nozzle travelling to the wipe/purge area after each layer.
Timelapse should not be running while it is disabled in the default print options.

Steps to Reproduce

Setup Bambuddy with Virtual Printer in Queue mode.
Send print via Orca Slicer 2.4.1.

Troubleshooting steps already taken

Checked release page for version v0.2.4.6 and found this change that might be the reason:

Finish photo no longer shows the bed already dropped (https://github.com/maziggy/bambuddy/issues/1397, reported by @rtadams89, @Jeff-GebhartCA, @MA2ZAK). Bambu's end-gcode lowers the build plate at print completion; capturing at gcode_state=FINISH showed the print well below the camera's natural framing. Fix sources the photo from a brief Bambu timelapse Bambuddy now force-records on every dispatched print — firmware stops recording AFTER the toolhead parks but BEFORE the bed-drop end-gcode runs, so the last frame frames the finished print correctly. BackgroundDispatchService overrides timelapse=True on the MQTT command + marks PrintArchive.bambuddy_forced_timelapse; new extract_video_last_frame ffmpeg helper extracts the last frame; _cleanup_forced_timelapse deletes both the locally-attached file and the on-printer copy when the user didn't ask for one. Verified on N=2 H2C prints; bed-slinger field verification welcome. Round-2 fix in the same drop: extractor switched from -sseof -1.0 to -update 1 (frame-per-layer recording produces sub-second videos on small prints, where the 1-second seek-from-end went before the start of the file); resolver wired into print_scheduler.py so queue-dispatched prints get the override too (not just background_dispatch.py).

Printer Model

A1

Bambuddy Version

2.4.6

SpoolBuddy Version

No response

Printer Firmware Version

01.08

Installation Method

Docker

Operating System

Linux (Ubuntu/Debian)

Support Package (.zip) and / or relevant logs

bambuddy-support-20260612-011841.zip

Screenshots

No response

Additional Context

No response

Final checks

• I searched existing (open AND closed) issues and this bug hasn't already been reported or resolved
• I checked the Troubleshooting wiki and the relevant feature page for my issue
• I am using the latest version of Bambuddy (or the latest daily build)
• My printer is set to LAN Only mode
• My printer has Developer Mode enabled
• For any connection / printing / camera issue, I ran the in-app Connection Diagnostic and included the result above

[maziggy]

Fist of all you need to install Bambuddy properly. Your logs are flooded by error messages. For example:

2026-06-11 23:57:26,225 WARNING [backend.app.services.virtual_printer.mqtt_server] [89426f14] [Bambuddy] MQTT auth failed for user 'bblp' (access code mismatch)
2026-06-11 23:57:26,328 WARNING [backend.app.services.virtual_printer.mqtt_server] [89426f14] [Bambuddy] MQTT auth failed for user 'bblp' (access code mismatch)
2026-06-11 23:57:29,332 WARNING [backend.app.services.virtual_printer.mqtt_server] [89426f14] [Bambuddy] MQTT auth failed for user 'bblp' (access code mismatch)
2026-06-11 23:57:29,436 WARNING [backend.app.services.virtual_printer.mqtt_server] [89426f14] [Bambuddy] MQTT auth failed for user 'bblp' (access code mismatch)
2026-06-11 23:57:38,445 WARNING [backend.app.services.virtual_printer.mqtt_server] [89426f14] [Bambuddy] MQTT auth failed for user 'bblp' (access code mismatch)
2026-06-11 23:57:38,548 WARNING [backend.app.services.virtual_printer.mqtt_server] [89426f14] [Bambuddy] MQTT auth rate-limited from [IP] (>=5 failures in 60s)

2026-06-11 17:12:36,312 WARNING [backend.app.services.virtual_printer.mqtt_server] [-] [Bambuddy] MQTT client session error from [IP]:36942: [SSL: APPLICATION_DATA_AFTER_CLOSE_NOTIFY] application data after close notify (_ssl.c:2786)

2026-06-11 17:13:05,123 WARNING [backend.app.services.virtual_printer.mqtt_server] [89426f14] [Bambuddy] MQTT client session error from [IP]:41966: [Errno 104] Connection reset by peer

2026-06-11 22:52:19,068 WARNING [backend.app.main] [-] [TIMELAPSE] Attempt 1: Failed to download new file, will retry
2026-06-11 22:52:59,074 WARNING [backend.app.services.bambu_ftp] [-] FTP list_files timed out after 30.0s for /timelapse
2026-06-11 22:52:59,111 WARNING [backend.app.services.bambu_ftp] [-] FTP connection timed out to [IP]: timed out

2026-06-11 23:50:36,455 WARNING [backend.app.main] [-] SD card cleanup failed after 3 attempts for /BMCU370_Dual_micro_switch(370x49e)-TL-R2_Tools.gcode (file may linger on SD card)

2026-06-11 23:53:17,053 WARNING [backend.app.services.bambu_mqtt] [-] [[SERIAL]] Connection stale - no message for 102.0s, forcing reconnect
2026-06-11 23:53:17,053 WARNING [backend.app.services.bambu_mqtt] [-] [[SERIAL]] Connected and subscribed, but the printer has sent zero status reports. The most common cause is a wrong or mis-cased serial number — the device//report MQTT topic is case-sensitive. Verify the serial number configured in Bambuddy exactly matches the printer.

That makes me think, that you didn't follow the install instructions. It doesn't makes sense to debug a system that is not running properly.

[agrisci]

Actually i have followed the install instructions to the letter.
The issue does not manifest on previous version (v2.4.5) so i had to unfortunately rollback.
What i did notice is that after the upgrade to Bambuddy version 2.4.6 i had to logout and re-add the device in Orcaslicer Devices tab, this time with the actual printers Secret code since Orca was complaining about wrong password.
Here is the virtual printer diagnostics:

Here are the printer diagnostics:

Camera is reachable both through Bambuddy and Home Assistant:

I am unable to find in printer Settings anything remotely similar to "Store sent files on external storage"

[maziggy]

Send me a new support-package please.

[agrisci]

Sure, here it is:

bambuddy-support-20260612-142218.zip

Keep in mind that i have restarted, upgraded and redowngraded to the previous version multiple times today in order to be able to provide more info.
I have also started and stopped multiple prints in order to monitor timelapse behaviour (unfortunately it is always enabled on version 2.4.6).
Finally i have also moved the printer from the DMZ vlan to the same subnet Bambuddy is located but still no change.
The issue manifests only with the newest version.

[maziggy]

No, there's still something wrong.

Check your logs!

2026-06-12 00:11:59,226 WARNING [backend.app.services.virtual_printer.mqtt_server] [89426f14] [Bambuddy] MQTT client session error from [IP]:54380: [Errno 113] No route to host

2026-06-12 00:36:33,468 WARNING [backend.app.main] [-] SD card cleanup failed after 3 attempts for /BMCU370_Dual_micro_switch(370x49e)-TL-R2_Tools.gcode (file may linger on SD card)

2026-06-12 12:37:21,409 WARNING [backend.app.services.bambu_mqtt] [-] [[SERIAL]] request_status_update: not connected

[agrisci]

Forgot to mention that i have also formatted the SD card multiple times using the actual printer's format functionality.
I have also noticed these errors and they appear immediately after the print has started:
14:49:12,317 [backend.app.services.bambu_ftp] [-] Failed to delete /BMCU370_Dual_micro_switch(370x49e)-TL-R2_plate_2.3mf: 550

In the meantime I can see the file in the SD card root folder:

And after I stop the print these populate the logs:
14:54:17,213 [backend.app.services.bambu_ftp] [-] Failed to delete /BMCU370_Dual_micro_switch(370x49e)-TL-R2_plate_2.gcode: 550 14:54:20,039 [backend.app.services.bambu_ftp] [-] Failed to delete /BMCU370_Dual_micro_switch(370x49e)-TL-R2_plate_2.gcode: 550 14:54:22,910 [backend.app.services.bambu_ftp] [-] Failed to delete /BMCU370_Dual_micro_switch(370x49e)-TL-R2_plate_2.gcode: 550 14:54:22,924 [backend.app.main] [-] SD card cleanup failed after 3 attempts for /BMCU370_Dual_micro_switch(370x49e)-TL-R2_plate_2.gcode (file may linger on SD card)

And the .3mf file disappears/gets deleted (i presume by Bambuddy?):

I am wondering if this could be a race condition.

Cache folder after i have stopped the print in case it helps:

Unfortunately I don't think i will be able to be of any further help without any specific guidance, my testing can go as far as this.

[maziggy]

2026-06-12 12:37:21,409 WARNING [backend.app.services.bambu_mqtt] [-] [[SERIAL]] request_status_update: not connected

This is the most serious error. This means, that the connection between Bambuddy and your printer is dropped.

Bad Wifi signal?

[maziggy]

Please...if you want me to debug your issue, please send me valid logs. How shall I debug, when I see errors in your logs which you forced? That doesn't work, I'm sorry.

[agrisci]

I don't understand what does valid logs mean?
I am actually trying to debug and pinpoint the issue (even if this means moving the printer from DMZ to LAN subnet which i definitely didn't want to do).
Anyway, found out that these logs appear after I have restarted the Bambuddy pod (killed it 2-3 minutes ago):

[maziggy]

See, you are sending me logs with errors, which were forced by you.

What would you think if I ask you debug a problem and after your first look at my provided logs you see many serious error messages?

[agrisci]

But the actual logs not more than 10-20 lines on top of these errors actually guide you (even me that i am not the developer of this wonderful tool) to the assumption that Bambuddy was restarted (which restart was performed only in the process of troubleshooting this issue and being able to provide more info).

Anyway, here the last pod start time:

Sent a print at 15:35.

At 15:36:

15:37 at Home Assistant timelapse reported enabled:

Stopped the print at 15:38 from Bambuddy UI.

Print showing up in archives with thumbnail:

Support Bundle exported at 15:39:

bambuddy-support-20260612-153923.zip

Let me know if you need me to let it complete a small print before exporting the support bundle.