v1.0.0-rc.22

Weir v1.0.0-rc.22

Date: 2026-10-30

Early days. Weir is early, and it is in active, hard testing. Expect rough edges. If something is wrong or confusing, please report it on GitHub issues.

This release adds an optional way to skip sign-in at home, and recovery codes, so a forgotten password is no longer the end of your setup.

What Changed

• Skip sign-in for devices on your home network (optional, off by default). Turn it on in System › Security, or answer the new question in first-run setup. A device that Weir can tell is on your local network is treated as signed in for that one request, with no password and no session left behind. A device on a public address is never skipped. Changing this choice, your password or your username still asks for your current password, even from a device that skipped sign-in.
• Recovery codes, and "Forgot your username or password?" on the sign-in page. Setup now shows ten single-use recovery codes once and waits until you have saved them (you can copy them or download them as a text file). System › Security shows how many are left and can make a new set, which voids the old one. On the sign-in page, "Forgot your username or password?" takes a code, shows your username and lets you set a new password. Every recovery signs out every browser, leaves your API keys working, writes an entry to Activity and sends a notification to whoever you have set up to be told.

Fixes And Stability

• Docker images always carry Ubuntu's newest security fixes. A cached build step could keep an older package set after Ubuntu had published a fix (libbrotli, CVE-2026-111497). The image build now notices when Ubuntu's archive changes and installs the update again, and the release builds every image from the same package set that was scanned.
• The Windows tray records what its icon says. The tray's log now notes each change of the icon's hover text, such as Starting and Running, which makes a restart easier to follow when diagnosing a problem.
• A first-time setup of the suite settings no longer fails when two requests arrive together. Both could try to create the same row, and one failed with a database error. The second now simply uses the first.
• The rules preview no longer sends the same request twice. The second request could replace a good result with an error. It now skips a request it has already sent and waits for a changed one until the running preview has finished.
• The recovery page stays where it is when Weir says you are not signed in. You are not signed in while you recover, and that answer could send you back to the sign-in page in the middle of using a code. Sign-in, recovery and setup now all stay on their own page.

Upgrade Notes

• Windows: Check now then Download update then Restart and apply in System › About, or install Weir-win-Setup.exe over the top. Before installing, Weir saves a copy of its data.
• Docker: change the image to ghcr.io/ejm-digital/weir:1.0.0-rc.22, then docker compose pull && docker compose up -d.
• After updating, Weir asks you to make and save recovery codes. This happens the first time you sign in, and System › Security keeps reminding you until you have a set. Save them somewhere other than this computer.
• The recover console command is gone. Recovery codes are now the only way back in. Weir no longer reopens setup when the only account is switched off.
• If you lose your password and every recovery code, the only way forward is a fresh install with a new data folder. Nothing else can get you back in, so keep the codes safe.

Docker

• ghcr.io/ejm-digital/weir:1.0.0-rc.22
• Images are published for linux/amd64 and linux/arm64, and run the .NET build of the Weir server.

Full Changelog

v1.0.0-rc.21...v1.0.0-rc.22

v1.0.0-rc.21

Weir v1.0.0-rc.21

Date: 2026-10-28

Early days. Weir is early, and it is in active, hard testing. Expect rough edges. If something is wrong or confusing, please report it on GitHub issues.

This release fixes a hand-off from Deluno that could be lost on a fresh install, and five faults found while the tests were being extended to cover every line of Weir's code. It adds no features. Nothing in it needs anything from you.

Fixed

• A film Deluno hands over while Weir is busy starting up is no longer lost. On a fresh install, Weir could fall behind just as the first films arrived: starting the media tools for the first time, and looking up the system's proxy settings, held the threads Weir answers requests with. Deluno gave up waiting, and Weir recorded the cancelled request as an unexpected failure. Weir now starts its tools and makes its calls to managers without holding those threads, a request whose sender has gone is recorded as just that, and Deluno sends an unanswered hand-off again (Deluno 1.0.0-rc.30.36), which Weir takes in exactly once (#1340).
• Backups shows Overdue when an automatic backup is long overdue, at any time of day. Between midnight and 3am in the chosen time zone, a backup missed for days was shown without the Overdue mark.
• Signing out now ends the session even if you close the page at once. Weir showed the sign-in page straight away, but the request that ends the session could still be unsent, or be cancelled when the page changed. Someone who signed out and then reloaded, reopened Weir or closed the tab could still be signed in. The request is now sent first and survives the page going away.
• A call to a media manager is no longer lost on a connection the manager had already closed. Weir kept connections to Sonarr, Radarr and Deluno open for up to a minute, and a manager or proxy that closes an idle connection sooner reset the next call, which failed with "could not reach". Weir now reuses a connection for 10 seconds at most.
• A library clean whose file check gets an unreadable answer is refused with a reason. A reply from the file check that was not valid JSON could stop the clean with an unexpected error. It is now refused like any other file Weir cannot make sense of.
• Closing the log file can no longer clash with a page that is reading it.

Under The Hood

• Tests. Weir's server code and its command-line tooling are now measured to 100% of lines and branches, and the web app's lines to 100%. Code the tests proved could never run was removed instead of being excluded. Tests listen on the local machine only, so running them no longer raises a firewall prompt, and the browser tests keep more evidence when one fails.
• Releases. The release check keeps the mutation-testing proof of each area while that area is unchanged, and the recordings of Deluno and Weir now name the newest Deluno release (1.0.0-rc.30.35) and pull its image from the organisation's registry.
• Diagnosis. If Weir runs short of threads, it saves one snapshot of what each thread was doing to logs/diagnostics in its data folder (the newest three are kept), so the cause can be found. The snapshot can contain file names and the text of a request being read; it stays in the data folder, which only Weir's account can open, and is not part of a backup.
• Safer merges. A check now stops any change that quietly puts files back to how they were before an earlier change, and a daily check reports any line of the server that the tests reach on some runs but not others.
• Dependencies. Security fixes for packages used only to build and test (undici, zod, qs, and dompurify in the documentation site), and the documentation site no longer installs the image plugin that brought in deepmerge, which has an advisory with no fix yet. None of them ships in Weir.

