0.1.9.1

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.1 · docker pull moonlightlaboratory/rexarr:0.1.9.1

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

Box sets

A four-disc season used to be four unrelated items in the queue that happened to share a name. Now the discs of
one season gather under a parent: Naruto - Season 1 box set, with Disc 1, Disc 2 and the rest inside it.

Each disc reads as what is on it rather than what MakeMKV called it — Disc 2 · E06 to E09 · 4 episodes — and
opens to the episodes themselves, by name, straight from Sonarr: E06 A Dangerous Mission! Journey to the Land of
Waves! rather than title_t03. Every disc keeps its own state (waiting, ripping, remuxing, done) and the set
shows how far through all of them it is.

When a disc is identified as the same series and season as one already in the queue, it offers to join rather
than starting an item of its own — Add this disc to “Naruto - Season 1 box set”? — and its episodes carry on
from where the last disc ended, so Disc 2 begins at E06 when Disc 1 held five. It asks rather than assuming,
because two discs of one season are usually a set but not always, and a disc put in the wrong one would be
numbered from the wrong place. Declining is remembered, and a disc can be taken back out of a set at any time.

A set is only ever its discs: it appears with the second one, goes when they go, and leaves nothing empty behind.
Turn the whole thing off with Group multi-disc sets into box sets in Settings → Disc ripping.

Swapping discs through a set

A box set is a stack of discs and two drives, so the queue now works that way.

Swap appears on a drive the moment its disc has been copied — not when the encode finishes, because
remuxing reads from disk and holding a tray shut for the length of a transcode idles a drive for nothing. One
press ejects the tray and the drive says what to put in next: Waiting for Disc 3 of Naruto - Season 1 box set.
Close the tray and the disc is read and dropped into that slot. While a drive is still reading, its Swap is
greyed out, and the server refuses the same thing rather than trusting the button.

Swap all finished does it for every drive at once, so a whole stack can be pulled and reloaded in one pass.
Each drive is given a different disc to wait for, rather than both asking for disc 3.

The set lists the discs that have not turned up yet — Disc 3 · incoming — so what is missing is visible without
counting. How many discs a set holds is worked out from the season's episode count and what its discs actually
hold (35 episodes at four or five a disc is eight discs), and Discs… sets it by hand when that is wrong.

If the disc that goes in is not the one expected — another series, a disc already ripped, or simply a different
disc of the set — nothing is filed by force. The disc says what it is and offers to go in at its own number, at a
number you pick, or to stay out of the set as its own item. A disc that matches no series at all is a new queue
item exactly as before.

Starting and watching a stack

Rip all starts every disc that has been read and is only waiting for someone to press start, keeping the
titles, episodes and profile already settled on each one. Next to it, Swap All — the same thing for every
drive whose disc has been copied.

A rip's elapsed time is now a running clock rather than a figure that only moved when something else happened on
the page, and it shows against each disc of a set as well as in the disc's own card.

Fixes

• Box set rows line up. The disc rows were a flex row, so a badge on one disc ("guessed") shunted that row's
  episodes, count and status out of step with the rows above it. They are a grid of fixed columns now — each row
  is its own grid container, so a column sized to its own content still drifted from the row above — and every
  row in a set now shares one set of column positions. The disc and its episodes read as a group on the left,
  state and actions on the right, instead of a metre of empty row between them on a wide screen.
• A drive is named like a drive. MakeMKV writes the formats it burns in front of the model and the serial
  behind it — "DVD+R-DL HL-DT-ST DVDRAM GT50N LT20 M1BC6B45752" — which wrapped onto two lines and said little.
  The model is what is shown; the full string is still there on hover.
• An expanded disc is not a card inside a card. Opening a disc in a set showed the whole rip card, header and
  all, repeating the series, the year and the state that the row above it had just said. Inside a set that header
  keeps only what the row does not say — the disc's own label, its drive and its age — and the panel is inset so
  it reads as part of the row it came from. The divider above a disc was also being drawn twice, making it
  heavier than the one above an empty slot.
• An empty progress bar is not shown. A set that has not started drew a full-width grey bar reading 0%, which
  said nothing the "0 of 2 done" beside it had not already said.
