0.1.9.0

Warning

Rexarr is in beta. Settings, file layout and the API can still change between releases. Keep backups
(System → Backup) and report what breaks.

Downloads

Platform	File
Windows 10 / 11	win-x64-installer.exe · portable win-x64.zip · 32-bit win-x86-installer.exe / win-x86.zip
macOS 11+	Apple silicon osx-arm64-app.zip · Intel osx-x64-app.zip · terminal osx-arm64.tar.gz / osx-x64.tar.gz
Linux	linux-x64.tar.gz · linux-arm64.tar.gz · linux-arm.tar.gz · Alpine linux-musl-x64.tar.gz / linux-musl-arm64.tar.gz
FreeBSD	freebsd-x64.tar.gz (needs pkg install node22)
Docker	docker pull ghcr.io/moonlightlaboratory/rexarr:0.1.9.0 · docker pull moonlightlaboratory/rexarr:0.1.9.0

Packages include Node.js; Rexarr runs on http://localhost:3939. See the
install guide.
The macOS app is not notarised: the first time, right-click Rexarr.app → Open.

New

• A drive the machine has is listed, whether or not MakeMKV saw it. MakeMKV does not always report one — a USB
  enclosure it calls Unsupported, a drive passed into Docker without its /dev/sg node, or MakeMKV not being
  installed yet — and the Discs page said no optical drive with one sitting in the machine. Rexarr now looks for
  itself and adds what it finds, marked found, with the tray state and the disc label like any other drive.
  On macOS a drive with nothing in it has no device path until a disc goes in, so it is listed as empty and the
  path appears with the disc. Add drive is still there for pinning one to a stable path or naming it.

• The command preview says what the bitrate will be. Video ≈ 9.6 Mbps · source 67 Mbps overall, under the
  command in the profile editor and in the transcode dialog. A CRF is not a number anyone can read a bitrate off,
  and that is the question being asked while one is being chosen.

• RexDB: a disc's episodes, read by somebody rather than guessed. Everything below this line is Rexarr
  working out where a disc starts from arithmetic, and arithmetic is wrong whenever a set is 7 + 7 + 5 + 5
  instead of four equal discs. RexDB is the shared answer:
  somebody reads a disc once and nobody else has to.

  A disc is recognised by a fingerprint — its volume label and the lengths of its titles — which is known
  the moment a scan finishes, so nothing has to be scanned or typed, a label as generic as DISC_1 cannot
  collide, and two regional pressings of the same season stay apart. An exact match is applied and the Discs
  page says the numbers came from RexDB. A structure that is only very close — a drive reading a duration a
  second out — is offered rather than applied, as is anything disputed, and what you set by hand always wins.

  Reading it sends nothing anywhere: one JSON file, cached for a day. Settings → Connections → RexDB
  switches it off or points it at your own copy.

• A disc from the middle of a set is no longer numbered from episode 1. Three things went wrong together on
  an anime set's second disc. Part 2 on the label was ignored — only Disc 2 was read — so Rexarr did not even
  know which disc of the set it had. Numbering then started at episode 1, silently. And a series AniDB recognised
  was always given absolute numbering, although Sonarr may file it as standard: the rip would have been named
  Show - 008 for a library of S02E08, and imported as the wrong episode.

  Part N and PN now read as the disc number; where a later disc starts is carried on from the earlier discs
  of the same set when Rexarr has ripped them, and otherwise assumed from this disc's own episode count — both
  guesses, both said out loud with the number, since a set is often 7 + 7 + 5 + 5 rather than four equal discs
  and nothing on the disc says which; and absolute numbering follows Sonarr's series type, which is what actually decides how the file is
  named and imported. The episode dropdown writes whichever number that choice calls for — it was writing the
  season number into a field the namer and importer read as absolute.

• The distributor on a disc label no longer loses the match. "Anime Limited Sword Art Online 2 P1" matched
  nothing: every word of a label is expected to appear in the title, and the label who pressed the disc is not in
  it. The label is now tried again with its leading words dropped, one at a time, and the log says what was
  ignored (matched "Sword Art Online 2 (ignoring "Anime Limited")"). Dropping words always loses to a match on
  the whole label, and at least two words have to survive, so a prefix cannot reduce a label to something that
  matches anything. No list of distributors to keep up to date.

• Auto transcode can be given a smart profile. It always accepted one — the per-type dropdowns under
  Settings → Automation simply never offered them, so the only way in was to make one the default profile.
  They are listed there now, and the page says why they suit automation: a scan runs unattended on whatever
  turns up, one fixed profile has to be right for all of it, and a smart profile decides per file instead. The
  Default profile (…) label also names a smart default, which it used to leave blank.

• A disc rip is sized with a smart profile too. Picking one on the Discs page left the estimate blank — it
  asked for a profile by id and a smart profile is not one. It is now decided per title, against the streams
  MakeMKV already found, so nothing has to be ripped first; the line says what it settled on, and names both
  where two titles on the same disc settle differently.

• Smart profiles in the transcode dialog, with a size. They could be set as a default and chosen for a disc,
  but not picked for a film or an episode you were about to encode — the one place you are actually choosing a
  profile. They are in that list now, and they carry an estimated size like everything else. Because a smart
  profile has no settings until it has seen a file, the estimate is of what it settles on for the files selected,
  resolved per file, and the dialog says which that is: "For this file it settles on libx265 CRF 18 tune
  animation + copy". Preview command resolves it the same way and shows the branches that fired. Where a
  branch asks what the title is, which is looked up only when the encode runs, the estimate says so rather than
  quietly guessing.