Upgrade Notes

• Windows: Check now then Download update then Restart and apply in System › About, or install Weir-win-Setup.exe over the top. Before installing, Weir saves a copy of its data.
• Docker: change the image to ghcr.io/ejm-digital/weir:1.0.0-rc.21, then docker compose pull && docker compose up -d.

Docker

• ghcr.io/ejm-digital/weir:1.0.0-rc.21
• Images are published for linux/amd64 and linux/arm64, and run the .NET build of the Weir server.

Full Changelog

v1.0.0-rc.20...v1.0.0-rc.21

v1.0.0-rc.20

Weir v1.0.0-rc.20

Date: 2026-10-22

Early days. Weir is early, and it is in active, hard testing. Expect rough edges. If something is wrong or confusing, please report it on GitHub issues.

This release fixes two faults in the update path and a set of wrong or unclear messages that a much larger round of testing turned up. Nothing in it needs anything from you.

Fixed

Updating:

• A manual update check shows its answer while automatic checking is off. On System › About, Check for updates now shows what it found (a newer version, or that you are up to date) even when Weir is not set to check by itself. Before, the answer was found and then not shown.
• A busy computer no longer makes an update give up on its safety copy. Before installing, the tray asks Weir to save a copy of its data. If the computer was busy and Weir was slow to answer, the update could fail at that step. The tray now waits for Weir to be ready and then carries on.

Wording and small faults:

• Confirmation messages are in plain words. Sign-in, media manager connections, account changes, pause and a few other places said "Invalid or expired CSRF token". They now say "Your confirmation token expired. Refresh the page and try again."
• A file that disappeared while Weir read it no longer shows a folder path. The message now asks you to check that the file is still in the watched folder and try again.
• A manual pass on a workflow with no watched folder says what is missing. It named an internal job instead of the workflow and the setting to fill in.
• Exporting settings with a part missing explains it. The message used to show the name of an internal table.
• A detection window can be saved as it was read. A workflow's detection window came back without a time zone and was then refused when saved, and a window given with an offset such as +02:00 was stored two hours out. Windows now keep the right time.
• Activity reads correctly. A pass that failed could read as done. An import by a manager that did not name itself read "Imported by Your media manager". A clean of one track read "1 tracks would come out". A file Weir had not started because it was busy with it for another connection no longer claims a newer send has the answer.
• A library clean that is refused shows the reason. Instead of a browser error, the page now shows what Weir said. A file whose track details cannot be read no longer stops the clean with a technical error: Activity says Weir could not make sense of the track details.
• A restored time keeps its time. A saved time with an offset other than UTC was shifted by that offset when a backup was restored.
• Session check. An account whose role Weir does not know is now refused when the page asks who is signed in, as it is everywhere else.
• Network paths. A share address with no share name is joined correctly in a hand-off report.
• The tray log is clearer. An update with no version number is no longer called "vunknown". If File Explorer cannot be started for a file, the tray opens the data folder as intended. The icon redraws if a blinking tick finds Weir has started.

Under The Hood

• Tests. Several thousand more tests across the server, the web app and the tray, with coverage floors raised, replies recorded from the metadata service, and mutation testing of the risky core with a score that only goes up.
• CI. Heavy jobs run on main, nightly and before a tag. The Windows file, volume and share checks run on a hosted runner, and the scenario fixes found by the rc.19 clean-machine run are in. Every Weir image is now published under the organisation's name.

Upgrade Notes

• Windows: Check now then Download update then Restart and apply in System › About, or install Weir-win-Setup.exe over the top. Before installing, Weir saves a copy of its data.
• Docker: change the image to ghcr.io/ejm-digital/weir:1.0.0-rc.20, then docker compose pull && docker compose up -d.

Docker

• ghcr.io/ejm-digital/weir:1.0.0-rc.20
• Images are published for linux/amd64 and linux/arm64, and run the .NET build of the Weir server.

Full Changelog

v1.0.0-rc.19...v1.0.0-rc.20

v1.0.0-rc.19

Weir v1.0.0-rc.19

Date: 2026-10-20

Early days. Weir is early, and it is in active, hard testing. Expect rough edges. If something is wrong or confusing, please report it on GitHub issues.

Weir's container image has a new home: ghcr.io/ejm-digital/weir. From this release on, the old name, ghcr.io/jampat000/weir, is no longer updated. If you run Weir with Docker, change image: in your compose file (or your docker run command) to the new name, then run docker compose pull and docker compose up -d. Your settings and data are not touched. Nothing changes for the Windows installer.

The project now lives at github.com/EJM-Digital/Weir, and the documentation is at ejm-digital.github.io/Weir.

This release is the result of a long test-and-fix sweep: every screen, setting and hand-off was checked in a real browser, against real recorded replies from Deluno, Sonarr, Radarr and your download clients, and on real files with the real tools. That found a good many wrong results, and all of them are fixed here. Nothing in this release needs anything from you except the Docker image name above.

New

