Upload workflow

upbrr separates source preparation, tracker decisions, media work, payload review, submission, and post-upload effects. Each stage consumes the exact prepared state approved by earlier stages.

1. Select the source

Provide a release folder or file. upbrr resolves the source layout, finds reusable torrent-client data when enabled, and creates a prepared release generation.

One input can be active per database, shared by the Web UI and CLI. Tabs in the same browser session resume that input. Another session or process receives a busy result while it is owned. Close the active input before handing it to another session. Closing retains history and reusable images.

Switching during local preparation cancels that work and waits for cleanup. While an input remains active, a submission or uncertain remote outcome must finish or be reconciled before switching that input. CLI queue continuation follows the recovery rules below after releasing the idle input. Closing a browser tab does not release the input.

Use Cancel active work above any workflow page to stop its current operation and further automatic continuation. The control stays in place and is disabled when idle. Cancelling… remains visible until the backend confirms a terminal result. Torrent hashing and reusable-torrent verification stop during processing and wait for their workers to finish cleanup. A file read blocked by the operating system must return before cancellation can finish. A page reload resumes confirmation for the exact saved operation. If confirmation fails, review the active work or retry cancellation before starting another attempt.

Cancellation keeps the selected input, retained results and completed work available for review or an explicit retry. Work that finishes before cancellation retains its result. Cancellation does not undo an image upload, tracker submission or client action; check any retained recovery actions for uncertain remote outcomes.

If Legacy workflow recovery lists an unresolved external effect, inspect the remote result, then choose Confirmed not completed; allow a fresh exact attempt only when that outcome is known. Recovery never repeats a submission automatically. The Web UI continues to list every retained workflow that needs recovery. For unknown tracker submissions with durable submission protection, CLI queues attach reconciliation to the affected source and continue independent items after releasing the previous input. Unresolved client-injection and image-hosting effects, and legacy submissions without that protection, still block new inputs until reconciled. A retained workflow without a reliable source still requires manual recovery.

Every explicit open, history restore, or refresh checks the source path and inventory and hashes at most the first 1 MiB of each file. File sizes and modification times are checked before and after sampling. This is a lightweight identity check, not verification of every source byte. Torrent creation still performs its required piece hashing. A plain page reload reads the current state without starting another verification.

A fresh application start leaves Input empty, including when the previous input had retained HDR analysis or an unfinished upload workflow. History, saved corrections, reusable artifacts, and completed operation checkpoints remain available. Open the source explicitly to continue; startup does not inspect the previous source or automatically resume its processing. Reloading a browser page in the same running application retains the current session.

Once prior-process input and work leases expire, startup interrupts unfinished operations and retains uncertain external outcomes for reconciliation. An interrupted operation does not establish whether the remote action completed and does not authorize a duplicate attempt. Check the tracker and torrent client before resolving an uncertain upload or injection. Confirmed successful submissions remain recorded. Changed configuration remains blocked until uncertain effects are reconciled. See restart recovery.

Folder handling matters. --keep-folder preserves a supplied folder instead of processing only a selected video file.

Multi-disc DVD and Blu-ray folders

Select the collection parent when every disc belongs to one release. Supported collections contain extracted folders of one disc format:

Example DVD Collection/
├── Disc 1/VIDEO_TS/...
└── Disc 2/VIDEO_TS/...

Example BDMV Collection/
├── Disc 1/BDMV/...
└── Disc 2/BDMV/...

upbrr prepares one release and creates one torrent rooted at the selected collection, preserving every disc folder. For BDMV, select at least one playlist for every disc. Duplicate playlist names such as 00001.MPLS remain separate because upbrr tracks their disc identity.

2. Review canonical metadata

Metadata preparation reports the active substep within its parent stage, including provider lookups, client discovery, media inspection, and Blu-ray.com catalogue discovery and release details. Counts describe processed work; an unknown total remains indeterminate. Elapsed updates indicate waiting without claiming more completed work. Reused evidence is identified as retained, and optional metadata failures remain visible as partial outcomes.

The Web UI and TUI update their existing progress display in place. Plain CLI output keeps fast preparation with no unavailable metadata quiet and emits at most one intermediate metadata line every 30 seconds, deduplicating unchanged updates, plus a terminal outcome when intermediate output was needed. Partial metadata outcomes are also reported when preparation finishes. Redirected output follows the same bound and uses ordinary lines. Detailed per-request diagnostics remain at TRACE.

