whisparr-eros #2072

Name of the Script

whisparr-eros

Script Type

CT (LXC Container)

Does this script support arm64?

arm64 not tested — see the open question at the bottom.

📋 Script Details

Whisparr V3 ("eros") currently has no helper script, and the existing ct/whisparr.sh
silently gives V3 users a different application. I have written and tested the three files and
would like a steer before opening the PR.

Why a separate script rather than a version option on ct/whisparr.sh

This has already been decided twice in this org, so I want to make sure I am following it rather
than re-opening it:

• Whisparr v2 & v3 are different applications ProxmoxVE#11042 — @tremor021 concluded "Ah, so it should be separate scripts
  then. … probably be making a separate script for v3." Closed 2026-01-22; the script was never
  written.
• Whisparr - User now has a choice between v2 and v3 versions ProxmoxVE#2895 — the opposite approach (a v2/v3 prompt inside the existing
  install script) was closed unmerged after CI failed on the interactive read -p.

So this is that separate script.

Why it matters

ct/whisparr.sh deploys Whisparr/Whisparr latest = v2.2.0-release.108, which is Whisparr
V2 (Sonarr-based, whisparr.db). Whisparr V3 is a different application in a different
repository, Whisparr/Whisparr-Eros (Radarr-based, whisparr3.db), split out on 2026-01-15.
V2 cannot read a V3 database, so a V3 user who runs the current script gets either an empty
install or a destructive migration attempt, with no warning.

Two dead ends worth recording, because they shape the script:

1. The Servarr eros update channel
   (https://whisparr.servarr.com/v1/update/eros?version=…&os=linux&runtime=netcore&arch=x64)
   tops out at 3.1.0.2116, dated 2026-01-14 — older than current releases — and returns
   available:false for anything current. The app's built-in updater therefore never finds
   anything on this branch.
2. Consequently the "the app offers a built-in updater, please use it" pattern used by
   ct/whisparr.sh would be a no-op here. This script implements a real update_script() using
   check_for_gh_release + CLEAN_INSTALL=1 fetch_and_deploy_gh_release instead.

What the script does

• Debian 13 unprivileged LXC, 2 cores / 2048 MB / 8 GB, port 6969.
• Deps: sqlite3, libicu-dev. The build is self-contained .NET (bundles libcoreclr.so), so no
  dotnet runtime package is needed.
• fetch_and_deploy_gh_release "whisparr-eros" "Whisparr/Whisparr-Eros" "prebuild" "latest" "/opt/Whisparr-Eros" "Whisparr.eros.*.linux-$(arch_resolve "x64" "arm64").tar.gz"
/releases/latest on that repo correctly resolves to the stable tag (v3.3.7-release.979) and
  skips the -develop prereleases, so no custom version logic is needed.
• The asset pattern must not match linux-musl-x64. Every release ships both, and the musl
  build dies on Debian with cannot execute: required file not found
  (libc.musl-x86_64.so.1 => not found). The glob above cannot match the musl variants; I
  verified that rather than assuming it.
• Paths derive from the slug: /opt/Whisparr-Eros, /var/lib/whisparr-eros, unit
  whisparr-eros. This is deliberate — if V3 reused V2's /var/lib/whisparr, update_script()
  could be run against a V2 container and overwrite it with the eros build, which is the exact
  failure this script exists to prevent. Data lives outside /opt, so the update needs no
  backup/restore step.

Testing

Installed and updated on a real Debian 13 unprivileged LXC via build.func, not a Docker image:

• Install → /api/v3/system/status reports version 3.3.7.979, branch eros;
  whisparr3.db created; binary confirmed glibc-linked; health clean.
• Update → seeded an older version file, got
  Update available: whisparr-eros 3.3.6-release.934 → 3.3.7-release.979, service restarted,
  config.xml and whisparr3.db byte-identical afterwards.
• Both guard branches exercised: "No update available" and "No Whisparr-Eros Installation Found!".

Two questions before I open the PR

1. Star count. The PR template asks for 600+ stars. Whisparr/Whisparr-Eros is a repo split
   from 2026-01-15 and has ~44 stars on its own, but it is the V3 train of Whisparr
   (Whisparr/Whisparr, ~1,042 stars, created 2022), same org, same
   wiki, GPL-3.0, official release tarballs, 232 releases,
   pushed daily. Does that count as a "comparable public adoption signal", or would this be closed
   on the star rule? I would rather know now than after review.
2. arm64. linux-arm64 and linux-musl-arm64 assets ship upstream and arch_resolve already
   selects the right one, and the five sibling *arr scripts all set var_arm64="yes". I have only
   tested amd64, and .github/agents/pve-script-creator.agent.md says to default to no unless
   verified. I currently have yes / has_arm: true — happy to flip it to no, just tell me
   which you prefer.

Files ready: ct/whisparr-eros.sh, install/whisparr-eros-install.sh, json/whisparr-eros.json
(category 14). ct/headers/whisparr-eros left out, since auto-update-app-headers.yml generates it.