• Backups can carry your connection secrets, locked with a password you set. Set a backup password on System › Backups and every backup from then on includes the API keys and passwords of your connections and download clients, sealed with it (Argon2id and AES-256-GCM). A restore asks for the password and changes nothing if it is wrong. Until you set one, backups leave the secrets out, as before, and the page says so.
• On Windows, Weir checks for updates only if you say so. Setup asks, and System › About has a switch for it. A new install starts with it off; an install you upgrade keeps checking as it did. With it off, Weir looks for nothing by itself, and Check for updates still works whenever you press it. Docker is unchanged.
• Weir's windows and lists update by themselves in more places. The list of signed-in browsers on the Security tab changes as soon as another browser signs in or out, and a change to Playback devices made in one browser shows in every other open browser without a reload.
• A backup made by hand counts as the last backup. Last backup on System now shows a backup made with Back up now, and says it was made by hand. The schedule stays where it was.
• Clear wording when a start cannot take its port. If another program already holds Weir's port, Weir now says which port is in use and the tray tries again like any other failed start. On Windows nothing else can take a port beside a running Weir any more.
• A notice for a viewer who signs in before setup is finished. A viewer who signs in before the first-run wizard is done now sees a plain note that an administrator needs to finish setting Weir up. They are not sent to the wizard or offered Skip.
• A busy database is explained in its own words. When the database is busy, every screen now shows the sentence Weir gives (what happened and how long to wait) instead of a general "something went wrong".
• Removed settings that did nothing. The search lanes, the "home note" shown after sign-in and the separate Movies and TV hours window never changed anything, so they are gone. Searching stays with your media manager and the weekly schedule is the one place for hours. A database from rc.18 upgrades on its own, and an older client or a restored backup that still sends them is not refused.

Fixed

Who may do what:

• Only an administrator can remove a connection or an alert. Removing is at least as serious as adding, but an operator could remove a media manager connection, unlink its workflows, give up the reports it owed and remove an alert. Now all four need an administrator. On the Connections screens, Add, Edit, the on/off switch, Remove and replacing a secret are greyed out for operators and viewers with a short note saying why. Testing a connection and sending a test alert stay open to operators.
• A person who may not use a route learns nothing about it. Thirty-four write routes answered "422 invalid" to someone not signed in, or a viewer, when the request body was incomplete. They now check who is asking first.
• A connection that workflows still come from is not removed. Removing it used to turn those workflows into ones Weir feeds itself, so Weir would scan their folder and might remove originals a download client was still seeding. Weir now refuses, names the workflows, and asks you to unlink them first.

Files and hand-offs:

• Activity lists every file of the last seven days. A file Weir handled before a scan had seen it was counted under Needs you but missing from the list. The list now goes by when Weir recorded the file.
• A report to Deluno always names a folder Deluno can open. If Deluno did not answer while Weir was writing a hand-off report, the report named Weir's own folder instead. Weir now asks Deluno again, and if it still does not answer, keeps the report until it can name the right place.
• A busy Deluno no longer loses a report. A hand-off report that Deluno answered with "not yet" (a 503, 408, 429 or any 5xx) was forgotten. It is now kept, sent again after a minute, then after longer waits up to an hour, and given up after a week. A refusal that cannot be fixed by waiting is still not sent again, and Activity says so.
• A rejection is reported once. When a download was rejected and the manager had already accepted the report, running the job again reported it a second time.
• A reject asks a busy manager again. A release known to be bad was handed back as good if the manager did not answer once. Weir now asks again, like other short failures, and hands the file back only when the tries run out.
• A file that is back is cleaned at once. Resuming processing, in the app or from the tray, now wakes the idle workers straight away, and so does a held file that has come back.
• A paused Weir changes no file. A paused Weir could still delete a failed download from Activity's Remove dialog and ask a manager to delete a library file for Download again. Both are refused, with the reason, while Weir is paused. Every other way a file can change is now listed and checked against the pause.
• A file's log belongs to its workflow. Two workflows holding the same path showed each other's log entries, and Move to top could raise the wrong workflow's waiting pass. Both now go by workflow and path.
• A cleaned file reads as clean without a rescan. After Weir cleaned a library file, the Library table could go back to "Needs cleaning" until the next scan. A clean that changed a file now asks for a fresh scan.
• A failed publish says what happened in plain words. A failed publish of a cleaned file, an unchanged copy or a file handed back showed the computer's own words and folder paths in Activity, and a failed hand-back copy was not recorded as one. A workflow that allows one attempt no longer reads "1 times".
• Folders Weir makes get the ownership you set on Docker. The folder Weir publishes into and the folders above it now follow WEIR_DIR_MODE_OUTPUT and WEIR_CHOWN_OUTPUT.
• A start-up sweep keeps a kept original that did not match. If a kept original did not match its backup, the next start deleted the backup. It is now left for you, as recorded.
• A scan of a library folder follows the workflow's own settings. A workflow with no file types picked took every file, downloader folders were matched by file name only, and hidden folders were not skipped. It now uses the built-in video types, the downloader folder names and hidden folders, as a watched-folder scan does.
• Sonarr and Radarr answer the scan. Weir sent a download client's id as a number, which Sonarr and Radarr refuse with an error, and asked Sonarr for episode files without a series. Both are corrected against real recordings of Sonarr and Radarr.
• A log download for a film with accents in its name works. A title such as Amelie with an accent used to answer an error. A log that is cut short now says "Showing the newest 500 of 1,234 entries" instead of "Records retained: 500".
• A tool asked to run at normal priority gets it. Weir skipped setting the priority for Normal, so a tool could inherit a lower one from Weir.
• The hardware check no longer says Weir cannot ask FFmpeg when the machine is only busy. The check now runs at normal priority with a time limit set from measurements, and a real timeout says so in plain words.
• A tool's time limit counts only the time Weir could run. A computer that sleeps or is frozen no longer uses up a tool's time.
• Waking from sleep is not a warning. A scan that comes late because the computer was asleep, or a job whose lease ran out while it slept, is now information in the log. Only falling behind while Weir ran is a warning.