• A long disc's episodes run in columns rather than down one tall, thin list.
• One drive is listed once. While MakeMKV works out what it has, it can report a drive twice in one listing:
  an empty slot and, separately, the same model with its disc. The entry naming a device is the real one.
• Discs are opened by their device, not by MakeMKV's drive number — the cause of most "could not open the
  disc" failures. disc:1 means "the second drive in MakeMKV's list", and that list is rebuilt on every call:
  a drive MakeMKV does not manage to enumerate shifts every number after it. A disc noticed in one call was then
  ripped by a number that, in the next, belonged to a different drive — usually an empty one, which fails to open
  in under a second. Where MakeMKV reports a device node, Rexarr now uses it, and a disc whose drive has been
  renumbered since it was noticed is read through the drive it is actually in. Windows reports drive letters and
  keeps using the number, as it always did.
• Drives with nothing in them are no longer missing from the drive list. MakeMKV names a drive's device only
  once a disc is loaded, and Rexarr discarded any drive it listed without one — so a machine whose drives were all
  empty looked like a machine with no optical drive at all, with nothing to select and nothing to insert a disc
  into. An empty drive MakeMKV lists is now shown as the empty drive it is. Rexarr's own detection no longer adds
  a second copy of it either: with no device on either side to compare, the drive's model is matched instead.
• A disc in the second drive is no longer credited to the first. Rexarr's own drive detection read macOS's
  drutil status positionally: every device node in the output, zipped against the list of drives. With one drive
  that is the same thing. With two it is not — a drive holding no disc prints no device line, so the nodes shift
  up, and a disc in the second drive was attributed to the first while the drive the disc was actually in was left
  with no device to open at all. Each device is now read from the block of the drive it belongs to.
• A disc is tried both ways MakeMKV can be told to open a drive. Neither handle is dependable alone: a drive
  number can move between calls, and MakeMKV answers "Unknown device" for a device node it did not enumerate that
  run — which happens to a second drive more than a first. A scan that cannot open a disc now tries the other
  handle before giving up, and remembers the one that worked for the rip that follows.
• A disc that failed to scan no longer fills the page with copies of itself. A failed scan was never marked
  finished, and the drive poll treats an unfinished disc as a newly inserted one — so a disc that would not open
  got another entry every few seconds, for as long as it sat in the drive. It is marked finished now, failed or
  not, and the same disc is left alone until it is swapped.
• One drive is no longer mistaken for two. MakeMKV reports a macOS drive as /dev/rdisk5 where Rexarr's own
  detection finds /dev/disk5; when MakeMKV did not list a drive and Rexarr found it instead, entries made under
  one name did not match the other, and the disc was detected again as new. The two names are compared as the one
  drive they are.
• A disc is read again before being given up on. A disc is noticed as soon as the drive reports a label,
  which can be before the drive has come up to speed — the read then fails to open the disc, though the same disc
  reads perfectly seconds later. A scan that cannot open a disc now waits a moment and tries once more.
• "Failed to open disc" says what actually went wrong. On macOS it always blamed a mounted volume, which sent
  people to Disk Utility for a drive that was merely still spinning up. It now quotes MakeMKV's own reason where
  there is one — a drive reporting NOT READY, or a drive MakeMKV never found — and tells an unreadable disc image
  apart f...

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...

0.1.8.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.8.0 · docker pull moonlightlaboratory/rexarr:0.1.8.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