Metadata providers and local media inspection produce shared release facts. Review at least:

• title and year;
• movie or TV category and independent anime classification;
• release type, source, and resolution;
• season, episode, edition, service, distributor, region, and group;
• external IDs;
• generated release name.

Automatic category detection checks source folders and filenames for TV hints before using the parsed release category, with Movie as the final fallback. Parent folders affect category only; they do not replace the parsed release title. A Season 1 directory is a TV-category hint without supplying a season number; filename season tokens still require two or four digits. Manual season and episode corrections accept plain numbers; see naming fields. Tracker-provided categories take precedence over automatic detection, and an explicit category correction in Input or --category remains authoritative.

Provider searches complete their movie/TV fallback before an unresolved category defaults to Movie. This final default applies to the prepared release and its generated name across CLI and Web UI, including reused or reloaded preparations. It does not supply missing provider IDs or waive other metadata requirements.

Overrides change the prepared generation. Later operations must use that exact generation rather than silently rebuilding it.

Web UI refresh verifies the source and reuses provider evidence whose lookup inputs still match. When finalized metadata is unchanged, ordinary refresh preserves valid duplicate decisions, including corrections that resolve to the same facts. Refreshing a successfully completed workflow reopens preparation; confirmed uploads remain excluded from resubmission. A correction can still produce a new prepared generation: earlier decisions return only after the backend verifies equivalent finalized facts, compatible tracker projections and current private evidence. Missing or expired evidence, changed metadata, changed tracker policy or incompatible preparation inputs requires fresh review; rebinding does not extend the original evidence lifetime. Staff-token attestations are renewed when evidence is rebound. Explicit fresh-provider preparation also renews the prepared generation and its dependent review, even when the provider returns the same values. It preserves compatible screenshot content and hosted links. Reset requests a new preparation of the source; source or capture changes can make earlier images incompatible. A provider failure is reported rather than presenting old provider data as fresh.

Input readiness evaluates missing release facts and selected tracker metadata before tracker assessment. Correct missing source, type, genre, or languages on Input. A tracker-specific requirement affects that tracker; global missing facts prevent advancement.

For automatic soundtrack comparisons, a single usable TMDB spoken language takes precedence over its original-language field. With multiple spoken languages, the original-language field is definitive when that language appears in the list. For example, Japanese original language with Japanese and English spoken languages establishes a Japanese title. An English-only programme track is classified as a dub; separate Japanese and English programme tracks are original plus dubbed dual audio. Explicit soundtrack-origin corrections remain authoritative.

When multiple spoken languages do not include the recorded original language, the unranked spoken-language set remains available for comparison. List order does not select a primary soundtrack or require separate audio for every listed language. Inspected tracks still establish the release's audio; listed English dialogue does not supply an English track or erase a confirmed dub. Independent subtitle, soundtrack-origin and default-track requirements still apply.

An original-language correction, including an explicit clear, overrides this automatic evidence. Auto restores the preferred provider evidence. When TMDB has no usable spoken-language entries, the existing original-language/provider fallback remains available. The scalar original-language metadata is retained for other uses. A production-language value does not override an established original soundtrack's language. Title-level corrections do not rewrite independently confirmed track origins. Mixed dialogue evidence does not establish which language predominates; an applicable exception can remain uncertain without making the release prohibited.

When a selected tracker's current rules need an unidentified programme audio language, Inspected tracks opens on Input and identifies the affected track. Correct its verified languages once, then prepare Input again. The canonical correction is reused across selected trackers and retained readiness checks; changing the inspected source or track manifest requires a compatible correction. Known multilingual tracks, non-linguistic audio, absent audio, and unknown commentary languages are not treated as the same missing fact. Language answers cannot establish an unknown track role or complete missing inspection evidence.