Alerts and rules:

• An alert's address never leaves the server whole. The alerts list and the Edit alert form show the address with its secret part hidden. Leaving it alone keeps the saved address, and Replace the address sets a new one. Two alerts can no longer send to the same address.
• Alerts say the right thing. A file that failed for good sent "A file finished" and never "A file failed for good", and a test to a destination that answered with an error said it worked.
• Rule sets do what they say. The subtitle order was saved and never used, "mark as default: third choice" acted as the first, and "other metadata" alone made every file fail its checks.

Screens:

• Settings keep what you typed. The days a cleaned copy waits no longer snap back to the saved value after a failed save. An hours week that you draw and undo no longer counts as unsaved. Leaving Speed, Alerts, Cleanup or the System time zone with unsaved ...

v1.0.0-rc.18

Weir v1.0.0-rc.18

Date: 2026-10-14

Early days. Weir is early, and it is in active, hard testing. Expect rough edges. If something is wrong or confusing, please report it on GitHub issues.

Release candidate 17 passed its full run on a clean machine and was published for Docker, but its Windows release page went up with no files. Releases on this repository are immutable once published, and the old publish step made the release first and attached the files afterwards, so every file was refused. A published release cannot be repaired, so Windows users get the changes of release candidate 17 here. This is the first Windows release since release candidate 13, so it carries everything user-facing from release candidate 17 and from the three release candidates before it: a Windows update that could leave Weir not running, a start-up that watches itself and tries again, a tray that counts its server ready only when that same server says so, how Weir answers a download your media manager sends twice, picking a file back up when it comes back, keeping an imported film from slipping back to "Waiting", a new border on Weir's icon, and no stall on requests on a busy or small machine. Release candidates 14, 15 and 16 were never published. Release candidate 14 was held back because the scenario run on a clean machine found problems in the run itself. Release candidate 15 was held back because that run then found that updating from release candidate 13 could leave Weir not running. Release candidate 16 was held back because that run then found that on a busy machine Weir could freeze for up to 84 seconds on list requests, so a waiting file was judged too early. Everything in all three is here, with the changes for issues #954, #955, #956 and #958, each confirmed on evidence from the clean-machine run.

New since release candidate 17: the release is now published only after every file is attached, a busy database and an unforeseen failure each get a clear answer a media manager can act on, and the tests and shared documents behind them are tightened.

New Since Release Candidate 17

• A release can no longer go up without its files. The release is now made as a draft. Every file is attached to the draft, the draft is checked to hold each one at its size, and only then is it published, in one last step, so the repository's rule against changing a published release can no longer refuse a file. A run that fails part-way leaves a draft, which running it again finishes. A release that is already published is never touched; the run stops and says why, because only a new tag can replace it. Addresses #969.
• A busy database gets an answer a media manager can act on. When a write waits for the database for the whole time Weir allows, for example while a backup tool holds it, Weir now answers 503 with a Retry-After header and the code database_busy, and writes one warning to System › Logs with the route and how long it waited. Before, the same moment surfaced as a plain-text 500 that a media manager could not tell from "Weir is broken". Retry-After is how long the write really waited, from 1 to 60 seconds. The write was not made, so the same request can be sent again after that time. Addresses #964.
• An unforeseen failure answers JSON with a code. A failure Weir did not foresee now answers 500 with a JSON body, a plain detail sentence and the code internal_error, with nothing of the failure in the body. The details and the stack trace are in Weir's log, as before.
• New setting WEIR_SQLITE_BUSY_TIMEOUT_SECONDS. How long a write waits for the database before it answers 503, from 1 to 120 seconds, 30 unless set. It covers Weir's own writers queueing for the database and then any program outside Weir that holds it. Raising it only makes a media manager wait longer for the same answer. It is listed in .env.example.
• The API reference lists both answers. docs-site/docs/api/index.md has a new Errors table, the OpenAPI description and generated types carry the 503, and the operator messaging standard says an error's wording is never what a client reads: it reads the status and code.
• Tests that judge the thread pool no longer share it with every other test. A test of the database write gate asked whether the process's thread pool ran a small job within a second, but every test in the same run uses that one pool, so the probe measured the other tests and failed on a busy runner, as it did on release candidate 17's push. The gate test now runs its writers on a thread of its own, with no pool and no clock. A run on four processors showed one other test starving the pool for 10 seconds by waiting on 24 pool threads at once; the tests that hold many threads at once now run on threads of their own, and five full runs after the change had no stall of 2 seconds or more. A switch for the test run, WEIR_POOL_SAMPLE, records every wait of half a second or more for the pool, and scripts/attribute-pool-stalls.mjs lays those waits beside the tests. This changes nothing in Weir itself.
• Shared documents from Deluno. docs/deluno-weir-contract.md is new: it lists every reply Weir gives Deluno, with its recording and the test that proves it. docs/golden-path.md is updated with the update phase, the keep-seeding group, running a single scenario, the ready checkpoint and the real run times. Both are copies of Deluno's, identical byte for byte.

The request stall

On the clean-machine run of release candidate 16, Weir froze for up to 84 seconds on list requests, and a file that was waiting for its media manager was judged too early. Release candidate 17 fixed the cause that was found, and added a warning that will record the stall if it ever comes back.

