2 Commits

Include renames

Author	SHA1	Message	Date
maziggy	4e79f9c2f7	Fill in a fallback archive when the 3MF finally arrives (issue #2957) ... A failed TLS handshake pauses a printer's file service for five minutes, and the archive flow checks that pause at the top of its path loop and gives up before opening a connection. A print that starts inside one gets an empty fallback archive 13 milliseconds later, having never touched the network. Four minutes on, the pause clears and the cover endpoint downloads the same file, parses it, takes a thumbnail out of it, and publishes it to the shared 3MF cache under the exact key the archive flow looks up. Nothing ever looks: all three readers of that cache run before or during the print-start handler that already gave up, and print completion drops the cache as its first act, deleting the file. No path existed by which a fallback archive could become a real one. Offer a later 3MF to the running print's archive, filling the existing row rather than adding a second -- the row id carries the energy reading, the timelapse session and the start notification. That covers the reported case at no network cost, since opening the printer card already downloads the file. Schedule a bounded retry when the pause is what caused the fallback, spending the cache first and the printer only if that misses. Not scheduled for the other cause: a print kept on internal eMMC has no FTPS copy to come back for, and retrying it is the sweep removed in #2780. The two reasons are now recorded separately instead of both landing as "no 3MF". Recovery refuses anything that is not a readable 3MF -- a truncated download would replace an honest empty archive with wrong metadata -- and leaves an archive alone once it has a real file. Three things the recovery path has to get right, each with a test: Reduce every retry candidate to a bare name. MQTT hands `filename` over as "/data/Metadata/plate_1.gcode" on some firmware, and joining that onto the temp directory yields the absolute path itself, so the retry is fed the flow's own sanitised candidate list and strips the path again on its own account. Serialise recovery per printer. The cover endpoint's single-flight coalesces by view, so two views race each other, and the retry task and print completion can land on top of either -- each reads file_path == "" and runs a full copy, leaving the row on one timestamped directory and the rest orphaned. Keep looking for photos in the pre-recovery directory. `archive_dir` derives from `file_path`, so filling the row moves the archive's directory, and a photo uploaded to the empty card while the print ran stays where it was put.	2026-08-25 09:33:52 +02:00
maziggy	0623cc46df	Repair no-3MF archives' photos and their silent filament writes (#1820) ... Two faults behind the same kind of print: one that arrives without a retrievable 3MF, which on an H2S is any job started from the printer's own internal library. Such an archive has no file_path, and Path("").parent is Path("."), so every site that derived the archive's folder from it landed on the data directory itself. The finish-photo capture spotted that and wrote to <archive_dir>/<id>/photos instead. Nothing else did. The photo was written in one place and looked for in another: reads 404'd, deletes dropped the name and left the file, and the notification attachment never found the image. Hand-uploaded photos worked only because upload and read agreed with each other rather than with the capture. Give the question one owner in utils/archive_paths and have all four sites ask it. Lookups check the old shared location too, so photos already uploaded there stay reachable; uploads now go where captures go. Separately, the remain%-delta fallback that stands in for a missing 3MF can charge nothing for several reasons, and did so without a word. The AMS reading is coarse and, on the reporter's printer, noisy: it rises mid-print, swings five points over a job, sits at 100% through a 36-minute print on a fresh spool, and goes negative on a nearly empty one -- which the start-of-print gate rejects, dropping the only slot that was printing. Two of their prints went uncounted for two different reasons and both read as "no spools updated", which is also what a print with nothing to charge prints. Name the slot and the two readings in each case, on the Spoolman path and on the internal-inventory path, which has carried the same gates since #1119. The Spoolman path also had no notion of which slots the print used, so a spool swapped into an idle slot mid-print reads as consumption and is billed to whoever that slot is assigned to -- the fault #1269 fixed for the internal tracker, still open here, and likeliest on exactly the prints this fallback serves, where nothing else narrows the field. Use the same three pieces of evidence it does: the print's mapping, its mid-print tray changes, and the tray it started on. The last needs storing, because the internal tracker's row is deleted before this runs and a screen-started print has no mapping to fall back on -- hence a new nullable column, and no backfill, since a row from before it existed has nothing to say. Where no evidence exists at all, every slot is still considered. Both paths also treated tray_now == 255 as naming a slot. It does not: it is the field's initial value, the fallback for an unparseable reading, and what it reports with nothing loaded. Mapped as a tray id it becomes (255, 1), so as the only evidence it excluded every real slot and charged nothing at all -- this issue's own bug, arriving by a new route. On the internal path that is live today; on the Spoolman path it would have shipped with the guard above. The external holder reports 254 when it is genuinely in use. The arithmetic is untouched: at one percent per step this cannot resolve a small print, and pretending otherwise would be worse than saying so.	2026-08-14 15:32:40 +02:00