Race Drain and Graduation

🇬🇧 English · 🇫🇷 Français

Race Drain, Graduation and Seed Obligations

Applies to Hydranos 4.4.

This page is for you if race torrents land on a fast, small disk and you want Hydranos to keep that disk from filling up. By the end you will know when the race drain runs, how it decides between deleting and moving a torrent, how to declare your trackers' seed obligations, and how to read and set the volume cards on the Race tab (marks, quota, TRIM). Terms used here are defined on Concepts and Glossary.

Can the drain delete my files?

Yes, but only in the exact cases below. Apart from actions you run or configure yourself (removing a torrent, a race purge, a workflow action, a share limit), the race drain and the transit sweep are the only parts of Hydranos that delete torrent data.

Who deletes	A torrent's files are deleted only when all of these are true
Race drain	1. The torrent is held by a race-role engine (race, or an extra engine with role race). That is decided when it was added (category mode, or an explicit engine) or by a later engine move or graduation, not by its current category label: Change category › without moving files does not take it off the drain. 2. Its volume has Auto drain on and is at or above its start mark, or you clicked Drain now. 3. Its tracker's seed obligation is met: you declared a Minimum seed for that tracker and the torrent has seeded that long, or you declared 0, or the torrent has no tracker at all.
Transit sweep	The torrent is in a hoard category that is ticked Transit area and is named as Graduate to by at least one category, and its tracker's obligation is declared and met (or it has no tracker).

How to make sure nothing is ever deleted:

• If unsure, file your categories as Hoard. Hoard engines are never drained, and the transit sweep never touches a hoard category you did not tick Transit area. Torrents imported from qBittorrent land in hoard. See Engines: Race and Hoard.
• Do not declare a Minimum seed you do not mean. A tracker with nothing declared is protected: its torrents are moved or left in place, never deleted. Declaring 0 means "delete when needed".
• Turn the drain off if you use race but want no deletion at all: switch Auto drain off on every volume card, set enabled = false in [race_drain] (the shipped config writes true, and new volumes follow it), and do not click Drain now.
• Torrents without a tracker are never protected. Nothing is owed for them, so on a draining race volume they are deleted when picked.
• Files are kept only when another torrent reads the same path. Deleting a torrent's copy deletes its own files unless another loaded torrent (this torrent's copy in another engine included) reads exactly that path. A race grab that the *arr also fetched into a hoard category, with its own payload, loses its race files.

The drain does not know whether Sonarr or Radarr has imported a torrent, and it does not spare torrents that are still downloading. Everything else on this page explains these rules in detail.

The idea

