|
|
@@ -59,6 +59,7 @@ All notable changes to Bambuddy will be documented in this file.
|
|
|
- **The frontend build no longer warns about `path` and `crypto` being externalized for the STEP previewer (#2976)** — `occt-import-js`, the Emscripten build behind STEP previews, requires both modules, but only inside its `ENVIRONMENT_IS_NODE` branches; in the browser it loads its `.wasm` from the URL the preview worker passes and draws randomness from `crypto.getRandomValues`. Vite still externalized both and printed two warnings on every build. `vite.config.ts` now drops exactly those two warnings for that one package through `build.rolldownOptions.onLog`, so an externalization anywhere else, or of any other module, still shows.
|
|
|
|
|
|
### Fixed
|
|
|
+- **Stream overlay and Cam Wall links keep working after a reload (#3204, reported and contributed by @adamspicedev in #3212)** — Opening an `/overlay/…?token=…` or `/camwall?token=…` link treated the token as a login: Bambuddy removed it from the address bar and tried to sign in with it, which a streaming token can't do. The page worked the first time, but a reload (or an OBS or Meld browser source restarting) had no token left and stayed on **Loading…**. In a browser that was already signed in, the failed attempt also signed the user out. The token now stays in the link and is used only by the overlay or Cam Wall, and an existing login is left alone. SpoolBuddy kiosk links still sign in with their API key as before.
|
|
|
- **The File Manager reaches the bottom of the window again (#3215, reported by @koder-guy)** — On desktop the File Manager and the G-code viewer were sized as if a 64px top bar sat above them, but that bar only exists in the mobile layout, so both pages stopped 64px short and left an empty band under the file browser. They now fill the full window height.
|
|
|
- **Progress milestones no longer send 75% at the start of a print, and 25% and 50% arrive again (#3211, reported by @BurgerKerman)** — An A1 mini reports a progress of 85% in the first moment of a print, while it is still heating the bed, and then values such as 3%, 40% and 44% through its calibration, before the first layer starts at 45%. Bambuddy read that 85% as progress and sent the 75% milestone together with Print Started, with an unknown remaining time. With 75% then on record, the 25% and 50% milestones of that print never fired. Milestones now count only from the first printed layer, and every new print starts them from zero. A printer that started layer 1 already past 25% sends the 25% milestone then. Until a print's layer count is known, the printer's preparation stage (bed preheating, homing, calibration) holds milestones back the same way. Printers that report neither behave as before.
|
|
|
- **A printer that refuses uploads no longer empties the print queue (#3210, reported by @Leander-Vh)** — When a printer's file service would not take a file, the queue marked the job failed. That left the printer idle, so the next pass gave it the next job, which failed the same way: one P2S whose file service answered `421 There are too many connections` failed 43 queued jobs in ten minutes. When the file never reached the printer (the connection was refused, timed out or dropped), the job now stays in the queue, and the printer gets no new jobs for five minutes. The wait doubles with each refusal in a row, up to an hour, and the first upload that gets through resets it. Jobs for any printer of that model go to the others, and a job assigned to that printer shows "*printer* is not accepting files — Bambuddy will retry automatically" until it can be sent. One Job Waiting notification goes out per outage, not one per retry, and **Keep bed warm between prints** does not heat a printer that is waiting this way. A rejected access code, a full SD card (including an FTP 452 reply, which used to be read as a network error) or an upload too slow to finish still fails the job, because a retry would fail the same way.
|
maziggy