v3.0.0-rc.3

The first published 3.0 build. 3.0.0-rc.1 and rc.2 were local test builds that were never released; everything in them is in this entry.

Important

Behaviour change: anyone outside your own network now needs a login. Until now the web interface - which can change every setting, including the command run after each pass - answered
any device that could reach its port. From 3.0 it works the way Sonarr and Radarr do: on your own network and on the computer Compressarr runs on nothing changes, you are never asked for a
password; a request from outside is refused until you set a username and password in Settings > Security (the refusal says so). If you reach Compressarr from outside your home - a forwarded port,
a reverse proxy, Home Assistant on another site - set them now. Over Tailscale (or any 100.64.0.0/10 address) tick the box in Settings > Security to count it as local. A request that carries proxy
headers (X-Forwarded-For and similar) always counts as outside, so behind a reverse proxy choose Authentication Required: Enabled. Home Assistant and scripts use the API keys, which are
separate from the login (see below). The default for a new install is "Forms" with "Disabled for Local Addresses", the same defaults as Sonarr.

Note

This is 3.0, not 2.2. The work done as 2.2 grew into a new generation: a second encoder, Passthrough, per-lane profiles, posters, Plex editions, a
redesigned History page, and now a new storage format - the run history moves into a database that 2.x cannot read. Nothing of 2.2 was released as a
final version; 2.2.0-rc.1 and 2.2.0-rc.2 stay as the pre-releases they were. 2.1.10 is the last 2.x release: the 2.x line is retired once 3.0 is
released, and 3.0 takes over a 2.1 install's history by itself (it finds the old history file in the Logs folder and imports it).

Changes since 2.2.0-rc.2
only - everything else is in the entries below.

Added

