A print that finishes now takes itself off the queue, and printing the same file twice in one day is finally logged twice.
The queue closes its own rows
The monitor already did the hard part. It notices a job ending, writes the print log with the real duration and the real filament rather than the slicer's estimate, and takes the grams off the spool. It simply had no idea the queue existed. So a row you started, that PrintVault sent, watched and logged entirely by itself, still sat there saying printing until you went and ticked it off.
A successful send now writes onto the row which file went to which printer, and the monitor looks that up when a job ends. What it finds back there is better than anything it could work out alone: the model comes off the row instead of being guessed out of the filename, and the spool you chose when you queued the job wins over whichever one happens to be flagged in use.
A run of six is six prints, so a finished copy advances a count rather than closing the row, and the row drops back to pending ready for the next one. The row, its estimates and the totals across the top all count what is left instead of what you first typed, so a batch half way through reads 4x with "2 of 6 printed" beside it. A print that stops early counts for nothing and goes straight back. Pressing Done yourself still closes the whole row, however many copies were on it.
Printing something twice a day now records both
Making that count work exposed why it never could have. The guard against logging one job twice matched on printer, file and day:
x.auto && x.printer === printer.name && x.date === U.today() && x.jobFile === name
Which quietly meant a file could only be logged once in a day. Print the same thing three times in an evening and you got one print record and one filament deduction. The other two were dropped on the floor, grams and all, and nothing said so. Anyone running repeats, a batch of the same part or a printer farm, has been losing print history to this.
It is a flag now, set when a run is written down and cleared the moment the printer reports printing again. One run logs once, on its own account, however alike two of them look. A window of time was the obvious fix and the wrong one: a short print is genuinely indistinguishable from a duplicate tick that way.
Fixed
- The queue was unusable on a phone. The card is a single nowrap row, so the wider button labels that came with 0.2.27 squeezed the name column to nothing, wrapped its details one word per line, and pushed the last button off the screen. It wraps below 640px now, name beside the thumbnail and the buttons underneath. The printing row had been overflowing on its own since well before those labels.
- The duplicates tab said "N in zips" above a list that has always counted 7z and rar too.