• The cause. Release candidate 16 made Weir and its tray look again, up to five times 20 milliseconds apart, at a file that seemed to be damaged or missing. Most of those small files are missing most of the time, for example the update state before the first update step, the update settings and network choice on a fresh install, and a pause request after it is answered. So every read of the update state or settings slept four times on a thread that was also serving requests. Weir's pool of threads starts with one thread per processor and adds another only every half second or so, so on a machine with few processors those sleeping reads used up the threads and unrelated requests had to wait behind them.
• Missing means missing. A name that is not there is now the answer at the first look. Weir and its tray replace these files by renaming a new file over the old one, which leaves the name in place: 43,000 renames against three readers at once never showed a missing name. Only a file that is refused (a virus scanner holding it, or a rename in progress) is looked at again.
• Requests look once. Everything Weir reads while answering a request or running a timer now looks once and keeps the last good reading: the tray's heartbeat, the update state, the reason an update was held back, the update settings and the network choice. A refused file is answered with that last reading, and the next read looks again. Before any reading exists, the safe side is used as before: update settings notify only, and the network choice is this PC only. Only start-up and the tray's watchers, which have nothing else to do, still wait between looks.
• A warning when work waits for a thread. When work waits two seconds or more for a thread, Weir writes a warning to System › Logs with the pool's counts (threads, how many it starts at once, work waiting, processors). It repeats every 30 seconds while the wait lasts and writes a line when it ends. It runs on a thread of its own, so a starved pool cannot silence it. A test also keeps the list of places in Weir that sleep short, so a new one cannot slip in unnoticed.
• Measured before and after. On a 2-processor server with 24 clients asking at once, release candidate 16 answered the update state with a median of 255 ms, the files list took up to 1,012 ms, and the server handled 923 requests in a minute. With this change the update state's median is 5 ms, the files list takes at most 38 ms and the server handles 2,184 requests in a minute, the same as before release candidate 16 made it look again.
• What was not shown. The full 84-second stall seen on the clean machine was not reproduced here. The slowdown above was, and removing its cause brings the measurements back to where they were, but the 84 seconds itself is not proven to have the same cause. If it comes back, the new warning will record it in System › Logs with the pool's counts, and the clean-machine run will show it.

What Changed

• An update can no longer leave Weir not running. On the clean-machine run, updating from release candidate 13 once left Weir started but never answering: it wrote nothing to its log, did not listen on its port and did not exit. The cause was found by measurement. If the server's printed output went into a pipe that was full and that nobody was reading, the server waited on that pipe before it wrote its first log line. Weir's console output no longer waits: it goes through a small queue handled on its own thread, and if nothing reads it, lines are dropped and counted instead of stopping the server. weir.log always keeps every line. A test starts the real server with a full pipe that nobody reads; it failed before this change and passes now. How that server came to have an unread pipe was not found, which is why the start-up watch below is there as well.
• Weir's start-up now watches itself and tries again. The tray starts the server, whether it is the first start, a start after a crash or Restart Weir, and watches how far it gets. The server reports each step: starting, opening the database, saving a copy of your data, updating the da...

v1.0.0-rc.17

Weir v1.0.0-rc.17

Date: 2026-10-14

Early days. Weir is early, and it is in active, hard testing. Expect rough edges. If something is wrong or confusing, please report it on GitHub issues.

This release candidate fixes a Windows update that could leave Weir not running, makes Weir's start-up watch itself and try again when a start goes wrong, and makes the tray count its server ready only when that same server says it is. It also carries everything from the release candidates before it: how Weir answers a download your media manager sends twice, picking a file back up when it comes back, keeping an imported film from slipping back to "Waiting", and a new border on Weir's icon. Release candidates 14, 15 and 16 were never published. Release candidate 14 was held back because the scenario run on a clean machine found problems in the run itself. Release candidate 15 was held back because that run then found that updating from release candidate 13 could leave Weir not running. Release candidate 16 was held back because that run then found that on a busy machine Weir could freeze for up to 84 seconds on list requests, so a waiting file was judged too early. Everything in all three is here, and release candidate 17 is the first published tag to carry the changes for issues #954, #955, #956 and #958, each confirmed on evidence from the clean-machine run.

The request stall

On the clean-machine run of release candidate 16, Weir froze for up to 84 seconds on list requests, and a file that was waiting for its media manager was judged too early. Release candidate 17 fixes the cause that was found, and adds a warning that will record the stall if it ever comes back.

• The cause. Release candidate 16 made Weir and its tray look again, up to five times 20 milliseconds apart, at a file that seemed to be damaged or missing. Most of those small files are missing most of the time, for example the update state before the first update step, the update settings and network choice on a fresh install, and a pause request after it is answered. So every read of the update state or settings slept four times on a thread that was also serving requests. Weir's pool of threads starts with one thread per processor and adds another only every half second or so, so on a machine with few processors those sleeping reads used up the threads and unrelated requests had to wait behind them.
• Missing means missing. A name that is not there is now the answer at the first look. Weir and its tray replace these files by renaming a new file over the old one, which leaves the name in place: 43,000 renames against three readers at once never showed a missing name. Only a file that is refused (a virus scanner holding it, or a rename in progress) is looked at again.
• Requests look once. Everything Weir reads while answering a request or running a timer now looks once and keeps the last good reading: the tray's heartbeat, the update state, the reason an update was held back, the update settings and the network choice. A refused file is answered with that last reading, and the next read looks again. Before any reading exists, the safe side is used as before: update settings notify only, and the network choice is this PC only. Only start-up and the tray's watchers, which have nothing else to do, still wait between looks.
• A warning when work waits for a thread. When work waits two seconds or more for a thread, Weir writes a warning to System › Logs with the pool's counts (threads, how many it starts at once, work waiting, processors). It repeats every 30 seconds while the wait lasts and writes a line when it ends. It runs on a thread of its own, so a starved pool cannot silence it. A test also keeps the list of places in Weir that sleep short, so a new one cannot slip in unnoticed.
• Measured before and after. On a 2-processor server with 24 clients asking at once, release candidate 16 answered the update state with a median of 255 ms, the files list took up to 1,012 ms, and the server handled 923 requests in a minute. With this change the update state's median is 5 ms, the files list takes at most 38 ms and the server handles 2,184 requests in a minute, the same as before release candidate 16 made it look again.
• What was not shown. The full 84-second stall seen on the clean machine was not reproduced here. The slowdown above was, and removing its cause brings the measurements back to where they were, but the 84 seconds itself is not proven to have the same cause. If it comes back, the new warning will record it in System › Logs with the pool's counts, and the clean-machine run will show it.

