Fix stale LAN printer info before local print

[tangkelu]

Summary

• Fix LAN printer readiness check to reject stale push info.
• Automatically reconnect the selected LAN printer when printer info is stale.
• Retry get_version and pushall while waiting for refreshed LAN printer info before local printing.

Root Cause

In LAN/developer mode, stale printer push data could be treated as ready, so the print dialog showed cached device information while the local MQTT publish path was no longer valid. Printing then failed with local print publish error (-4030). After correcting the readiness check, the dialog exposed the real issue: it waited until timeout without re-triggering the same LAN reconnect flow users performed manually by reselecting the printer.

Verification

• Built Release target BambuStudio_app_gui successfully with VS 2022:
  cmake --build build-verify --config Release --target BambuStudio_app_gui -- /m /nr:false /v:minimal
• Verified with a local LAN A1 printer:
  • Before fix: device info changed from syncing to timeout, or local print failed with -4030.
  • After fix: device info refreshes and LAN print can start successfully.

[OskisJ]

Timeout logic is wrong

network and stuff is not my jam but check src/slic3r/GUI/DeviceManager.cpp in is_info_ready line 2382
i think this code uses wrong clock, this could cause some issues, i asked copilot what could cause issues with your implementation

What can go wrong if system_clock is used for timeout logic?
system_clock tracks wall‑clock time, not elapsed time.
Wall‑clock time can jump forward or backward due to:

• NTP time sync
• Windows/macOS auto‑adjust
• User manually changing the clock
• Daylight savings adjustments
• VM host time drift
• Laptop waking from sleep
  This is why it’s dangerous for timeout logic.

std::chrono::system_clock::time_point curr_time = std::chrono::system_clock::now();
auto push_age = std::chrono::duration_cast<std::chrono::milliseconds>(curr_time - last_push_time);

The code uses std::chrono::system_clock to measure elapsed time. system_clock is not monotonic and can jump backwards or forwards due to NTP adjustments or user changes, leading to negative ages or premature timeouts.

Here is my take for this:

Note: make sure that last_push_time is also changed to std::chrono::steady_clock::time_point

std::chrono::steady_clock::time_point curr_time = std::chrono::steady_clock::now();
auto push_age = std::chrono::duration_cast<std::chrono::milliseconds>(curr_time - last_push_time);

[OskisJ]

The check push_age.count() >= 0 is good for handling system clock adjustments, but ensure PUSHINFO_TIMEOUT is correctly scaled now that the unit changed from microseconds to milliseconds.

[tangkelu]

PUSHINFO_TIMEOUT is already defined in milliseconds (15000.f in DeviceManager.hpp), so no additional scaling is needed here. The previous code was actually mixing microseconds with a millisecond timeout, and also computed last_push_time - now, which made the stale check effectively always pass for normal past timestamps. This change intentionally aligns the duration unit with the timeout constant.

I agree steady_clock would be a cleaner choice for elapsed timeout logic; that can be a follow-up, but it is separate from the unit conversion in this patch.