The interactive CLI and --unattended_confirm (--uac) collect all required track languages and required soundtrack origins in one source review before repreparing. --unattended never prompts: it reports the affected track and --track-languages correction option, without authorizing a blocked upload. Enter verified language names or codes, separated by commas; do not infer English or the title's original language. Soundtrack origin is independent of language identification. In Inspected tracks, choose Original soundtrack, Dubbed soundtrack, or Unresolved only from verified source knowledge. Auto removes that origin correction without changing the track's language correction. A mul tag does not identify the languages, and a language difference alone does not normally prove a dub. English-only programme audio is classified as dubbed when the non-English original language is definitive under the rules above or a verified original-language correction. Ordinary matching-language original tracks need no special title or flag. Commentary is not programme audio. Automatic title-language matches can fill a soundtrack evidence gap. They do not override an established original soundtrack; changing that classification needs verified original-source evidence or a correction based on that knowledge. A verified title-level original-language correction governs title-level restrictions without changing the inspected track's soundtrack-origin flag.

When soundtrack review is needed, the plain CLI and TUI show the source, resource, track title, codec and channels, title original language, and inspected/effective track languages. Missing facts are shown as unknown. The question identifies the affected trackers, explains original, dubbed and unresolved, and shows the separate title-language, track-language and soundtrack-origin correction options. An unresolved answer keeps the affected trackers waiting for evidence; it does not confirm a dub or waive a restriction.

When the title's original language is unknown, the original-language comparison does not require track-language or soundtrack-origin answers and does not block an otherwise eligible upload. Unknown facts remain unknown. Explicit soundtrack evidence still supports applicable audio order and default-track rules. Confirmed dubs still follow the selected tracker's restrictions; a dub-specific rule may need further facts. Review first identifies an unknown confirmed dub, then offers companion soundtrack classification if an original or English soundtrack is still needed. Existing evidence that satisfies the rule removes that request. An uncovered release-name audio marker may require an explicit choice from verified track facts; this does not supply the title's original language. Independent payload and media requirements still apply. Supplying an original language restores the ordinary comparison; clearing it or resetting to an unknown automatic value removes that comparison again.

Language corrections accept complete names or codes, including explicit regions and scripts such as pt-BR and zh-Hant. These variants remain visible; matching uses the base language. Filipino (fil), Tagalog (tgl) and the collective Philippine languages (phi) remain distinct. A collective label does not identify its members. Absent language, undetermined (und), multiple languages (mul), uncoded languages (mis), non-linguistic content (zxx) and custom text are retained separately; unknown values do not establish English or an original soundtrack. Full and Forced subtitle coverage stays separate from language identity. Auto removes a correction; an explicitly empty list clears it. For an ambiguous name, choose the suggestion with its displayed code or enter the intended code directly.

For a previously inspected source, the CLI accepts --track-audio-origin 'TRACK_ID=original' (or dubbed or unresolved). It binds the answer to that track's current manifest; changed sources require review again. --reset-input 'metadata.track_audio_origins:TRACK_ID' restores Auto independently of --track-languages. Unresolved answers do not waive tracker restrictions, and unattended runs still never prompt. English dialogue within one multilingual original soundtrack does not by itself establish an English dub or Dual-Audio.

Generated descriptions retain the corrected audio/subtitle notes without duplicating them on repeated preparation. Custom and final descriptions remain under their existing override rules.

If a composite upload stops because a required global source or type is missing, its operation reports an input failure rather than a completed upload. Edit the missing fields on Input, then retry from the latest workflow state. If another stage stops without a next action, review its retained stop reason before retrying; a stopped operation is not proof of a successful tracker submission.

Each manually selected provider ID is authoritative independently, including when several selections conflict with provider cross-links. upbrr retains successfully fetched metadata for each selection through refresh and restart; the disagreement alone does not block preparation. Unspecified IDs still require the existing inference agreement, except that MAL can be discovered from the selected TMDB resource even when its IMDb or TVDB links disagree with other selections. A manual MAL ID or an explicit MAL clear takes precedence; cleared providers stay cleared. Invalid syntax, failed lookups and responses for the wrong requested resource remain errors.

Accepted corrections win over history and provider metadata, except provider-owned fields. Auto removes a correction, while an empty list, a zero manual year, or explicit false retains manual authority. Provider failures preserve accepted edits. A changed content identity can require confirmation of saved corrections. An explicit TV category correction permits TVDB lookup even when the filename was parsed as Movie; TV naming year follows usable TVDB naming evidence, including collision qualifiers and automatic omission. Manual year and omission controls apply only while usable TVDB naming data is missing.

