Skip to content

Bazarr+ v2.5.1 Murmuration

Choose a tag to compare

View all tags
@LavX LavX released this 03 Jul 10:50
v2.5.1
6fd24bb
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Bazarr+ v2.5.1 (Murmuration)

Codename: Murmuration (stability patch on the v2.5 line).

v2.5.0 taught Bazarr+ to fly as a flock of many Sonarr and Radarr servers. v2.5.1 is the follow-up that tightens the formation: it fixes the two most-reported rough edges from the multi-instance rollout, refreshes a stale community link, and folds in a full round of dependency and security maintenance. No schema changes, no breaking changes, and existing installs self-heal on upgrade.

Headline: Fresh multi-server setups stop spamming the log

A brand-new install configured through the onboarding wizard connected Sonarr and Radarr correctly (the connection test passed, media synced), yet the log filled with Connection refused retries against the default ports 8989 / 7878, and the System page could show one app "down" while it actually worked (#276, #279).

Root cause

The onboarding wizard (and the Connections page) create each arr instance directly through the API and flip use_sonarr / use_radarr on, but they never populated the legacy scalar settings.<kind>.* config. A handful of single-instance compatibility paths (the health-check rootfolder validation, the shared version probe, and the scheduler / SignalR fall-back) still read that scalar config whenever there is exactly one instance, on the assumption that it mirrors the default instance. That assumption holds for installs upgraded from an older single-server config (which was backfilled into an instance) but not for a fresh wizard setup, so those paths kept polling 127.0.0.1:8989 / :7878.

The fix, and it auto-heals

Bazarr+ now mirrors the default instance's connection details back into the scalar config after every instance create/update, and once at startup. The startup reconcile is idempotent (it only writes when something actually changed), so existing affected installs heal themselves on the first boot of this release, with no manual steps.

Upgrading from a fresh v2.5.0 setup that was noisy? Just update and restart as usual. The scalar config is reconciled from your default instance on boot and the connection-refused spam stops.

Reverse-proxy subpath no longer shows a blank page

Running Bazarr+ behind a reverse proxy on a subpath (base_url, e.g. /bazarr, with PathPrefix and no StripPrefix) rendered a blank/white page: the HTML loaded with the correct <base href="/bazarr/">, but every JavaScript and CSS asset 404'd (#277, #278).

The supervisor injected the <base href> while its static allowlist only held bare assets/… keys, so /bazarr/assets/* never matched and fell through to the known-extension 404 guard. The supervisor now strips the configured base_url prefix before the static lookup, so assets resolve correctly under the prefix. Deployments without base_url are unchanged.

Thanks to @slother, who both reported the issue and sent the fix.

Community

  • The Discord invite had been created as a 30-day link and quietly expired; it is replaced with a current never-expiring invite across the README, the in-app System status page, and the marketing site (#279).

CI / Docker

  • Release-only image publishing is unchanged: Docker images publish on a push to master and on a v* tag (build-docker.yml); the GitHub Pages site deploys from site/ on master.
  • The dynaconf bump kept the startup requirements probe honest: the fork pins its security-probed dependency versions in bazarr/app/requirements.py and a guard test asserts requirements.txt and the probe agree, so a bump has to update all three in lockstep (#285).

Dependency Updates

A full round of dependency and security maintenance, with no known vulnerabilities outstanding (0 open Dependabot alerts, 0 open code-scanning alerts):

  • Python: dynaconf 3.3.2 (#285), pillow ≥12.3.0 (#283), apscheduler 3.11.3 (#282), alembic 1.18.5 (#271), cloudscraper ≤1.2.71 (#270), python-dateutil 2.9.0.post0 (#269), numpy 2.5.x (#268), ruff 0.15.20 (#273).
  • Frontend: the FontAwesome group (#281) and @tanstack/react-query-devtools 5.101.1 (#272).
  • CI: actions/cache v6 (#267).

Deferred: guessit 4.0.2 (#280) is intentionally held back. It requires rebulk>=6, but the tree cannot get there (subliminal → knowit → trakit, and every published trakit pins rebulk<4). It will be revisited when upstream trakit / knowit support rebulk 6.

Database Migrations

No schema changes in this release. Configuration and database migrations still run automatically on first start, and the multi-instance scalar-config reconcile described above runs on boot and is idempotent. Nothing to do manually; single-instance installs are unaffected.

Included Pull Requests

#267, #268, #269, #270, #271, #272, #273, #278, #279, #281, #282, #283, #285

Upgrade / Migration Notes

  • No breaking changes. Update and restart as usual.
  • A fresh-onboarding install that was noisy on v2.5.0 self-heals on this upgrade: the scalar config is reconciled from your default instance on first boot.
  • Behind a reverse proxy on a subpath, the blank-page issue is resolved with no config change on your side.
  • PostgreSQL remains fully supported and first-class.

Docker

docker pull ghcr.io/lavx/bazarr:2.5.1
docker pull ghcr.io/lavx/bazarr:latest

After upgrade, confirm the UI loads and /api/system/status reports 2.5.1.

Contributors

Thanks to @slother for reporting and fixing the reverse-proxy subpath issue, and to @Ultimatum22 and @MikeTrysome for the detailed, reproducible bug reports that drove this release. 🪶

Full Changelog: v2.5.0...v2.5.1

Contributors

Ultimatum22, slother, and MikeTrysome
Assets 2
Loading