Point the Watchtower recommendation at the maintained fork (issue #2917)

CHANGELOG.md

@@ -15,6 +15,9 @@ All notable changes to Bambuddy will be documented in this file.
 - **A file dropped on a busy or offline printer is queued instead of refused (#2849, reporter @abraha2d)** — Dragging a sliced file onto a printer card refused the drop unless the printer was connected and neither printing nor paused. The overlay went red with "Printer busy", the handler returned early, and the file was discarded with no toast and nothing uploaded; the card's Print button was hidden by the same condition, so both routes into printing from the card closed at once and the way through was the File Manager. The gate never described a real constraint. Every print Bambuddy sends becomes a queue item, and dropping onto an idle printer only looks instant because the scheduler dispatches it on the next pass — busy is a timing difference, not a different path, which is why the print dialog has always accepted a busy target and said the job would start later. Offline is included for the same reason: the queue dispatches when the printer comes back, so a machine that is powered down can be given work. The overlay now says which one is happening, "Drop to print" when the job would start immediately and "Drop to queue" when it would wait, using the same predicate the print dialog uses for its own later-start notice so the card cannot promise something the dialog contradicts a second later. The drop is also gated on the permissions the flow actually exercises — `library:upload` and `queue:create`, the pair the Print button beside it has always checked — instead of `printers:control`, which it checked and never used, and which let someone holding it alone get the file uploaded and then rejected by the queue, leaving an orphaned library row behind.
 - **An archive that arrives with only a name now says what to do about it (#2843, reporter @gyrene2083)** — The no-3MF banner and the connection diagnostic both explained why a print archived with nothing but a name and offered nothing to do about it, and the explanation was wrong in the way that mattered most: both blamed the printer's firmware and said no setting changes it, which reads as "your machine is broken and nothing will help". Measured on hardware: same Bambu Studio, same model, three printers a minute apart, all reporting the external-storage option as on — the H2C and H2D went to internal storage and archived with a name only, the X1C went to the card and archived in full. The same H2C and H2D sliced in OrcaSlicer put the file on the card and archived in full, and turning the option off changed nothing, because OrcaSlicer always uploads over FTPS. So the destination is the slicer's choice, not the printer's, and the option governs neither slicer on this generation. Both strings now name Bambu Studio rather than the firmware and lead with the two routes that take one step — start the print from Bambuddy, or slice in OrcaSlicer — with Send-with-External followed by a separate print start offered as the way to stay in Bambu Studio. Both also mention that a card or stick is still needed, since with an empty slot OrcaSlicer refuses to send at all. Translated in all thirteen locales, and the README callout and this entry now link the upstream issue, bambulab/BambuStudio#10481, so the behaviour can be followed where it is tracked.
 
+### Changed
+- **The Watchtower we recommend for daily builds is the maintained fork (#2917, reported by @CamelT0E)** — The daily-build instructions in the README, on Docker Hub and in every daily prerelease pointed at containrrr.dev/watchtower. That project has been archived and read-only since December 2025 and its last release, v1.7.1, is from November 2023, so anyone following the recommendation was being handed a container with Docker socket access that had not received a fix in over two years. Development continues in Nicholas Fedor's fork, which ships as `nickfedor/watchtower` and released v1.21.0 this month. All four references now point at watchtower.nickfedor.com and name the image, including the release-notes template in `docker-publish-daily-beta.sh` that produced the screenshot in the report — the READMEs alone would have left every future daily prerelease repeating the dead link. Existing images keep working; only the recommendation changed.
+
 ### Fixed
 - **The archives API never reported which plate was printed (#2796, contributed by @sgiffhorn)** — `archive_to_response()` builds the archives response field by field and had no line for `plate_id`, so `GET /archives/`, the detail endpoint, search, PATCH and the project archive list all answered `plate_id: null` — for archives whose column was populated as well. `ArchiveResponse.plate_id` defaults to `None`, so Pydantic filled the null in without complaint and nothing ever raised. The column has been written since #2603 and is backfilled from the queue on startup, so the plate was recorded all along and simply could not be read back out; on the reporting instance 181 of 257 rows carry one. Archive cards now name the plate again — but only when it is not the first one. The queue records a plate for single-plate files too, because the print dialog auto-selects the only plate there is, so labelling every archive that has a `plate_id` would have put "Plate 1" on most cards in the grid and taken room from the truncated print name. A multi-plate archive printed from its first plate still identifies itself through the plate carousel, which has always gated on whether the source 3MF holds more than one plate.
 - **The first AMS sync after enabling Spoolman from Settings failed on every slot (#2903, diagnosed by @ojimpo)** — Spoolman rejects a spool whose `extra` dict carries a key it has not been told about, answering HTTP 400 `Unknown extra field tag.`. Bambuddy stores the tray UUID in `extra.tag`, so that key has to be registered before the first spool is created — and registration only ever ran from three hand-maintained lists that fire when the integration is *set up*: the Connect button, application startup, and two inline blocks in the inventory routes. Enabling Spoolman from the Settings page reaches none of them, so "Sync AMS Data" reported `Synced 0 spools with 3 errors` with vendor and filament creation succeeding and only spool creation rejected. Restarting Bambuddy cleared it, which made the failure look like a connectivity problem. The Connect button would also have fixed it, but it is not on screen by then: saving the settings initialises the Spoolman client as a side effect of syncing locations, the status endpoint reads any live client as "connected", and the UI shows the Connect button only while disconnected — so the one registration path reachable from the interface hides itself exactly when it is needed. Registration now travels with the write instead of the feature: every spool write that carries an `extra` dict registers the keys it is about to send, once per client, before it sends them. That covers all five places Bambuddy writes a tag — AMS sync, linking and unlinking a tag from a spool, and both inventory edit paths — and it closes the class rather than the instance, since a write that carries a key is now a write that registers it. `bambu_color_name` is the cautionary case: it never made it into the Connect or startup lists at all, and worked only because two call sites remembered to register it by hand. Registration stays best-effort — if it fails, the write is still attempted and reports exactly what it reported before, and the failure is not cached, so a Spoolman that was merely restarting is retried on the next write.

DOCKERHUB.md

@@ -97,7 +97,7 @@ Beta builds with the latest fixes are pushed regularly to the same beta version
 docker pull maziggy/bambuddy:0.2.2b1
 ```
 
-Use [Watchtower](https://containrrr.dev/watchtower/) to automatically update when new daily builds are pushed.
+Use [Watchtower](https://watchtower.nickfedor.com) (image `nickfedor/watchtower`) to automatically update when new daily builds are pushed.
 
 > **Note:** Beta builds use version tags like `0.2.2b1` — they are never tagged as `latest`. Your stable installation won't auto-update to a beta unless you explicitly pull a beta tag.
 

README.md

@@ -601,7 +601,7 @@ docker pull ghcr.io/maziggy/bambuddy:0.2.2b1
 docker pull maziggy/bambuddy:0.2.2b1
 ```
 
-Use [Watchtower](https://containrrr.dev/watchtower/) to automatically update when new daily builds are pushed.
+Use [Watchtower](https://watchtower.nickfedor.com) (image `nickfedor/watchtower`) to automatically update when new daily builds are pushed.
 
 > **Note:** Beta builds use version tags like `0.2.2b1` — they are never tagged as `latest`. Your stable installation won't auto-update to a beta unless you explicitly pull a beta tag.
 

docker-publish-daily-beta.sh

@@ -15,7 +15,8 @@
 # Builds and pushes a multi-arch Docker image tagged as 'daily'. Each push overwrites the
 # previous 'daily' image. A GitHub prerelease is created with a date-stamped tag for history.
 #
-# Users can stay up to date by pulling the 'daily' tag or using Watchtower:
+# Users can stay up to date by pulling the 'daily' tag or using Watchtower
+# (https://watchtower.nickfedor.com, image 'nickfedor/watchtower'):
 #   docker pull ghcr.io/maziggy/bambuddy:daily
 #
 # Prerequisites:
@@ -340,7 +341,7 @@ docker pull maziggy/bambuddy:daily"
 > ${PULL_COMMANDS}
 > \`\`\`
 >
-> **Tip:** Use [Watchtower](https://containrrr.dev/watchtower/) to automatically update when new daily builds are pushed.
+> **Tip:** Use [Watchtower](https://watchtower.nickfedor.com) (image \`nickfedor/watchtower\`) to automatically update when new daily builds are pushed.
 
 ---