What Changed

• An update can no longer leave Weir not running. On the clean-machine run, updating from release candidate 13 once left Weir started but never answering: it wrote nothing to its log, did not listen on its port and did not exit. The cause was found by measurement. If the server's printed output went into a pipe that was full and that nobody was reading, the server waited on that pipe before it wrote its first log line. Weir's console output no longer waits: it goes through a small queue handled on its own thread, and if nothing reads it, lines are dropped and counted instead of stopping the server. weir.log always keeps every line. A test starts the real server with a full pipe that nobody reads; it failed before this change and passes now. How that server came to have an unread pipe was not found, which is why the start-up watch below is there as well.
• Weir's start-up now watches itself and tries again. The tray starts the server, whether it is the first start, a start after a crash or Restart Weir, and watches how far it gets. The server reports each step: starting, opening the database, saving a copy of your data, updating the database, getting ready, starting to listen, ready. A start counts as stuck only when the reports stop for longer than that step allows, so a large database that is still working is left alone and a stuck one is not waited on for long. A stuck server is asked to stop and then ended, and only a server the tray itself started is ever touched. The next try does not begin until the old server is confirmed gone; if one cannot be ended, the tray stops there rather than start a second server beside it, and its log names the process to end. Otherwise the start is tried again after a short, growing wait. The details, and the measurements behind the numbers, are in docs/start-supervision.md.
• The tray counts its server ready only when that same server says so. The tray asks Weir's /ready address whether Weir is up, but that address cannot say which Weir answers. If another Weir already held the port, it answered "ready" while the server the tray had just started was about to fail to take the port and exit, and the tray took that answer for its own server's. The tray now accepts a ready answer only after the server it started has reported that it is ready, either on its standard output or in startup-progress.json, in a report that carries that server's own process number. A server that exits instead ends the start as any exit does, and one that never reports is treated like any other silent start.
• A download sent twice gets the right answer. When your media manager sends the same download again, the new send takes over Weir's work and is told the result with the cleaned file; the earlier send is told it was replaced. Notes no longer mix, so a film never reads "imported" and "will not import" at once. Answers go only to the connection that sent the download. Addresses #955, #956.
• A file that comes back is picked up again. A file Weir saw as gone is looked at again as soon as it is back, instead of waiting ten minutes, and its hand-off is answered. Addresses #956.
• An imported film stays imported. A film your media manager imported no longer slips back to "Waiting for your media manager" after its download is cleaned up or handed over again.
• Two connections sharing a download folder. A file Weir is already working on for one connection is not taken for another; that connection is told Weir is busy and sends it again later.
• A new logo border. The Weir app icon, tray icon, browser icon and docs icon now carry a thin teal border set in from the rounded edge, like Deluno's, and the mark is a little smaller so it clears the border. Addresses #958.

What You See When A Start Goes Wrong

• While Weir is retrying, the tray icon shows Starting.
• If Weir has not started after 5 tries within 15 minutes, the tray stops trying. The icon turns red and a notice says "Weir didn't start after 5 tries, so it has stopped trying. The details are in the tray log. Click to try again." Clicking the notice, or choosing Restart Weir, starts over with a fresh set of tries.
• If Weir was running, stopped and could not be brought back, the notice says it stopped and did not start again after that many tries, with the same way back.
• If the port Weir saved last time cannot be read when it starts (another program has the file for a moment), the tray treats that as a failed try like any other: it waits and tries again with the same growing wait, shows Starting, and never asks for a port or saves one meanwhile. After 5 tries it gives up with the same notice, red icon and Restart Weir.
• If Weir was started by something with nobody at the desktop, such as an installer, the tray exits with code 1 and the reason is in the tray log.
• A server that stopped for a reason that trying again cannot change is not tried again: its settings are not valid, it cannot use its database, or it could not save a copy of your data before updating. Its own words are shown, as before.
• If Weir only started on a retry, it works, and System › Logs shows a warning that it needed one.

Where The Logs Are