• Smart profiles: a profile that settles part of itself from the file. A smart profile is a profile — it has
  its own settings and encodes with them. What makes it smart is that some of those settings are decided when
  there is a file to look at, which is the only time the questions worth asking can be answered: whether a disc's
  lossless track is stereo or 7.1, whether its audio carries Atmos or DTS:X, whether what you are encoding is
  animation. It can be chosen anywhere a profile can, so an automatic rip decides per disc and a series per
  episode.

  Every encode starts from the profile's own settings; each branch that fits then changes them, and a later one
  wins where two touch the same thing. There is no fallback branch to write — the settings you start from are
  the fallback. And when nothing would be re-encoded (video copied, audio copied, same container) Rexarr queues
  no encode at all, which is what keeping a TrueHD track actually looks like.

  Two ship as examples. Lossless audio, the right way round copies everything except a lossless stereo
  track, which becomes FLAC — the same samples in less space — leaving surround and object audio alone.
  x265, and animation knows itself is HEVC CRF 20, with animation (by genre, or a series Sonarr calls anime)
  taking the animation tune and CRF 18, and UHD HDR adding 10-bit.

  A branch can ask about 27 things and change 28. Audio: channels, codec, object audio, losslessness,
  languages carried, commentary, track count, bitrate. Video: height, width, codec, HDR, Dolby Vision, bit
  depth, frame rate, interlacing. Subtitles: count, languages, forced, text or bitmap. The source's running
  time, size, bitrate and container. And what Radarr or Sonarr say the title is — kind, genres and year, only
  looked up when a branch actually asks, so one that never mentions them costs no request. What it can change
  covers the whole profile: every video, audio, subtitle and output setting, extra ffmpeg arguments included.
  A branch wants all of its conditions by default or any of them if you say so, can be named, and can be
  switched off without being unwired.
  Object audio is read from the stream profile FFmpeg reports (Dolby TrueHD + Dolby Atmos, DTS-HD MA + DTS:X and the other two); nothing else in a file says so, and an FFmpeg too old to name it never reports
  it, so the condition is then never true. Every decision writes what it saw and what each branch changed into
  the job log.

  It is edited as a graph — the whole window beside the sidebar — starting at Start from, through branches
  whose Then goes to a Set node and whose Carry on continues down, to an If nothing matches node
  showing what a file that fits no branch is encoded with. Nodes drag anywhere and remember where they were
  put; the background pans and the wheel zooms; and holding shift while dragging draws a box that selects
  every node it touches, which then move together.

• CDDB, for the discs MusicBrainz has never heard of. The track listings CD players have used since the
  nineties, under Settings → Metadata → CDDB / freedb, on by default. Rexarr works out the disc's CDDB id and
  asks for its entry — but only when MusicBrainz has nothing for that disc id, so nothing changes for a CD that
  was already recognised. A CDDB entry appears in the release list labelled CDDB and carries artist, album,
  year, genre and the track titles; it has no cover art, and no MusicBrainz ids are written from it, though the
  GENRE and the DISCID rippers have always written are. The server is a setting, and it takes either a plain
  endpoint or the whole URL gnudb.org publishes, handshake and all — paste theirs as it
  stands and the hello in it is used, since gnudb answers only application names it already knows.

• Settings → Experiments, and the first one in it: barcode scanning. Scan the barcode on a disc case with
  your phone — the page shows a QR code that opens Rexarr's scanning page on the phone — and Rexarr works out what
  the disc is, adds it to Radarr / Sonarr if it is not there yet, and keeps it on a list of discs it expects.
  Numbers are looked up at TheDiscDB first – a community catalogue of physical releases, so a hit names the film
  or series outright with its TMDb id – then MusicBrainz and UPCitemdb. None of them needs an account, and
  TheDiscDB has its own switch under Settings → Metadata. Experiments are off by
  default, can change between releases, and each one says where to report it when it misbehaves. A camera needs
  HTTPS, so over plain http the page asks for the number instead.

• A ripping to-do list, the second experiment: the Discs page can show what Radarr and Sonarr would still
  like a better copy of — their cutoff-unmet lists — as Insert disc for…, with what is on disk now and which
  kind of disc would improve it. A 1080p remux is not improved by a Blu-ray, so those appear only when a UHD disc
  would help, and 2160p remuxes are left out. Discs whose barcode you scanned are marked and sorted first.

• Audio only, for files you already have. Audio only beside Transcode on a movie or series page — and a
  tickbox in the transcode dialog everywhere else — copies the video exactly as it is and sends only the audio
  through the encoder, whatever the profile says about video. Turning a TrueHD track into FLAC on a film you
  already own takes minutes instead of hours, and the picture is bit-identical because it is never touched. The
  command preview shows the real command, with -c:v copy in it, and the size estimate is of that command: the
  video part is the stream being carried over, measured rather than predicted, so the figure comes out exact.

Fixes