Race torrents fill a fast volume. When a volume passes its start mark, the race drain walks its race torrents, oldest first, and frees space until allocated space (used space plus what downloads still have to write, counted on the torrents' declared sizes) is back down to the lower mark. Each torrent's fate depends on its tracker, never on how full the disk is:

• seed obligation met → the torrent is deleted with its data;
• not met yet, or not declared → the torrent graduates: a graduate job moves it and its data to the hoard category named in its race category's Graduate to (hoard category), where it keeps seeding;
• not met and nowhere to go → the torrent is stuck: it stays, and the Race tab shows a red badge.

A hoard category marked Transit area then deletes what graduated into it once the obligation is paid. Without that flag, a hoard category is a library and keeps graduated torrents for good.

The drain only runs on race-role engines (race, and any extra engine with role race). Hoard engines are never drained. See Engines: Race and Hoard for roles.

stateDiagram-v2
    state "Refused at add" as Refused
    state "Downloading on race" as Downloading
    state "Seeding on race, seed time counts" as SeedRace
    state pick <<choice>>
    state "Stuck on the race volume" as Stuck
    state "graduate job queued" as Queued
    state "graduate job running" as Moving
    state "Back on race as it was, job failed" as Back
    state "In no engine, ROLLBACK FAILED" as Lost
    state "Seeding in the hoard category" as SeedHoard
    state sweep <<choice>>
    state "Deleted with its data" as Deleted

    [*] --> Refused: add_block_enabled and projected space too small
    [*] --> Downloading: added to a race-role engine
    Downloading --> SeedRace: download complete
    Downloading --> pick: picked by the drain
    SeedRace --> pick: picked by the drain
    pick --> Deleted: obligation met
    pick --> Queued: not met or undeclared, usable Graduate to
    pick --> Stuck: not met or undeclared, no usable Graduate to
    Stuck --> pick: next drain pass
    Queued --> Moving: job runner picks it
    Moving --> SeedHoard: files moved, adopted by the hoard engine with its resume record
    Moving --> Back: failure or cancel, files moved back, re-adopted by race
    Back --> pick: next drain pass
    Moving --> Lost: the race engine refuses it back
    SeedHoard --> sweep: transit sweep every 5 minutes
    sweep --> Deleted: Transit area target, obligation declared and met
    sweep --> SeedHoard: otherwise keeps seeding
    Refused --> [*]
    Deleted --> [*]

Loading

Seed obligations

A seed obligation is the number of hours a tracker requires a torrent to be seeded before you may remove it. You declare it per tracker host on the Trackers tab: click Edit on a row (or + Manual host), fill Minimum seed, Save. The Min seed column shows it. It is stored in the config file, in [announce_min_seed_hours] (also editable as a table in Config › Advanced settings (default.toml)), and the drain reads it again on every pass, so a change applies to the next pass without a restart. + Manual host opens the form with Minimum seed blank: nothing declared until you type a number.

[announce_min_seed_hours]
"tracker.example.org" = "72"     # 72 hours; the value is a quoted string
"open.example.org" = "0"         # asks for nothing: the drain may delete

What you declare	Min seed column	What the drain does
nothing (blank field)	-	protected: never deleted, graduated instead (or stuck)
0	0h	obligation met at once: deleted when picked
N hours	Nh	deleted once the torrent has seeded N hours, graduated before that
a torrent with no tracker at all	—	nothing is owed: deleted when picked

How it is matched and counted:

• The host is taken from the torrent's first tracker URL (first tier, first URL): https://tracker.example.org:8443/announce/0123456789abcdef → tracker.example.org. The key must match that host exactly: no subdomain matching, case-sensitive.
• Seeding time counts only while the torrent is complete, seeding and not stopped. It is kept in the engine's resume state (see Architecture) across restarts, and a graduation carries it over.
• Over the API: POST /api/announce/min-seed with {"host":"tracker.example.org","hours":72}; {"host":"tracker.example.org","clear":true} removes the declaration. "hours":0 declares 0. It does not clear the value.

The same declaration gates share limits: a torrent that reaches a share limit is held until its tracker's obligation is declared and met (see Queue, Share and Speed Limits).

Timing and announce behaviour are on Trackers and Announces.

When the drain runs

One drain task runs per race-role engine. It waits 10 seconds after startup, then waits one full check_interval_seconds (60 in the shipped config; 0 or a missing key means 300) before its first pass, and runs every interval after that. With the shipped 60, the first pass comes about 70 seconds after startup. On each pass it looks at every volume that holds that engine's torrents:

• A volume is a filesystem, found from each torrent's save path, or its nearest existing parent folder (st_dev on Linux, volume serial on Windows). You never configure one. A volume appears as soon as a race torrent's save path is on it, even before a byte is written, and is named by its mount point as Hydranos sees it (inside the container, under Docker).
• A volume is drained only if its policy is enabled (Auto drain) and its allocated space is at or above its start mark (high_watermark_pct). Allocated = space used plus what accepted downloads on that volume still have to write. A disk at 60 % with large downloads in flight can trigger the drain.
• With a quota on the volume (see The Race tab volume cards), the percentages are of the quota instead of the disk: total = the quota, used = what this engine's torrents on that volume have written, free = the smaller of (quota − that data) and the disk's real free space. Each race-role engine's drain counts its own torrents' data against the whole quota; the card adds the engines together.
• The drain then frees until allocation is back to the down to mark (low_watermark_pct). It counts the torrents' declared sizes, not measured space. A deletion counts when it happens; a graduation counts when its job is queued, because the copy takes minutes. A torrent that would graduate but already has a move or graduation pending is skipped and not counted. A torrent whose obligation is met is deleted even if a move or graduation is pending for it.
• Only torrents on that volume are candidates, sorted by added time, oldest first. A full SSD never drains a torrent that lives on another disk.

flowchart TD
    A["Every check_interval_seconds, per race-role engine"] --> B["Each volume holding this engine's torrents"]
    B --> C{"Auto drain on for this volume?"}
    C -- no --> Z["Leave the volume alone"]
    C -- yes --> D{"Allocated percent at or above start?"}
    D -- no --> Z
    D -- yes --> E["Next torrent on this volume, oldest added first"]
    N["Drain now on the volume card"] -->|"skips both checks"| E
    E --> F{"Tracker seed obligation met?"}
    F -- "yes: hours served, declared 0, or no tracker" --> G["Delete the torrent and its data"]
    F -- "no, or tracker undeclared" --> H{"Category has Graduate to,<br/>that category has a save path,<br/>and it files under another engine?"}
    H -- yes --> I["Queue a graduate job<br/>(skipped, not counted, if a move<br/>or graduation is already pending)"]
    H -- no --> J["Count it as stuck and leave it"]
    G --> K{"Excess above down to still not covered?"}
    I --> K
    J --> K
    K -- yes --> E
    K -- "no, or no torrent left" --> L["Write a History row if anything<br/>was deleted, graduated or stuck"]
    L --> T{"TRIM after drain on, something deleted<br/>and the disk gave space back?"}
    T -- yes --> TT["TRIM the volume on its own thread"]
    T -- no --> TN["Done until the next pass"]

Loading

Things to know before you rely on it:

• Deleted means deleted. The drain removes the torrent from the engine and from the store, and deletes its files, except a file another loaded torrent reads at the same path. If Sonarr or Radarr hardlinked those files into a library on the same filesystem, the library copy survives, but the race volume gets no space back. The Freed column in History shows what the disk really gave back.
• The drain does not skip torrents that are still downloading. If the oldest torrent on the volume is still downloading, it is handled like the others. There is no grace period for young torrents: keep low_watermark_pct far enough below high_watermark_pct, declare realistic obligations, and see the add refusal below to keep the volume from filling in the first place.
• TRIM after a pass. When TRIM after drain is on for the volume and a pass deleted at least one torrent and the disk gave space back, the volume is trimmed on a thread of its own (see TRIM after drain below). A pass that only graduated does not trim; the space a graduation frees is trimmed by the next pass that deletes.

Graduation

Graduation moves a torrent and its data to the engine of another category, and keeps it seeding. The drain uses it for torrents that must leave the race volume but still owe seeding time.

To make the drain graduate, open Categories, edit the race category and pick a Graduate to (hoard category). The list only offers hoard categories that have a save path. Example: race category tv-race (save path /data/race/tv) graduates to hoard category tv (save path /data/library/tv).

A torrent is stuck (it can be neither deleted nor moved) when it owes seeding time and:

• its race category has no Graduate to, or the torrent has no category;
• the Graduate to category no longer exists or has no save path;
• the Graduate to category has mode race and the torrent is on the engine race (a torrent on another race-role engine is instead queued to graduate onto race). This happens through the API, or when the target category's mode is switched to Race after it was picked. The log names the category, not each torrent.

Stuck torrents stay where they are. The drain retries them on every pass and keeps freeing with the next candidates. Fix the category, or declare the tracker's obligation, and the next pass handles them.

What a graduate job does:

1. It waits its turn on the Jobs tab: one job at a time, oldest first.
2. It captures the torrent's resume record (pieces, edited trackers, uploaded and downloaded counters, seeding time, stopped or started state), then removes the torrent from the race engine, keeping the data. The torrent does not seed while its files move.
3. It moves each file to the target category's save path: a rename on the same filesystem, otherwise a copy and then a delete, with a free-space check. A cancel from the Jobs tab is honoured between two files.
4. The hoard engine adopts the torrent with that resume record (no recheck), and the torrent is filed under the target category. Counters, tracker edits, seeding time and a stopped state carry over.

If anything fails after step 2 (a file that cannot move, the hoard engine refusing it) or the job is cancelled, the job puts the moved files back and the race engine adopts the torrent again as it was. The job's error says which case happened:

Job error ends with	State
rolled back, the torrent is in race as before	back on race, files back in place
back in race, but these files did not move back: …	back on race; the listed files are still at the destination
ROLLBACK FAILED, re-add it by hand at <path>: …	the race engine refused it back: the torrent is in no engine, its data is on disk. Recovery: Jobs, Bulk Actions and Moving Data

(race stands for the source engine's id.) The drain never breaks hardlinks: a file hardlinked elsewhere (for example by an *arr import) that has to be copied to another filesystem makes the job fail, and then roll back. The torrent stays on race, and the next pass picks it again.

The drain checks the destination before it queues a graduation. When a file of the same name already sits there (another torrent's, typically), the torrent stays on race and the drain logs those torrents by category, as a WARN not graduated: files of the same name already sit at the destination…; the job itself checks again and refuses (… already exist …; nothing was moved). A move or a graduation you start yourself is refused with destination_taken in that case (below). Give each race category's Graduate to a save path that no other torrent's files share, or those torrents never graduate.

You can also graduate by hand: Change category + move files › in the context menu (see Jobs, Bulk Actions and Moving Data), or POST /api/torrents/:info_hash/graduate with {"engine":"hoard","category":"tv"} (save_path is taken from the category when you omit it; "allow_breaking_hardlinks": true accepts copying hardlinked files). This route goes through the same checks as a category change that moves files, and answers 409 with a reason and the plan when:

• unsafe_path: the torrent names a file outside its folder;
• shared: another torrent reads the same files;
• destination_taken: N file(s) already exist at the destination (…); moving onto them would overwrite them;
• hardlinks: the move would break hardlinks and allow_breaking_hardlinks is not set;
• space: not enough free space at the target;
• or, without a reason, a move is already queued or running for this torrent (a graduation or a move).

On success it answers {"status":"queued","job":"…","plan":{…}}. 400 for a missing engine, the engine the torrent is already in, an unknown engine, or no save path.

Transit areas

Transit area is a checkbox on hoard categories. A transit area is a waiting room: a torrent arrives there owing seeding time, serves it, and is deleted with its data.

The transit sweep:

• runs on every engine, 90 seconds after startup and then every 5 minutes, with no disk-pressure condition;
• only looks at torrents whose category is ticked Transit area and is named as Graduate to by at least one category (a category that names itself through the API counts; only the UI picker hides it). A ticked category that nothing graduates into is left alone, so a library cannot be wiped by mistake;
• deletes a torrent with its data once its tracker's obligation is declared and met. An undeclared tracker is never paid: such torrents wait until you declare a value;
• deletes a torrent with no tracker on the next sweep (nothing is owed);
• applies to every torrent filed in that category, including ones you added there directly, not only graduated ones.

Leave Transit area off on a library category. The sweep writes no History row. It logs transit: seeding time served, removed.

Refusing adds when space is short

With add_block_enabled = true in [race_drain] (default false, absent from the shipped config), Hydranos refuses a new torrent for a race-role engine when

free space − what accepted downloads on that volume still have to write − reserve_free_gb < the torrent's size.

The volume is the one the torrent's own save path sits on; with a quota on it, free space is the quota's free space (the smaller of what the quota leaves and what the disk has). reserve_free_gb is in GB (10^9 bytes), default 0. The add fails with race disk full: … GB free of disk, … GB already promised to downloads in flight, … GB reserved; this torrent needs … GB (of 2.0 TB quota instead of of disk under a quota). If the volume cannot be read, the add goes through. Hoard engines are never refused. The change applies to the next add, without a restart. How each add route reports the refusal is on Adding Torrents and Existing Data.

The Race tab volume cards

The Race tab shows one card per volume that holds race data, above the torrent list. With no race data yet it says No race volume yet. One appears as soon as a race torrent has data on disk. Two race-role engines on one disk share one card; under a quota their data adds up on it.

Element	What it shows or does
Title	mount point and total size; with a quota, the quota size followed by quota (the disk's own figures in the tooltip: disk: … used of …)
Bar	used space (occupancy); markers at down to and start; N% used · X free · N torrents, or N% of quota used · X free · N torrents under a quota
over its mark	shown when used space is at or above start. The drain itself triggers on allocated space, so it can run while this is not shown
Auto drain	turns the drain on or off for this volume
Quota … GB	on the Auto drain row. The space you are allowed on a shared disk (a seedbox slot). Empty (placeholder whole disk) or 0: the whole disk. Tooltip: On a shared disk (a seedbox slot), the space you are allowed rather than the disk's size. The percentages and the drain then count the data of this engine's torrents against it. Empty: the whole disk.
TRIM after drain	switch, off by default. See TRIM after drain below. On its right, last trim: N s, <time ago>, or the refusal in red
start % / down to %	the two marks; the line that is …, back to … turns them into sizes. down to must be below start; start 1–100
History	the last drain passes on this volume: When, Before, After, Freed, Deleted, Graduated, Stuck
Drain now	one pass on this volume right now, then a summary such as 2 deleted, 1 graduated · 40 GB

Below the cards, a Graduating panel lists every graduation queued or running (all volumes together), with copied / total bytes.

Where a card change is saved. Auto drain, start and down to are saved at once through POST /api/drain/policy into the store (hydra.db, one entry per mount point), not into default.toml. They apply on the next pass. Once you change any of the three on a card, that volume keeps its own three values and stops following [race_drain]. The UI has no "back to default" control. Use the API with "inherit": true, shown below.

Quota and TRIM after drain are saved in the store too, under their own keys (volume_quota:<mount point> in bytes, volume_trim:<mount point>), apart from the three drain settings: setting them does not make the volume stop following [race_drain], and "inherit": true does not clear them. They are not [race_drain] keys and have no field in Config › Advanced settings (default.toml).

Drain now runs even if Auto drain is off and the volume is below start. It still frees only down to down to, and still never deletes a torrent whose obligation is not met.

The red badge on the Race tab counts stuck torrents: for each volume, the stuck count of its latest History row from the last 24 hours. Click it to open the history. It refreshes every 30 seconds. A pass writes a History row only when it deleted, graduated or found stuck torrents. While torrents stay stuck, the drain writes one row per pass.

TRIM after drain

An SSD that is never told which blocks were freed keeps treating deleted races as live data and can slow down sharply. With TRIM after drain on, Hydranos trims the volume at the end of a drain pass that deleted at least one torrent and got disk space back. The TRIM runs on its own thread (named trim), never blocks the drain, and only one runs at a time per volume. Tooltip: Tells the SSD which blocks the drain just freed. An SSD that is never trimmed treats deleted races as live data and can fall to a fraction of its write speed. Needs CAP_SYS_ADMIN; ZFS, network shares and hard disks refuse it.

• Linux only. Hydranos issues FITRIM on the mount point. On Windows and macOS it is refused with TRIM is not available on this system (Windows trims deleted files by itself).
• A success logs volume trimmed after drain (processed_gb, secs). The card shows the duration and when, not the byte count.

A refusal is shown in red on the card and logged as TRIM after drain refused, off for this volume until it is turned on again or the daemon restarts:

Refusal	Cause
not allowed: TRIM needs CAP_SYS_ADMIN (Docker: cap_add SYS_ADMIN)	the process lacks the capability
this filesystem or device does not support TRIM (ZFS: use autotrim)	ZFS, a network share, a hard disk, a device that rejects discards
TRIM is not available on this system	not Linux
TRIM failed: …	any other error

After a refusal, that volume is not trimmed again until you switch TRIM after drain off and on (or send "trim_after_drain": true), or restart Hydranos.

Watching the drain

All routes need the API key. See REST API for authentication.

Route	What it returns or does
GET /api/drain/status	the [race_drain] defaults (default_enabled, default_high_watermark, default_low_watermark, check_interval, add_block_enabled, reserve_free_gb) and volumes[]: id, engines, total, used, free, used_pct, committed, alloc_pct, torrents, quota (bytes or null), basis (quota or disk), disk_total, disk_used, disk_free, enabled, high_watermark, low_watermark, inherited, trim_after_drain, last_trim (at, secs, then bytes or error). total, used, free, used_pct and alloc_pct are the quota's when one is set
GET /api/drain/history	the last 50 passes, all volumes, newest first: timestamp, volume, before_pct, after_pct, deleted, graduated, stuck, freed (bytes, measured)
GET /api/drain/graduations	graduate jobs queued or running: info_hash, name, state, copied, total, pct
POST /api/drain/policy	body {"volume", "enabled", "high_watermark", "low_watermark"} (any subset), or {"volume", "inherit": true}. Also quota_gb (GB = 10^9 bytes, 0 removes the quota; a negative value answers 400 quota_gb is a size in GB, 0 to remove it) and trim_after_drain (true/false), each independent of the three drain settings and of inherit
POST /api/drain/now?volume=<mount>	one pass on that volume. Without volume, every volume at or above its start mark, even with Auto drain off. Answers status (ok, no_drain_needed, no_volume), volumes (mount points touched), deleted, graduated, stuck, freed_bytes. With no_volume, only status and volumes

# State of every race volume
curl -s -H "X-Api-Key: YOUR_API_KEY" http://localhost:8199/api/drain/status

# Give /data/race its own marks: start at 90 %, free down to 75 %
curl -s -X POST -H "X-Api-Key: YOUR_API_KEY" -H "Content-Type: application/json" \
  -d '{"volume":"/data/race","high_watermark":90,"low_watermark":75}' \
  http://localhost:8199/api/drain/policy

# Make it follow [race_drain] again
curl -s -X POST -H "X-Api-Key: YOUR_API_KEY" -H "Content-Type: application/json" \
  -d '{"volume":"/data/race","inherit":true}' \
  http://localhost:8199/api/drain/policy

# Declare a 2 TB quota (a seedbox slot), and TRIM it after each drain
curl -s -X POST -H "X-Api-Key: YOUR_API_KEY" -H "Content-Type: application/json" \
  -d '{"volume":"/data/race","quota_gb":2000,"trim_after_drain":true}' \
  http://localhost:8199/api/drain/policy

# Drain it now
curl -s -X POST -H "X-Api-Key: YOUR_API_KEY" \
  "http://localhost:8199/api/drain/now?volume=%2Fdata%2Frace"

The MCP tool drain (read-only) returns the same status plus the most recent passes under recent_runs (history, default 10; it accepts up to 100, but the history route returns only the 50 most recent passes, all volumes together; older rows stay in the store). See MCP Server (AI clients). The log names every drained or graduated torrent (drained, graduating: still owes seeding time) and every torrent stuck for lack of a Graduate to. Torrents stuck because Graduate to points back at their own engine are summed up per category (graduate_to points back at this engine, so these torrents can never leave the volume). A pass that could not free enough logs race drain could not free enough. The lines race volume over its high watermark, draining and race drain could not free enough carry a basis field (of disk, or of 2.0 TB quota) that says what the percentages are of. TRIM logs are under TRIM after drain above.

Purge and store reconcile

Two other routes take race torrents away; neither is part of the drain.

• Race purge: POST /api/race/torrents/:info_hash/purge (MCP tool purge_race) removes the torrent's copy in the engine named race, with its files, through the same path as a delete: files another loaded torrent reads at the same path are kept, the trackers get stopped, and a copy of the same torrent in another engine is untouched. It answers {"status":"ok"}, 404 torrent not in race when the store has no race row for that hash (a row whose engine no longer holds the torrent answers ok, and the row is dropped), or 500 the race engine refused: …. It acts on the engine named race only, not on an extra engine with role race: for one of those, use DELETE /api/torrents/:info_hash?engine=<id>&delete_files=true (see REST API).
• Store reconcile (every 5 minutes) removes store rows of torrents an engine no longer holds, and only that engine's rows: after a restore of hydra.db or of an engine's resume state, a torrent another engine still holds keeps its row there.

Configuration

[race_drain] in default.toml. Values shown are the code default when the key is missing, and what the shipped config writes.

Key	Missing key	Shipped config	Read?	Effect
enabled	false	true	yes, every pass	default Auto drain for volumes without their own policy
check_interval_seconds	0 → 300 s	60	at startup only (restart needed)	time between passes
high_watermark_pct	0	95	yes, every pass	default start mark (allocated %)
low_watermark_pct	0	85	yes, every pass	default down to mark
add_block_enabled	false	absent	yes, every add	refuse race adds that do not fit
reserve_free_gb	0	absent	yes, every add	space kept free by the add refusal (10^9 bytes)

"Every pass" and "every add" apply to changes made through the UI or the API (Config tab, Trackers tab), which update the running config. A hand edit of default.toml is read at the next start, or as soon as any UI or API setting change rewrites the config file, because that reloads the whole file. check_interval_seconds still needs a restart. The per-volume Quota and TRIM after drain are not keys: set them on the volume card or with POST /api/drain/policy (quota_gb, trim_after_drain).

min_age_minutes is no longer in the shipped config. It never did anything (the drain protects a torrent by its tracker's Minimum seed, not by its age); a value left in an older file is ignored, and Hydranos logs at startup config: race_drain.min_age_minutes is ignored: ….

The seed obligations live in [announce_min_seed_hours], described above. Full key reference: Configuration: Engines and Race Drain and Configuration: Daemon, Auth and Global Sections.

See also

• Categories and Routing: how a category picks the engine and folder.
• Jobs, Bulk Actions and Moving Data: the Jobs tab, moves and their failure cases.
• Known Limitations in 4.4.