When Saved values need review appears on Input, review the affected fields and the source or provider identity changes shown with each saved value. Choose Keep saved value, edit the value where supported, or choose Use automatic value to discard only that field's saved correction. Provider-owned fields remain read-only. Use automatic values for all affected fields resets only the fields listed in that review, preserving other corrections and history. Select Apply and continue to resume preparation; any unresolved fields remain visible. Automatic values are derived during preparation and are not shown as known while the release snapshot is unavailable. If identity evidence changes again, review the refreshed context before confirming again.

You can reload a paused correction review in the same owning browser session. To remove a stored release instead, select it in History and choose Remove from database. The deletion action remains available when its details fail to load; the confirmation still applies.

Video naming follows the effective release type, including your corrections: AVC/HEVC encodes use x264/x265, Blu-ray remuxes retain AVC/HEVC, and WEB-DL releases use H.264/H.265. An explicit release type takes precedence over the filename and source; select Auto to restore automatic type detection. The underlying measured codec remains unchanged. Older cached names are regenerated the next time the release is prepared; existing corrections are retained.

If a provider fails or selects the wrong title, supply a correct ID or clear that provider. Clearing suppresses its ID and metadata for this source, including later reloads. Other providers remain available, but trackers that require the cleared provider may be blocked.

Mixed-season source files

After metadata fetch, the CLI and Web UI input page warn when the source files contain more than one detected season, such as S00 and S01. The warning lists the season numbers and up to five files from seasons other than the selected metadata season, with an omitted count when needed. If that season is unknown or absent from the files, the most represented season is used instead. Nested files use paths relative to the selected source folder.

Review the listed files for unintended specials or episodes. Correct the source selection and fetch metadata again to update or clear the warning. Editing the release title or season does not change the file-derived evidence. The warning does not change tracker restrictions: trackers that reject multi-season packages can still block the release during duplicate checking.

3. Resolve tracker names and eligibility

Each tracker can project its own upload and duplicate-search names from the reviewed source facts. upbrr resolves those names before duplicate checks so the search evidence and eventual payload refer to the same reviewed identity.

Tracker group policies are evaluated separately for each selected tracker and travel with that tracker's reviewed projection. Changing a tracker's group lists invalidates the affected reviewed projection and duplicate decision so they are rebuilt from the new policy. A matching personal-release group supplies the default only while Personal Release is Auto; an explicit Yes or No remains authoritative through upload and restart.

Tracker rules and constructibility checks can mark a lane ready, blocked, skipped, or requiring manual review. A tracker-specific block need not stop other eligible trackers.

The renamed/modified-source check examines the selected media files, not an otherwise unused containing folder. With --keep-folder, it checks both that folder and the selected filenames. A heuristic warning asks one release-wide yes/no question across the selected trackers. Verify file hashes and source provenance before continuing; declining applies to every selected tracker. The answer belongs to the current prepared generation, so preparing changed source facts requires a new decision. Authoritative scene-rename failures remain strict.

For warnings that permit an override, turn on Acknowledge tracker warnings on the tracker's Dupe Check card or answer the CLI prompt. Approval covers the current warnings. Turn the toggle off to withdraw approval. Changed warnings or a new prepared generation require renewed approval. Strict failures cannot be overridden. See tracker warning approval for unattended and debug behavior.

Continuing after an acknowledgement keeps your selected trackers. If their metadata requirements are already covered by the prepared facts, continuation reuses that generation and its current acknowledgement. Missing metadata can require refreshed preparation; if the refreshed facts need another decision, review the new action before continuing.

4. Review duplicate evidence

Duplicate search results are evidence, not an automatic upload decision. Review candidate names, metadata, and tracker warnings. Where approval is required, select an explicit non-empty tracker subset after the duplicate stage.

Some duplicate overrides require a staff-issued token. Confirm that you have the appropriate token for the current upload; without confirmation, upbrr blocks the upload even when automatic duplicate overrides are enabled. Reprojecting upload inputs or refreshing duplicate evidence requires a new confirmation. Check the tracker's current rules for token conditions.

Before searching, upbrr excludes trackers with a confirmed upload of the same verified submitted content. These appear as Already uploaded. Remaining trackers receive compatible retained evidence or fresh duplicate checks; if every selected tracker is excluded, the operation completes successfully without another approval or upload. Changing metadata or a screenshot playlist does not make a full-disc upload new content. A different actual file subset can be different submitted content.