• Audio CD rips were tagged twice, and the stale half usually won. fre:ac tags a rip from its own lookup
  before Rexarr writes what MusicBrainz said, and FFmpeg keeps TRACKNUMBER, DISCNUMBER and ALBUMARTIST
  under names of its own — so Rexarr's tags landed beside fre:ac's rather than replacing them, and a player
  reading the first of the two showed the wrong track and disc number. The rip now starts from no tags at all.
  While there: ORIGINALDATE / ORIGINALYEAR so a remaster keeps the album's own year (which the folder is now
  named after too, as Lidarr files it), MEDIA from what the disc actually is instead of always CD,
  COMPILATION on a Various Artists disc, sort names, catalogue number, DISCSUBTITLE, and
  MUSICBRAINZ_RELEASETRACKID beside the recording id — Picard's field names throughout.

• A CD could be identified as an album it has nothing to do with. Asking MusicBrainz about a disc id also
  asks it for releases of a similar length, and it answers with those even when it has never seen the disc —
  so a 15-track disc of Daniel O'Donnell's The Last Waltz came up as Kabát's Banditi di Praga, cover art and
  all, ready to rip under that name. Rexarr now tells the two answers apart: a release found by disc id is the
  disc, a release of similar length is a suggestion. Suggestions are listed and labelled similar length only,
  unconfirmed, they are never applied on their own, auto-rip will not start on one, and the disc sits on
  Generic track names until you choose. That disc, with CDDB asked as it now is, comes up as Daniel
  O'Donnell – The Last Waltz with its real track titles.

• A disc from a box set is tagged as that disc. Picking a release by hand from the title search always used
  disc 1's track list, so disc 2 of The Wall came out as "In the Flesh?" and DISCNUMBER=1. The inserted
  disc's id now decides which medium of the release is used, wherever the release came from. The same search
  list also claimed every result had 0 tracks: MusicBrainz does not send a track list with search results,
  only a count, which is what the list reads now.

• "EACCES: permission denied, mkdir …" now says what is actually wrong. The folder in that message is
  rarely the one that could not be made, and the cause is usually a share that is not mounted — on macOS that
  shows up as a permission error because only root may create folders directly in /Volumes. Rexarr now walks
  up to the deepest folder that does exist, says whether it can write there, and names the first missing part:
  Cannot create the rip folder "/Volumes/Media/Rips/…": /Volumes/Media is not mounted. Read-only filesystems
  and a full disk get their own answers. A disc rip checks the rip folder when it starts, rather than at the end
  of an hour of ripping.

• A scan that finds nothing now says why. "No titles found on this disc (all ...

0.1.7.2

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.7.2 · docker pull moonlightlaboratory/rexarr:0.1.7.2

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

• Notifications (Settings → Connections): Rexarr can tell you when an encode or a disc finishes or fails, and
  when a new release is out — through Discord, Slack, Telegram, ntfy, Gotify, Pushbullet, an Apprise server (which
  covers IFTTT and the rest) or a plain webhook. Add as many targets as you like; each picks its own events, so
  the phone can get failures only while a channel gets everything. Test sends one message with the values on
  screen before you save. A target that fails is written to System → Events and never holds up the job it was
  reporting on. Add notification opens a picker laid out like Sonarr's, one card per kind with a link to that
  service's own instructions, and there is a Custom Script kind that runs a program of yours with the event in
  its environment (REXARR_EVENT, REXARR_TITLE, REXARR_MESSAGE, REXARR_FAILED, …).

Fixes

• The interface got a pass over its spacing and controls. Gaps between form fields came in four different
  sizes because a field's own margin was added to the gap of the grid it sat in; a grid now owns the spacing, a
  card's padding is even on all four sides, and a section heading has more air above it than below. Fields that
  shared a row no longer drift apart vertically – a stretched field was handing its spare height to its own rows,
  which is why "Drive poll interval" sat below "makemkvcon binary" with their labels level.

• Disc ripping and Local media are broken into sections instead of one long two-column wall, each with a
  heading: MakeMKV, where rips go, what happens when a disc is inserted, which titles to rip, adding to your
  library, testing – and scanning, folders, metadata. Nothing moved out of either card.