• OMDb, so a smart profile knows what a local file is. A smart profile can decide on genre, year and whether
  a title is a film or a series — but those could only ever come from Radarr and Sonarr, so if it is animation,
  use the animation tune quietly did nothing for a local file, a disc being ripped, or anything queued by hand.
  Settings → Metadata → OMDb, with a free key from omdbapi.com, answers for those. It is asked last, after
  the *arr apps have had their turn, and only when a branch actually wants the answer, so a library that is
  entirely in Radarr and Sonarr never sends it a request; answers are kept for a day, and the job log says what
  it found. Test checks the key against OMDb there and then.

  It also joins disc identification, last in the chain. A TMDB or TVDB search wants something close to the
  catalogue title and OMDb is better at the other end — a short, slightly wrong disc label — and what it hands
  back is the proper title and an IMDb id, which goes straight to Radarr so the match is exact rather than
  another guess. Where neither *arr app knows the title, OMDb's own name and year still go on the rip. The
  same applies to a scanned barcode that only UPCitemdb could answer: the shop's product name becomes a real
  title before anything is added to Radarr or Sonarr.

• Rip farm mode: more machines, one queue. A shelf of Pis with USB drives, a spare desktop with a fast CPU,
  and one Rexarr that holds the library. rexarr-agent --server http://nas:3939 --key <key> on each of them, and
  they take rips and encodes off the same queue.

  An agent is deliberately thin: it has MakeMKV, or FFmpeg, or both, and it runs what the server tells it to
  run. It holds no library, no profiles and no metadata and decides nothing — identifying a disc, resolving a
  profile, naming the file and talking to Radarr and Sonarr all stay on the server. That is the point: a Pi can
  read a disc at full speed although it could never encode one, and the server can hand it a scan without
  teaching it what a disc is.

  Every drive an agent can see appears on the Discs page named after its machine; a disc put in one is
  scanned there, identified here and ripped there. Any agent with FFmpeg takes encodes, the one with the least
  on going first, and only ones whose FFmpeg has the encoder the profile asked for. The job log says which
  machine ran it, and cancelling, the progress bar and the stall timeout work as they always did.

  Agents pull: nothing is pushed to one and nothing listens on it, so a shelf behind a router needs no ports
  forwarded and no certificates. The files never travel either — agent and server share a folder, and where
  they mount it at different paths, that agent's path mappings rewrite every path in every command. An agent
  only ever runs the two programs it was started with; the server is trusted to say encode this, not run
  this. One that stops polling is treated as gone after ninety seconds and its work goes back on the queue.

  New agents wait to be approved, under Settings → Connections → Rip farm, which is also where the switch lives. See
  Rip farm.

• A disc's subtitles, as text. DVDs, Blu-rays and DVB recordings carry their subtitles as pictures, which
  is why an MP4 made from a DVD has none: nothing in FFmpeg turns a picture into words, so there was nothing to
  convert them to. Profiles → Subtitles → Picture subtitles now offers to read them with
  Tesseract — keeping the text instead of the pictures, or both — and what
  comes out is real SRT, searchable and small, muxed into the encode with its language and its forced flag kept
  and named English · OCR.

  Getting the pictures out is the part FFmpeg will do: a bitmap subtitle stream used as a filter input becomes
  a video stream that emits one frame each time the subtitle changes and nothing in between, so with
  -fps_mode passthrough -frame_pts 1 a feature film is a few thousand PNGs named after their own timestamps
  rather than a few hundred thousand sampled ones — and every cue's start and end is read off the stream
  rather than guessed. format=gray,negate turns light-text-on-nothing into the black-on-white Tesseract
  wants, which also makes the frames where a line has cleared come out blank, which is how the end of a cue is
  known. Tesseract then reads the lot in one pass, loading its model once.

  It runs before the encode, because it cannot run inside it, and it is slow — minutes for a feature, written
  into the job log as it goes. How well it reads depends on the disc. A track it cannot read, or a language it
  has no model for, is logged and left as pictures rather than failing the encode, and the System page says
  whether Tesseract is installed and warns when a profile asks for OCR without it. Settings → Tesseract
  is the switch for the whole of Rexarr and holds the path, empty to find it where it usually lives; turned
  off, every profile's choice is ignored and the pictures are copied as they are, which the job log and the
  command preview both say rather than going quiet.

• One track per language, when a disc gives you three. A disc routinely carries the same language more than
  once — DTS-HD MA 5.1 beside Dolby Digital 2.0, or the same mix in two codecs — and until now a profile could
  only keep whichever the file listed first, which on a DVD is as often the stereo track as the good one.
  Tracks per language in a profile's Audio section now offers keep them all, the best, the smallest or
  the first. Best and smallest rank a track exactly as disc ripping already does — codec first (TrueHD,
  DTS-HD MA, LPCM, FLAC, then DTS over Dolby Digital), then channels, then bitrate — so there is one idea of
  "best" whether tracks are dropped at the rip or at the encode, and a commentary track is never the pick either
  way. It is a smart-profile setting too, so a branch can keep everything on a film and cut a series down. The
  old First match only tickbox becomes first where it was on, and nothing else changes.

Fixes

Nothing reported against 0.1.8.0 that is not covered above.

Full changelog: v0.1.8.0...v0.1.9.0

Full Changelog: v0.1.8.0...v0.1.9.0