A complete structured group is preferred for group-policy decisions. When a tracker omits that field, only one unambiguous normalized release-name suffix can prove different-group ownership; conflicting, missing, or multi-group text keeps the normal duplicate review.

5. Prepare media and descriptions

Depending on the source and trackers, upbrr can:

• inspect MediaInfo, BDInfo, DVD, or other prepared technical data;
• optionally generate local waveform and spectrogram PNGs from prepared audio tracks;
• select Blu-ray playlists;
• generate screenshots at chosen frames;
• capture compatible DVD menus or import disc-menu images;
• upload selected images to allowed hosts;
• build tracker-specific BBCode descriptions.

Automatic screenshot plans distribute the requested images across all prepared discs, with at least one planned image per disc. Manual frame numbers apply to every disc. Screenshot previews, captures, and DVD menu images remain grouped by disc; DVD menu capture can warn about partial coverage when its collection-wide safety cap or the available menus leave a disc uncovered.

With Collect existing tracker images enabled, validated tracker screenshots can supply the screenshot set and reduce the number of new captures. In the Web UI, eligible existing description images load automatically on Screenshots, with the same selection and deletion controls as new captures. Loading does not capture missing frames; use Generate screenshots when more images are needed. Existing images have unknown capture timestamps and provenance, so their chronological order relative to new captures is unknown. Imported comparison blocks remain in descriptions and are excluded from ordinary screenshot selection.

Where a tracker permits source-description references, an existing image link may remain usable when its format cannot be inspected. upbrr retains this separately from local screenshot files and reports unknown image properties as guidance, not proof of quality or preservation. Reuse requires a current prepared-source receipt and the tracker's normal image-host policy; rejected URLs and older records without that evidence do not qualify. Explicit screenshot requests and other selected trackers' requirements still apply. Review the final description before upload.

Some trackers accept the full description and screenshots in separate upload fields. Their generated description omits the ordinary screenshot gallery and its configured header, while keeping release notes and other supported content. Use Descriptions to review and save the tracker-ready text before upload.

Automatic tonemapping notices are not available for every tracker. Existing tonemapping notes remain in the description; review them for accuracy before upload.

Capturing an additional frame keeps previously generated screenshots, including their selection and order, without adding those images again.

Inspect image ordering, host URLs, technical blocks, headers, and rendered BBCode. Open an image to inspect it at its natural resolution in a nearly full-viewport lightbox. Scroll horizontally or vertically for larger images; Close and Escape remain available while scrolling.

Compatible images retain their selection and order across refresh. In the Web UI, the Screenshots page reloads its saved-image suggestions when preparation or tracker assessment changes, while keeping edited frame times. Deleted images stay removed. upbrr verifies local image bytes before reuse and reuses hosted links only for a compatible host account and purpose. A hosted link can remain usable when its local preview is missing. Changed capture settings or stricter tracker requirements can require additional images.

Audio analysis is a separate, optional operation. It streams decoded samples from FFmpeg into Go without writing a full decoded-audio file. Its PNGs are retained for preview and download. When descriptions are generated from a completed analysis, upbrr hosts the graphs for each tracker and adds them with the statistics to the default description.

HDR analysis produces independent HDR10+ and Dolby Vision metadata plots. The CLI and Web UI default to metadata plots plus primary-audio analysis. Optional bounded scene checks produce colour thumbnails around selected metadata boundaries; sampled or full-frame picture checks provide additional brightness and border evidence. Native plots and audio are included by default, while picture-check images require selection. Descriptions keep HDR plots, Audio Plots, and ordinary screenshots separate. Retained metadata supports retries and estimator changes without repeating a complete native scan.

6. Preview immutable tracker operations

Tracker preparation captures an immutable operation. Payload preview and live submission use that captured state rather than regenerating names, rereading mutable prepared input, or uploading images again.

• Description preview prepares only the description.
• Dry run and upload review can prepare a preview but cannot submit it.
• Upload consumes the approved operation once.

An explicit Dry Run injects the prepared torrent into the configured client unless Skip client injection is enabled. It never submits to the tracker. Automatic review before a live upload does not inject the prepared torrent; live uploads wait for the tracker-registered torrent.

Short-lived remote tokens can still be acquired at submission time when required by a tracker.

7. Submit and retain registered torrents

After confirmed tracker success, upbrr records the tracker result and attempts to retain the tracker-registered torrent. Client injection consumes that registered artifact, not the pre-upload torrent, even if an earlier explicit dry run already injected the prepared torrent.