• Buttons and selects: the small button had 1px of vertical padding, so a Test button was 44x18 with the icon
  crammed against the label; it is 66x26 now, and the notification rows use the same icons as the rest of the app.
  Selects were still the operating system's control inside our box, with its own arrow and spacing – they are
  drawn like the inputs now, chevron included, and the compact ones keep room for it.

• Focus and glow: a focused field shows an amber border, matching the accent the rest of Rexarr uses, with no
  halo – except the search box, which keeps a tinted one. Ticking a checkbox no longer leaves a glow behind it,
  and there is no focus ring on buttons.

• Small things: the count beside a nav item is square and centred with tabular figures, so it does not jump
  between 9 and 10; the header search placeholder fades with its underline instead of blinking out halfway
  through; the rip-folder import is called "Import finished rips", since it has handled films as well as episodes
  since 0.1.7.0.

Full changelog: v0.1.7.1...v0.1.7.2

Full Changelog: v0.1.7.1...v0.1.7.2

0.1.7.1

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.7.1 · docker pull moonlightlaboratory/rexarr:0.1.7.1

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

• NAS templates: ready-made app files for Unraid, ZimaOS / CasaOS, TrueNAS SCALE, Synology DSM
  and OpenMediaVault, each with that system's paths, user ids and device passthrough, plus a
  NAS and home servers page covering hardware
  encoding, disc ripping and the mistakes that bite on a NAS. Rexarr also warns now when its own data folder is on
  an SMB / NFS share, where a dropped share can lose the settings file.

• MakeMKV and Docker, a page of its own: why the published image cannot rip (MakeMKV may not be
  redistributed, and its glibc binaries will not run on the Alpine image), how to build the Debian image that can,
  how to pair Rexarr with a MakeMKV container you already run — through a shared folder, either as virtual drives
  or as finished files for the rip-folder import — and how to keep the two from fighting over the drive. With a
  compose file for the MakeMKV build at docker/docker-compose.makemkv.yml.

• Docker Hub: the image is published to moonlightlaboratory/rexarr as well as GHCR — same build, same tags.
  The CasaOS / ZimaOS app store listing lives in distribution/casaos and is submitted from there.

Fixes

• A dead link in the 0.1.6.0 notes pointed at docs/README.md, which the documentation site replaced; it goes
  to the install guide now. npm run lint was listed in the development notes, which is not a script this
  repository has - npm run typecheck is.
• Release notes shown in System → Updates render fenced code blocks instead of printing the backticks.

Full changelog: v0.1.7.0...v0.1.7.1

Full Changelog: v0.1.7.0...v0.1.7.1

0.1.7.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.7.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

• System → Updates: every release Rexarr has published, newest first, with its notes rendered in the UI —
  what is installed, what is newer, and what changed in between. The list is read from GitHub, cached for six
  hours, refreshed by the Check for updates task twice a day and by the Check button, and a new release is
  written to System → Events once. Rexarr still does not update itself: each newer release says how to install it
  for the way this instance was installed (package, Docker image, or source).

• Documentation site: the whole guide now lives at https://moonlightlaboratory.github.io/rexarr/ — install
  and setup, every page of the UI, disc ripping end to end, a settings reference with the JSON key behind each
  field, the API, troubleshooting and development notes. It is built from docs/ on every push, and the ? in
  the header opens it (System → Status links it too).

Fixes

• MakeMKV availability: the probe swallowed launch errors, so a makemkvcon that could not start was reported
  as simply missing instead of saying why. Thanks to @Dixiao-L.

Full changelog: v0.1.6.0...v0.1.7.0

Full Changelog: v0.1.6.0...v0.1.7.0

0.1.6.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.6.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

• Disc ripping is on by default. Rexarr watches your optical drives out of the box; a disc is still only ripped
  when you press Rip, unless Rip automatically is ticked. Existing installations keep their setting.

• Disc audio tracks: the Discs page now lists every audio track of a title and keeps only the best one per
  language by default (lossless > DTS > Dolby Digital, then channels and bitrate, never commentary). Tick any
  combination of tracks per title and Apply to all titles copies it to every episode on the disc; the rest are
  dropped by a stream copy.