• The stat cards at the top of the History page can be rearranged. Hover a card and drag it by the dots on its top edge (or focus the dots and press the arrow keys) to put the stats in the order you like; the other cards, the period table and "History at a glance" stay where they are. The order is remembered in the browser next to which stats are shown, a stat you add from the Stats menu goes last, and "Reset to defaults" restores the original order as well.
• Sign-in (Settings > Security). Authentication is None, Forms (Login Page) (a sign-in page with Remember me; a sign-in lasts 7 days from when you last used it) or Basic (Browser Popup). Authentication Required is Enabled (everyone, this computer too), Disabled for Local Addresses (the default) or Disabled for Localhost. Local means 127.0.0.1/::1, 10.x, 172.16-31.x, 192.168.x and link-local addresses; the decision is made from the connection's real address and ignores anything a request claims about itself. The account is a username and a password of at least 8 characters, kept as a salted PBKDF2 hash in the state database (not in the settings file, not in the settings export; backups carry it). Five wrong passwords lock an address out for five minutes. Sign out everywhere ends every browser's sign-in, and changing the account from outside your network asks for the current password. Every page sends you to the sign-in page when a sign-in ends and brings you back to where you were, and a Sign out button appears in the toolbar for browsers that signed in.
• Allowed Hosts (Settings > Host). An optional list of the names and addresses Compressarr answers to (for example compressarr, 192.168.0.100); a request for any other name gets a 400 answer, which stops a web page that points its own name at your network address. Empty means any; localhost and 127.0.0.1 always work, so you cannot lock yourself out of the computer. The Web UI card is now Host (Port, Allowed Hosts, Install as app).
• A way back from a forgotten password. From your own network you can simply type a new one in Settings > Security. If you chose "Enabled" and are locked out, the tray menu has Turn off web login... (it puts the setting back to "Disabled for Local Addresses" after you confirm), and starting Compressarr once with COMPRESSARR_RESET_LOGIN=1 does the same for a container or a service. The Troubleshooting page on the wiki walks through it.
• Saved keys, tokens and passwords are never sent back to the browser. A Sonarr, Radarr, TMDb or OMDb key, a notification channel's tokens and webhook addresses (Discord and Slack webhook URLs and the generic Webhook's URL and custom headers are now treated as secrets too), and the web password show as dots once saved. Leave the dots to keep the value, type to replace it, empty the box and Save to remove it. Test buttons use the saved value when the box still shows the dots, whatever address is typed, so a machine that got a new address from DHCP can be tested without retyping its key.
• Export config leaves secrets out (a file you may send to someone for help); tick Include API keys and passwords in Settings > Backup & Restore for a full copy. Importing a file without keys keeps the ones the installation has. Backups are unchanged and complete: they carry the settings, the state database (with the Compressarr API keys and the web login) and the history, so a restore brings every integration back working.
• Automation API keys (the first piece of the Automation API). The Security card on Settings has an Automation API section with two keys, as Sonarr and Radarr show theirs: an API Key (can read everything and act) and a Read-only API Key (for dashboards). Each is shown in full, always, with Copy and Regenerate (the old key stops working at once). Calls go to addresses starting /api/v1 with a key in an X-Api-Key header (or Authorization: Bearer); GET /api/v1/whoami says which key it is and which version answered. There is no anonymous mode, wrong keys are slowed down (five wrong tries lock that address out for a minute), and a Read-only key is refused on anything that acts. The keys work from any address and are separate from the web login; they are kept in the state database (not in the settings file or the settings export) and are included in backups, so a restore brings back the keys your automation already has. The wiki has a new API and Automation reference page listing every call, field and example, and the Home Assistant page is rewritten around the keys.
• Automation API: the read calls. With a key (Read access is enough): GET /api/v1/status (what is running, paused or monitoring, the current file with progress and speed, the queue's size and projected finish, the schedule), /queue (the In Queue list in processing order, filterable by lane and state, paged), /lanes (each lane with what waits in it), /schedule, /runs (the runs, newest first, by period or from/to day, paged), /runs/{id} (one run with its lanes and every file: sizes, time, speed, engine, profile, error code and reason), /stats?period= (the Overview's figures for today, 7 days, 30 days, a year or all time, with the lane, tool and profile breakdowns) and /reports/{id} (the report page). Every field name is fixed by tests, so an update cannot rename one under your automation; new fields may be added. Times carry the server's UTC offset. The control calls (run now, pause, hold the queue, change the schedule) are described next.
• Automation API: control calls, and a hold for Home Assistant. With a Control key: POST /api/v1/hold holds the queue (no new file starts) with an optional reason and end time, and an option to also freeze the file being encoded (otherwise it finishes); DELETE /api/v1/hold releases it. The hold is saved, so a restart during movie night keeps it; it lapses by itself at its end time; placing it again just updates it. It works whether or not the Scheduler is switched on, "Run anyway" does not lift it, and it shows everywhere: GET /api/v1/status and /hold, the Monitor (State: Held, a note with the reason and a Release hold button), the top bar ("Held by automation") and the run log. Also POST /run (run one pass now), /monitoring/start and /stop, /pause and /resume, /schedule/run-anyway, and PATCH /schedule to change the schedule settings (only the fields you send; a schedule that would be invalid is refused and nothing is saved). Every action is written to the run log with the name of the key that asked. A Read key is refused (403) on all of these.
• A film strip, a TV or a camera beside every queued file. The Monitor page now shows what kind of file Compressarr thinks each one is, just left of its name in the queue and in the top right corner of the Current status card while it is being compressed: a TV when the name has a season and episode (S02E07, 2x07), a film strip when it has a (year) like Inception (2010), and a camera for any other video (a home video, a clip, anything that is not a standard film or show). A camera file is still handled like a movie (the lane's movie preset, filed in the lane's Movie folder), so a TV episode with an unusual name that shows a camera is the reason it got the movie preset. The report, the run log and the History archive call such a file "Video" (new runs only; earlier runs keep "Movie"), and History, the notification {movie_count} and the run totals count it with the movies, so movies plus TV still add up to the files. The Automation API reports it too: type ("tv", "movie" or "video") on each /api/v1/queue item and on current in /api/v1/status.
• The run history is now a database, and reports are built when you open them. Every run is recorded in compressarr.history.db (SQLite, in Compressarr's data folder) instead of Compressarr_History.csv: the run, each file in it (name, type, size before and after, time, tool, lane, profile, speed, status, warnings), and running totals per day that are updated in the same step, so the History figures are a few small rows added up instead of the whole history re-read on every page load. A database cannot be left half-written by a crash the way a text file could, and it can grow new fields without breaking anything. The first start of 3.0 moves your history over by itself: every run is imported and checked against the old file (runs, files, sizes, time must add up), the old CSV is kept next to it as Compressarr_History.csv.imported, and reports that were still saved from earlier versions are kept exactly as they were and read for what the old history never recorded (movie / TV split, and which lane, tool and profile handled each file). If anything goes wrong the old file stays in use and nothing is removed.
• No more HTML file per run. The report is built from the stored rows when you open it (from the History page, after a run, or from the link in a notification), so its link never goes dead when old files are cleaned up and a backup carries every report. Settings > Logging & Reports has Also save a copy of each report as a file (off by default) for anyone who wants the files, and the folder setting is now the folder for those copies. The report page can be saved as a file from your browser as before; adding ?download=1 to its address downloads it.
• Export CSV on the History page downloads the whole history in the old CSV layout, for a spreadsheet or a script.
• The History page's Reports card has period buttons, pages, and a place for errors you have not seen. The buttons are the Overview's - All time, Last year, Last 30 days, Last 7 days and Today (the default) - so the list no longer grows without end, and a long period is shown 25 reports to a page with page buttons below and a Rows per page box (25, 50 or 100); the choices are remembered in the browser. Above the list, a red-edged table shows the runs with errors or warnings that you have not looked at yet (the ones the sidebar's History badges count), and opening the page counts as having seen them, which clears the badges. View recent errors, at the right of the card's title bar, shows the latest 50 runs that had an error or a warning, seen or not, in the same place, in case one was missed.
• Backup and restore carry the database (a consistent copy made with SQLite's own backup, correct even while Compressarr is running), so the history, its reports and the run counter travel together. Restoring a backup made by an earlier version imports its CSV the same way.
• COMPRESSARR_DATA_DIR: an environment variable that makes Compressarr use another folder for its settings and history (a portable copy, a container, or a trial run against a copy of your data).
• The History page Overview has stat cards, a period selector and charts. Next to Overview choose All time (the default), Last year, Last 30 days, Last 7 days or Today: the stat cards below follow the choice, and the matching row of the period table is highlighted (click a row to choose it too). The five default cards are Total Runs (for Today its chart shows the last 24 hours as eight three-hour blocks, 12-3 AM, 3-6 AM and so on, with the current block last), Files Compressed (with a movie / TV split bar), Best Month (it becomes Best Week, Best Day or Best Run as the period gets shorter), Time Spent Encoding and Clean Runs (a green / orange / red bar of clean runs, runs with warnings and runs with errors). The new Stats button on the toolbar adds more: Space Saved, Movies vs TV, Average Saved / File, Biggest Run, Active Days and Redirected Files. The choice is remembered in the browser, and the cards always fill their rows evenly. A second group, History at a glance, always shows the whole history: a space-saved ring, space saved per week, and a ribbon of the last 48 runs (green, orange or red, each linking to its report). Runs in which every file failed and nothing was produced are left out of the cards, as they always were from the period totals.
• Compressarr now records a rough average speed (frames per second) for every file it encodes. It is HandBrake's own running average or ffmpeg's last reading, as one combined figure. It shows as an Average speed tile on the report (and as a tooltip on each file's duration), as a new Average Speed card on the History page's Stats menu, and as the Custom notification token {avg_fps}. A file that was passed through, failed or gave no reading has no speed, and a run with none shows nothing (never 0); runs from before this have none.
• The History page now also records which lane handled each file, which tool produced it (HandBrake, ffmpeg or passed through) and which profile. Four new cards on the Stats menu, all off by default: Busiest Lane, HandBrake vs ffmpeg, Passed Through and Most Used Profile. The facts are stored as six new columns at the end of Compressarr_History.csv (older builds ignore them; older runs show as "not recorded" in these cards, never guessed).
• Compressarr now records how many movies and how many TV episodes each run compressed. The History file gets two new columns, MovieCount and TvCount (appended at the end, so older builds ignore them; a run from before this change shows as "not split" rather than as 0). Custom notification messages can use them as {movie_count} and {tv_count}; like {files} they count every file in the run, so the two add up to {files}. None of the built-in message styles use them.
• An {error} token for Custom notification messages. A Custom message template (Notifications > Message Format) can now include {error}: a few words about what went wrong in the run, such as Error 102: File move failure. The same error on several files adds a count (Error 102: File move failure (x3)), and several kinds show the first two and then "(+N more)". A lane that could not run counts too, and a failure with no numbered code reads Error: see the report. When the run had no errors the token is nothing at all, and in a template of several lines the whole line it is on is left out, so Problem: {error} leaves no dangling "Problem:". The built-in styles are unchanged.
• Numbered warnings, and a {warning} token. A file that converted and was filed, but with something to note, now has numbered warnings in their own series, WARN 201 to 205 (errors stay ERROR 101 to 114, so no number means two things): 201 move skipped (the destination already exists and the collision setting is Skip), 202 companion files not moved, 203 Sonarr/Radarr unmonitor failed, 204 source-folder cleanup deferred (rescan not confirmed), 205 source-folder cleanup deferred (the cleanup failed). The HTML report (and so the History page) shows each as a WARN 20x badge with a help bubble, like an error's code, with the specifics (a path, the reason) still beside it. A Custom notification template can use {warning} the same way as {error}, such as Warn 201: Move skipped (already exists); it is nothing, and its line is left out, when the run had no warnings.

Changed

• Keys, tokens and webhook addresses moved out of the settings file. The Sonarr, Radarr, TMDb and OMDb keys and each notification channel's tokens, webhook addresses and custom headers are now kept in the state database (compressarr.state.db), not in compressarr.settings.json, so that file can be shared, attached to a support request or kept in a repository without leaking them. Nothing changes on screen. The first start after upgrading moves what an older settings file holds (and empties it there); restoring a backup made by an earlier version does the same; if the database cannot be written the keys simply stay in the file, so none is ever lost. They are still stored readably (Compressarr has to send them), so this guards against accidental sharing rather than against someone using your account, and backups, which exist to restore the same installation, still carry them.
• Compressarr no longer rewrites your settings file as it works. The values the app itself records - when the last backup finished, the day each digest was last sent (so it goes out once a day), and how far you had viewed on the History page (the sidebar badges) - moved from compressarr.settings.json into the state database, compressarr.state.db. Before, every digest and backup rewrote the settings file (and put those values into every settings export and into support files people shared). The first start moves whatever an older settings file still holds and takes it out of the file; restoring an older backup does the same; importing an export from another computer drops them (its "digest already sent today" must not silence this one). Nothing changes on screen: the Settings page still shows the last backup.
• Settings > Logging & Reports is now two cards, Logs and Reports, and each says what it does. Logs has the log folder, Delete logs after (days) and Keep logs of successful encodes. Reports says that reports are kept in the history database and never expire, and has Open report after run, the new Flag unseen errors from the last (days) and the optional save-a-copy-as-a-file box; its folder and the new Delete saved copies after (days) appear only while that box is ticked. Before, one "Log/report retention" number cleaned logs and saved copies and also set how far back the sidebar badge and the Unseen errors table looked, which looked like it applied to the stored reports too. A blank box for either new setting means "same as Delete logs after", so existing installs behave exactly as before. The red button is now Purge Logs & Report Copies.
• The queue is now a database too. What Compressarr remembers between passes - the queue order, skips, per-file profiles, "land in another lane" choices, failed files that are held, an encoded file waiting for a move to be retried, and converted sources that were kept - moves from compressarr.resume.json into compressarr.state.db (SQLite, next to the history database, kept in a separate file so one cannot take the other down). Each change is a single transaction that writes only the rows it changed, so a crash or power cut leaves the queue as it was, two edits at once cannot overwrite each other, and a damaged file no longer stops every Monitor refresh and pass. The first start imports the old file (and renames it to compressarr.resume.json.imported, never deleting it); if that file or a later database cannot be read it is set aside as .damaged, the log says so, and the queue starts empty (your folders are scanned again). Backup and restore carry the database; restoring an older backup imports its queue file.
• {report_path} in a notification is now the report's web address (this computer's name, the web port and the run's number, such as http://my-pc:1212/api/reports/412), so it opens from a phone on the same network. Before, it was a file path that only meant something on this machine. The Generic Webhook and IFTTT channels still carry it; the other channels still never send it.
• Clear History and Clear All delete the history from the database (reports included) instead of moving a file to the Recycle Bin; a backup is the way back, and the confirmation says so. Purge Logs & Reports still leaves the history alone.
• The starting speed estimate the Monitor shows before a file has finished is now worked out from the files stored for the last few runs, instead of being read out of report HTML files.
• A damaged line in an old history file no longer takes the whole History page down: it is skipped and counted.
• Opening Compressarr now shows a start-up window at once. A small window with the logo, the name, the version and what it is doing ("Getting things ready...", "Starting the web interface...", "Almost ready...") appears first thing and closes just before the Monitor opens, so the few seconds of background start-up no longer look like nothing happened. It is not shown when Windows starts Compressarr at login (the login entry now passes --autostart; an existing entry is updated the first time the installed copy starts). The first CPU reading, which used to make the first Monitor load wait almost a second, is now taken behind the splash.
• Purge Logs & Reports no longer deletes the run history. It is disk cleanup: it permanently deletes every log and every HTML report, and leaves Compressarr_History.csv alone (the History page keeps all its numbers; only the report links stop working). It used to remove the history as well. Clear History and Clear All still delete it. The button's confirmation and help text say so.

Fixed

• The file count of a pass can no longer read "65 of 0". The total was counted once, when the lane was prepared, so a lane that started empty and then received files (imports during a long pass) showed its running count against a total of 0 on the Home Assistant fileIndex/fileTotal fields (the Monitor hid the line). The total now grows to cover the files already started plus the ones still waiting in that lane.
• Smart App Control (Windows 11) no longer blocks Compressarr. Only the main program and the installer were signed, so Smart App Control refused to load the unsigned files next to it (Compressarr.Desktop.dll and the other Compressarr and Avalonia libraries) and Compressarr would not start; it also refused the unsigned uninstaller the installer generates. Every program file in the installer (ours and the bundled third-party ones) and the uninstaller are now signed. The HandBrakeCLI and ffmpeg programs that Compressarr downloads are third-party builds that are not signed; on a PC with Smart App Control a one-time notice about them can appear the first time Compressarr starts after an installation (in testing both ran normally afterwards; the Troubleshooting page on the wiki explains it).

🛡 VirusTotal GitHub Action analysis:

• Compressarr-Setup-3.0.0-rc.3-Full.exe
• Compressarr-Setup-3.0.0-rc.3.exe