When upbrr reconstructs a registered torrent after success, its comment includes the available destination detail link. Inherited source-tracker comments are removed before upload. A draft without a usable destination link keeps the generic upload comment; upbrr does not invent a public link.

A failure to download or persist the registered torrent does not turn a confirmed remote upload into a failed upload. Review the warning and recover the torrent manually when needed.

Deleting a release from History removes its associated local workflow, effect, and submission records along with generated artifacts. This also removes local repeat-submission protection for that release. It does not undo remote uploads or delete source media. While an unknown outcome is retained, it requires reconciliation and is never treated as confirmed success. Restarting does not clear its retry block; verify and reconcile the remote outcome before another attempt.

Automatically managed reports, screenshots, descriptions, torrent exports and analysis files share the release's tmp/<release>/ folder in the active state directory. Analysis and secondary-file reports may use nested folders. Compatible source evidence is reused; changing the source requires fresh evidence. History deletion includes these nested files and preserves active or shared ownership. See the v0.4.2 upgrade notes for legacy cache removal.

8. Inject into clients

Client injection is enabled by default when configured. Disable it explicitly with CLI --no-seed or the corresponding Web UI upload option.

Workflow client injection is skipped when no enabled client is selected. Tracker preparation remains eligible and a successful tracker submission stays completed; a skipped or empty client selection is not a completed injection.

For a URL-only tracker result, a default watch-folder selection is also skipped when no URL-capable fallback is available. It does not record a successful client delivery. An explicit watch-folder override still reports that it cannot receive a URL-only result.

If an explicit dry run pauses for a tracker preparation decision, answering it automatically continues client injection once preparation is ready. You do not need to choose Run dry run again. Further preparation decisions keep injection pending. Before injecting, upbrr rechecks the captured source manifest; a changed source blocks injection and requires re-preparation. The original Skip client injection choice still applies, and a live-upload review continues to defer injection until tracker registration.

Completed dry-run receipts identify only enabled destinations, so editing a selected disabled client does not repeat delivery. Older receipts that included disabled destinations can permit another client action on a later explicit request after upgrading; watch-folder delivery can repeat. An unresolved attempt still blocks another injection.

Workflow injection into qBittorrent verifies that the torrent's infohash and required announce URLs are present in the client. An existing torrent with the same infohash can still have different trackers; upbrr does not change tracker-merging settings or edit its trackers. Verification requires a local v1 torrent artifact. URL-only artifacts cannot be verified and report an injection failure separately from the successful tracker submission. If an add was sent but verification remains uncertain, inspect and reconcile the client outcome before retrying; upbrr keeps the attempt blocked against another add.

When that exact torrent is already installed with the required trackers, verification reuses it before creating link staging for a new add. Existing client data is retained.

A successful draft can be injected before publication when the tracker integration supplies registered torrent authority. It remains unpublished on the tracker. If that artifact is unavailable or injection fails, the result reports the local failure separately from the completed submission.

Check save path, category, tags, automatic management, staging mode, and source-file access. Hardlink, reflink, and symlink staging have filesystem-specific requirements.

Debug and unattended modes

Mode	Submission	Prompts	Client injection
Normal	allowed after review	allowed	enabled when configured
--debug	suppressed	allowed	enabled unless --no-seed
--unattended	allowed when all required decisions exist	never	enabled when configured
--unattended_confirm	allowed when confirmed	required prompts allowed	enabled when configured

Debug mode is not a non-mutating dry run. It can perform screenshots, image uploads, remote searches, tracker preparation, and later workflow effects. Add --no-seed when testing without client injection.

Tracker questions

Answer tracker-specific questions on Dupe Checking, alongside release-name and duplicate review. Questions appear immediately for selected trackers, including defaults, using the current prepared facts. Before the first duplicate check, loading these questions does not run duplicate searches, remote metadata enrichment, authentication, banned-group checks, or claim checks. Once duplicate results exist, selection changes reconcile those results as described in duplicate evidence. If the current prepared facts are unavailable or insufficient for this review, upbrr asks you to prepare the source instead of fetching metadata in the background.

Questions are omitted when finalized media and current provider metadata establish the required answer. Conflicting or incomplete evidence still requires review. A tracker with an unanswered required field cannot proceed to upload; other eligible trackers can continue.