• Rip time and size: a rip shows elapsed time and time left while it runs, and how long it took when it finishes.
  Before ripping, the Discs page estimates the size of the rip and of the encode that follows it.

• Ripped files are imported reliably: Rexarr now tells Sonarr the series and episode, and Radarr the movie, of
  each ripped file (Manual Import) instead of asking the app to scan the folder, which Sonarr skipped because
  "Show (Year) - Disc 1" is not a series name. Every file is checked afterwards, DVD rips are imported as DVD
  quality, and each file's result is written to the disc log.

• Import finished rips automatically (Settings → Disc ripping, on by default): every 10 minutes, films and
  episodes left in the rip folder – a failed import, files copied there by hand – are handed to Radarr and Sonarr;
  Import rip folder now does it at once and lists what happened to each file.

• Check import access (Settings → Disc ripping): asks Radarr and Sonarr whether they can see the rip folder,
  so a rip that cannot be imported is caught before the first disc.

• Better disc matching: a disc label is matched against your own library first – titles, alternate titles and
  AniDB's name for each season – so "SNAFU_2_DISC_1" becomes My Teen Romantic Comedy SNAFU, season 2 ("SNAFU Too!"),
  and a trailing number, "S2", "II" or "2nd Season" is read as a season. Search results are scored instead of taking
  the first hit. Match again re-runs this on a disc that was matched wrongly.

• Specials and extras on discs: each title can be an episode, a Sonarr special (season 0, when TVDB lists
  specials) or an extra – OP, ED, Extra, OVA, Special or a name of your own – which goes into an Extras folder next
  to the show. Titles numbered past the season's last episode are flagged. Include extras and specials (Settings →
  Disc ripping) also lists short titles such as creditless OP / ED.

• Keep the computer awake while working (Settings, on by default): while a disc is scanned or ripped, or a
  file encoded, Rexarr stops the computer from going to sleep – caffeinate on macOS, the Windows power API,
  systemd-inhibit on Linux – and lets it sleep again when nothing is running. System → Status shows when it is.

• Discs for titles not in Sonarr / Radarr are added when the rip starts (or with Add to Sonarr now on the
  Discs page, to pick episodes by name). They go into the root folder and quality profile your library uses for that
  kind of title – TV, anime, movies, anime movies – or the ones set in Settings, and are not monitored by
  default, so adding a show to import one disc never starts downloading the rest of it.

Fixes

• A delivery that imported nothing was reported as done. Radarr and Sonarr report their import commands as
  "completed" even when they imported nothing – the rip folder is mapped to a path that does not exist, the files are
  not where the app looks, a file is rejected – and Rexarr took that as success: the rip was done with no error
  while the files sat in the rip folder. The rip now fails with what happened, both paths and where the files are,
  and the rip-folder import can still bring them in later.
• Encodes at a time: the limit (Settings → FFmpeg, now also on the Activity page) could be exceeded – a job only
  counted once ffmpeg started, so jobs still probing their file let others start. With the limit at 2, three encodes
  ran at once; now the third waits.
• Discs on macOS: macOS mounts a DVD as soon as it is inserted, and MakeMKV could then only use "OS access mode",
  which fails on most discs – scans finished in a second with "No titles found on this disc". Rexarr now unmounts the
  volume (the disc stays in the drive) before scanning and ripping, and says so if MakeMKV still cannot open a disc.
• Adding a title from a disc used the first root folder and quality profile: TV shows went into /anime,
  every movie into Anime Movies, all with "Any" – and shows were monitored, so Sonarr would start downloading
  every episode that was not on the disc.
• Raw rips were imported: raw MakeMKV files were written straight into the rip folder, so a rip that failed
  before encoding left uncompressed files there, which the rip-folder import picked up. Discs are now ripped and
  encoded in Rexarr's local cache, and only finished, compressed files are moved to the rip folder (copied under a
  temporary name and renamed when complete, so a half-copied file is never seen).
• Disc labels of generic words: a label such as "MOVIE_DISC" or "BONUS" matched a library title by those words
  alone – "MOVIE_DISC" became No Game No Life: The Movie. Only real title words count now.