On Windows, in `C:\ProgramD...

v1.0.0-rc.13

Weir v1.0.0-rc.13

Date: 2026-10-10

Early days. Weir is early, and it is in active, hard testing. Expect rough edges. If something is wrong or confusing, please report it on GitHub issues.

This release candidate lets you check for, download and apply an update from System › About without waiting for the tray, saves a checked copy of Weir's data before every update, and stops a frozen ffmpeg after 10 minutes without progress instead of a flat hour. It also lets a media manager leave files under a workflow's minimum size out of a hand-off.

What Changed

• Update from System › About without waiting for the tray. Addresses #950.
  • System › About › Updates now has Check now, Download update and Restart and apply.
  • Check now makes the tray look for an update at once, and the page shows the result as it happens.
  • Download update works in every update mode, Notify only included, because clicking it is your choice. The page shows "Downloading update..." and then the ready state.
  • Restart and apply restarts Weir, installs the downloaded update, and the page reloads by itself.
  • The next step is the blue button. Each button is only available when it applies.
  • When the tray isn't running (Docker, or the tray was quit), the buttons are greyed out with a plain reason beside them.
  • Download installer and Release notes stay as small links.
• A checked copy of your data before every update. Addresses #951.
  • Before installing an update, the tray asks Weir to save a checked copy of its database, settings and keys in the backups folder. The last 5 copies are kept.
  • If the copy can't be made, for example because there isn't enough free space, the update isn't installed. Weir keeps running the old version and says why on About and in the tray.
  • Weir also takes a copy at start-up when it finds its version has changed. That covers installing Setup over the top and Docker image changes.
  • System › About shows where the copy was saved.
• Minimum file size shared with Deluno.
  • Weir tells Deluno each workflow's minimum file size, so Deluno knows which files Weir will leave alone.
  • When Deluno sends the list of source files to hand off, Weir leaves out files under the minimum. They are never touched and stay where they are for seeding.
  • This needs a Deluno build with Deluno #1199.

Fixes And Stability

Addresses #948.

• A frozen ffmpeg is stopped after 10 minutes with no real progress. It used to run until a flat 1-hour or size-based limit. A big remux on a slow NAS is no longer killed by a flat hour, as long as it keeps moving.
• An ffmpeg that finishes but won't exit is given a minute. If its output checks out after that, the clean counts.
• The same file is no longer processed twice. A database hiccup could make a job lose its claim and be picked up again. That can't happen now.
• The tray waits sensibly.
  • On Quit and on update, the tray gives Weir 45 seconds to stop and shows "Weir - Stopping...", but stays within the installer's time limit.
  • A server that never answers goes red after about a minute. A slow one may take up to 5 minutes.
  • A slow Setup no longer stops Weir coming back.
• A tray test that failed now and then is fixed at the root, so a failed check means something.

Upgrade Notes

• Windows: Check for updates in the tray or System › About, or install Weir-win-Setup.exe over the top. Existing data is kept, and so is your choice about starting Weir when you sign in to Windows.
• Docker: change the image to ghcr.io/jampat000/weir:1.0.0-rc.13, then docker compose pull && docker compose up -d.
• The first update to rc.13 is protected by the copy Weir takes at start-up when the version changes. Later updates are protected by the copy taken before installing.
• Docker's healthcheck start period is now 5 minutes, to leave room for the copy Weir takes at start-up.
• Handing off only the files above a workflow's minimum size needs a Deluno build with Deluno #1199.

Docker

• ghcr.io/jampat000/weir:1.0.0-rc.13
• Images are published for linux/amd64 and linux/arm64, and run the .NET build of the Weir server.

Full Changelog

v1.0.0-rc.12...v1.0.0-rc.13

v1.0.0-rc.12

Weir v1.0.0-rc.12

Date: 2026-10-09

Early days. Weir is early, and it is in active, hard testing. Expect rough edges. If something is wrong or confusing, please report it on GitHub issues.

This release candidate makes the tray's dot show only whether Weir itself is healthy, stops an extra that was left out for being too small from counting as needing you, settles a file that leaves before Weir starts on it, and makes the first-run port window impossible to miss.

What Changed

• The tray's dot shows Weir's health, nothing else. Addresses #944.
  • Green: Weir is running and everything it relies on answers.
  • Amber: Deluno, or a watched, work or output folder, isn't answering. A network drive that hangs counts after about 10 seconds, and only after two misses in a row, so a single slow answer doesn't turn the dot amber.
  • Red: Weir has stopped.
  • The dot blinks while Weir is starting.
  • Pause bars and the update arrow now sit in the opposite corner. If both apply, the pause bars show.
  • The hover text and the menu's status line read "Weir - ..." and say what is wrong, for example "Weir - Deluno isn't answering".
  • Files waiting no longer change the tray at all. They stay on Weir's own screens.
  • Start with Windows is asked once if an older version switched it on without asking. The tick beside it in the menu is now announced by screen readers.
• An extra left out for being under the workflow's minimum size is no longer something you need to act on. Addresses #945.
  • It reads "Skipped" and no longer counts under Needs you or in the Dashboard headline.
  • If the workflow deletes such files, it reads "Removed: under the workflow's minimum size."
  • Other rule skips (maximum size, patterns, date windows) still ask you.
  • No skip is ever shown or counted as cleaned.
• Just finished shows each file's current result. A film that was imported after an earlier failure no longer shows "Couldn't finish". The Dashboard headline and chart agree with it. Addresses #945.
• A file that leaves before Weir starts on it says so at once. Addresses #946.
  • While waiting to settle, while paused or outside workflow hours, the file now reads "... is no longer there" instead of "Waiting...". It is recorded once, not twice.
  • The panel of a file that is gone offers only Remove from list.
  • A file placed directly in the watched folder no longer logs a cleanup warning.
• The first-run port window opens in front. Addresses #947.
  • It stays on top until you answer, and the tray icon shows while it waits, so Weir never sits silently waiting on a question hidden behind other windows.

Fixes And Stability

• A busy PC no longer fails a good clean. Weir now gives ffmpeg up to 60 seconds to close after it has written a file, instead of 5.
• No log lines are lost while old logs are trimmed. A gap introduced in rc.11 is closed.
• Several tests that failed now and then for no real reason are fixed at the root, so a failed check means something.
• Weir's tray standard is a word-for-word copy of Deluno's, so the two apps follow the same rules.

Upgrade Notes

• Windows: Check for updates in the tray or System › About, or install Weir-win-Setup.exe over the top. Existing data is kept, and so is your choice about starting Weir when you sign in to Windows. A fresh install asks once.
• Docker: change the image to ghcr.io/jampat000/weir:1.0.0-rc.12, then docker compose pull && docker compose up -d.
• Two small database changes run on the first start: one adds the kind of file skip, and one adds an index that keeps Activity quick. Neither needs anything from you.

Docker

• ghcr.io/jampat000/weir:1.0.0-rc.12
• Images are published for linux/amd64 and linux/arm64, and run the .NET build of the Weir server.

Full Changelog

v1.0.0-rc.11...v1.0.0-rc.12

v1.0.0-rc.11

Weir v1.0.0-rc.11

Date: 2026-10-09

Early days. Weir is early, and it is in active, hard testing. Expect rough edges. If something is wrong or confusing, please report it on GitHub issues.

This release candidate makes the update check dependable on busy networks, gives the Windows tray the same look and menu as Deluno's, stops Weir slowing down while it processes, and settles three cases that used to leave a file waiting or showing an error.

What Changed

• The update check keeps working when GitHub limits your network. Weir used to say only "Could not check for updates". It now reads GitHub's public release feed, keeps showing the update it already knew about, and says when it will try again. Addresses #935.
• The tray's own updater uses the same feed. Update checks from the tray work again on networks that hit GitHub's limit. Addresses #935.
• The Windows tray matches Deluno's. Addresses #939.
  • The icon shows the state: a corner mark appears only when something differs (starting, paused, needs you, or an update is ready), and no mark means all is well.
  • The hover text gives the status, for example "Weir - Paused".
  • The menu is the one Deluno's tray uses.
  • You can pause and resume processing from the tray.
  • Windows asks once whether Weir should start when you sign in. Nothing is switched on without your answer.
  • Weir no longer opens your browser by itself when it starts. A notice offers to open Weir, and clicking it does.
  • If Weir is already running, starting it again shows a notice, and clicking the notice opens Weir.
• A first visit no longer says "Your session expired". On a fresh install, the first page goes straight to creating your account. The line with your setup code is now logged as ordinary information, not a warning. Addresses #937.
• "Process again" on a file Weir already cleaned now answers. It shows "Skipped: already done" in Activity, instead of doing nothing visible. A file that has changed is still processed. Addresses #936.
• A file deleted while it waits settles quietly. After a short second look and the usual 10-minute wait, Weir records "no longer there" and moves on, with no errors and no failed job. A file Weir can't read is never handed back as unchanged. Deluno is told the file is gone. Addresses #940.
• A finished hand-off no longer waits for ever. When the main film was delivered and only an extra was skipped for being under the size minimum, the hand-off now ends completed. Weir also accepts the media manager's "imported" for it, so the entry settles instead of staying on "Waiting for your media manager". Addresses #941.

Fixes And Stability

• Weir no longer slows to a crawl while it processes files. Logs could show a warning about "thread pool starvation" and pages and live updates went slow. Database writes now queue without holding up other work, and long file copies run on their own threads. Addresses #938.
• Installing Weir quietly over a running Weir starts it again. A silent Setup, which is how Deluno updates Weir, used to leave Weir stopped until someone started it by hand. Weir now starts again by itself, without opening a browser. A Weir that was stopped before stays stopped. Addresses #942.
• Several tests that failed now and then for no real reason are fixed at the root, so a failed check means something.
• Weir's golden-path and tray-standard documents are now word-for-word copies of Deluno's, so the two apps follow the same rules.

Upgrade Notes

• Windows: Check for updates in the tray or System › About, or install Weir-win-Setup.exe over the top. Existing data is kept, and so is your choice about starting Weir when you sign in to Windows. A fresh install asks once.
• Docker: change the image to ghcr.io/jampat000/weir:1.0.0-rc.11, then docker compose pull && docker compose up -d.

Docker

• ghcr.io/jampat000/weir:1.0.0-rc.11
• Images are published for linux/amd64 and linux/arm64, and run the .NET build of the Weir server.

Full Changelog

v1.0.0-rc.10...v1.0.0-rc.11

v1.0.0-rc.8

Weir v1.0.0-rc.8

Date: 2026-10-08

Early days. Weir is early, and it is in active, hard testing. Expect rough edges. If something is wrong or confusing, please report it on GitHub issues.

This release candidate fixes what a clean install alongside Deluno turned up: folders Weir guessed, files it could not read, and messages people could not make sense of.

What Changed

• Weir never guesses a folder. When Deluno doesn't say where a library's downloads arrive, Weir leaves that workflow's watched folder empty and says plainly what to set in Deluno. It no longer points a workflow at a folder every library shares, which stopped Weir's setup from finishing. A workflow that already holds such a folder is put right.
• Setup explains itself. If a download client saves everything to one folder, Weir says to give Movies and TV their own category folders, instead of offering nothing.
• A file Weir can't read is never deleted, and never passed on. Weir looks at it again over about an hour, as it does for a download that is still arriving. If it is still unreadable and hasn't changed, Weir refuses it before writing anything and leaves the original where it is.
• Plain words instead of tool output. Activity, Logs and what Weir tells Deluno now say what went wrong in a sentence, not raw ffmpeg text.
• A later "imported" counts. If Deluno first says it won't import a file and later imports it after all, Weir's record and Activity now say it was imported.
• Linked workflows show only what can happen. On a workflow linked to a media manager, "Delete only the rejected file" is shown as unavailable, because your media manager removes rejected downloads itself.

Fixes And Stability

• Leaving a page while it is loading no longer puts an error in Logs.
• Weir only ever releases its own cleaned copy that a hand-off actually named, even when two answers from a media manager arrive at once.

Upgrade Notes

• Windows: Check for updates in the tray or System › About, or install Weir-win-Setup.exe over the top. Existing data is kept.
• Docker: change the image to ghcr.io/jampat000/weir:1.0.0-rc.8, then docker compose pull && docker compose up -d.

Docker

• ghcr.io/jampat000/weir:1.0.0-rc.8
• Images are published for linux/amd64 and linux/arm64, and run the .NET build of the Weir server.

Full Changelog

v1.0.0-rc.7...v1.0.0-rc.8