Questions are also hidden when an independent eligibility or preparation failure prevents the tracker from accepting the release. If an answer can resolve the blocker, the relevant questions remain available, including rejected answers that are already filled in. Review those answers before continuing. An optional multi-select answer can be cleared in the CLI by submitting a blank response; required questions still need an answer.

Each tracker panel starts collapsed and identifies Required answers missing, Required fields filled, or Optional controls. Unapplied changes means a local edit has not reached the assessment; filled fields are not a claim that pending changes have been accepted. Open the summary with a click, Enter, or Space to review the fields. Collapsing preserves your edits. Choose Apply tracker answers to refresh the assessment without uploading. Compatible duplicate results are retained; changed duplicate-search inputs require a new check for the affected tracker. Unapplied changes block dry runs and uploads. Passive warnings require no answer; a separate Acknowledge tracker warnings control appears only for findings that require explicit acknowledgement. Guidance does not certify unknown source history. An acknowledgement permits proceeding past the stated warning; it does not change inspected facts, establish tracker permission, or prove replacement eligibility.

After duplicate checking, adding or deselecting trackers rebuilds the assessment for the selected set. Unchanged trackers retain compatible results; added trackers are checked. Tracker answers and reviewed-name changes affect only their own tracker. If prerequisites interrupt a selection refresh, the next selection change retries reconciliation while retaining compatible sibling evidence. Results retain their original check times and expiry, within the existing 30-minute freshness window. Changed source or prepared input and expired evidence require fresh checks for all selected trackers. Changed reviewed names, configuration or rules can also invalidate affected evidence. Follow the stages requested after applying: retained results never supply tracker approval or renew staff-token confirmation.

Some new-group or channel requirements can only be confirmed during tracker preparation. When preparation reports them, late-only fields appear in a separate Tracker preparation details section on Dupe Checking. Requirements for an existing question update its normal tracker panel. Existing-group uploads do not require new-group-only details. Tracker-local source and encoding notes are answered here; canonical metadata and language corrections remain in Input.

Language assessments

Review blocking reasons and warnings before duplicate checking. CLI and WebUI use the same backend findings. A strict staff-exception or prohibited result cannot be acknowledged away; a Trumpable release requires an explicit tracker-specific acknowledgement of the replacement consequence. Unattended mode never supplies it automatically. Full-disc uploads are excluded from these assessments, while remuxes are included.

Subtitle review

Set regular and hardcoded subtitle languages with the editable language dropdowns in Input. The hardcoded list offers English (Full) and English (Forced); the ordinary list suggests base-language names. Both lists accept custom text. Adding or removing a hardcoded language controls hardcoded handling; there is no separate hardcoded-subtitles toggle. Auto resets the language correction and any retained legacy boolean override.

Review any required subtitle questions under Tracker questions on Dupe Checking, then choose Apply tracker answers. Correct mislabeled media tracks separately on Input; questionnaire answers do not rewrite detected track languages. Consult the tracker's current rules to understand the requested review.

Changing a reviewed answer refreshes dependent tracker work, retaining compatible duplicate evidence as described above. Complete any workflow stages requested afterward. The final payload uses the accepted answers from the exact reviewed projection.

Final review checklist

Before submission, verify:

• release name matches current tracker rules;
• category and type are correct for every tracker;
• movie, TV, disc, remux, encode, WEB, HDTV, pack, season, and episode handling are correct;
• source, resolution, edition, service, distributor, region, language, tag, and group are correct;
• screenshots are valid, ordered, and hosted on allowed hosts;
• description BBCode renders correctly;
• torrent contents, piece settings, and announce behavior are expected;
• client category, tags, save path, and injection target are correct;
• duplicate results, rule warnings, and manual prerequisites have been read.

When any item is uncertain, stop before upload and resolve it manually.

Release annotations and editions

Automatically detected Hybrid describes source composition and is kept separately from the title’s cut or edition. Recognized mastering, extras and packaging annotations from provider edition labels are also kept separately. Their existing displayed wording is retained without treating them as editorial edition IDs; filename-only feature annotations keep their existing naming behavior. Generic restoration or remastering does not imply a 4K source.

Older prepared releases must be prepared again so cached mixed edition values cannot be reused. Explicit manual Edition entries and complete release-name overrides retain their existing behavior.