Upgrading: nothing to do. Windows installs over the old version, macOS and Linux replace the folder; your
settings and data stay where they are.

Full changelog: v0.1.5.0...v0.1.6.0

What's Changed

• Fix MakeMKV availability probe swallowing launch errors by @Dixiao-L in #2

New Contributors

• @Dixiao-L made their first contribution in #2

Full Changelog: v0.1.5.0...v0.1.6.0

0.1.5.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.5.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

• New logo, and the name is now written Rexarr: a new icon for the Windows installer and the macOS app, the
  disc mark in the header and as the browser icon. File names, commands, paths and the Docker image stay lowercase.
  The macOS app is now Rexarr.app.
• Version numbers have four parts, major.backend.feature.minor: 0.0.0.X for fixes, 0.0.X.0 for features,
  0.X.0.0 for backend changes and X.0.0.0 for a rewrite. See
  CONTRIBUTING.

Fixes

• Tools that cannot start now say why. An FFmpeg, fre:ac or MakeMKV binary built for another processor (an Intel
  build on an Apple silicon Mac without Rosetta) reported only "Unknown system error -86"; System → Status and the
  health checks now explain it, as they do for missing files and files that are not executable.
• Linux packages: the launcher inside the .tar.gz was named Rexarr after the rebrand, so rexarr/rexarr did
  not exist on Linux. Fixed, and the packager now checks file names case-sensitively.

Upgrading: nothing to do. Windows installs over the old version, macOS and Linux replace the folder; your
settings and data stay where they are.

Full changelog: v0.1.4.2...v0.1.5.0

Full Changelog: v0.1.4.2...v0.1.5.0

0.1.4.2

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.4.2

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

• Recommended tools page: on first launch rexarr checks for FFmpeg (required), fre:ac, MakeMKV and slskd and shows
  how to install whichever is missing on your platform: winget, Homebrew or apt commands with a Copy button, and the
  official download pages. Check again re-detects after installing. It stays available under System → Tools.
• Windows installer: a new Recommended tools page. Tick a tool and its official download page opens when setup
  finishes; tools that are already installed are marked.

Fixes

• fre:ac installed in its standard Windows folders (Program Files\freac) is now found without setting its path.

Full changelog: v0.1.4.1...v0.1.4.2

Full Changelog: v0.1.4.1...v0.1.4.2

0.1.4.1

Warning

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

The first public release of rexarr: a remux-first transcoding companion for Radarr, Sonarr and Lidarr.

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.4.1

Packages include Node.js. Install FFmpeg yourself (and fre:ac for music, MakeMKV for disc ripping); the Docker image
already has FFmpeg and fre:ac. rexarr runs on http://localhost:3939. See the
install guide.

The macOS app is not notarised: the first time, right-click rexarr.app → Open.

Highlights

• Transcoding with FFmpeg profiles for x264, x265, SVT-AV1, libaom, VP9 and hardware encoders (VideoToolbox,
  NVENC, QuickSync, VAAPI, AMF), with presets for movies, TV and anime
• Estimated output size for every profile before you encode
• Live preview while encoding and a before / after comparison when done
• Remux-first release search through Radarr, Sonarr, Lidarr and Prowlarr, ranked by source quality
• Auto transcode of new remux imports, with webhooks for instant pick-up
• Disc ripping with MakeMKV from physical or virtual drives (ISO / BDMV / VIDEO_TS)
• Music with Lidarr and fre:ac: FLAC, MP3, Opus and Vorbis profiles, audio CD ripping with MusicBrainz, MQA
  detection, Soulseek (slskd) search, and automatic splitting of image + cue downloads
• Local media: finds movies, series and albums the *arr apps do not manage, with TMDb, MusicBrainz and Cover
  Art Archive metadata
• Smart search across your library, TMDB / TVDB and AniDB
• Safety: queue pause, stall watchdog, free-space checks, network share health checks and scheduled backups

Notes

• The default port is 3939 (7878 is Radarr's).
• The Docker image's fre:ac has no WavPack or Monkey's Audio encoder.

Full Changelog: https://github.com/MoonlightLaboratory/rexarr/commits/v0.1.4.1