Releases: Krippler/Starr
Releases · Krippler/Starr
Release list
v1.3.6
Fixed
- The rightmost dashboard column still couldn't be dragged — cards in the right column of a two-column layout couldn't be moved to create a third column or into the first column (only after seeding a third column from the left did the middle column become movable). Root cause: native HTML5 drag-and-drop — adding the + rail on dragstart reflowed the columns and the browser's drag hit-testing broke dragging out of the rightmost column. Rearranging is now driven by pointer events with a floating clone and purely coordinate-based routing, so every column behaves identically. Verified by driving a real mouse in a headless browser (right-column → new third column, right-column → first column, and in-column reorder all work).
Docker images
docker pull krippler52/starr:1.3.6
docker pull ghcr.io/krippler/starr:1.3.6Also published as latest, 1.3, and 1.
v1.3.5
Fixed
- Dragging a card into an adjacent column or the new-column rail was unreliable — the drag used a per-column dragover handler, so you had to land the cursor precisely inside a thin column/rail and the flex gaps between columns were dead zones. In a two-column layout, a card from the right column often couldn't be dropped into the far-right "+" rail to create a third column. Drag routing now uses a single dashboard-level handler that tiles the full width into column bands (a column owns everything up to its right edge; the rightmost owns everything beyond), so the whole dashboard is a reliable drop surface with no dead gaps.
Docker images
docker pull krippler52/starr:1.3.5
docker pull ghcr.io/krippler/starr:1.3.5Also published as latest, 1.3, and 1.
v1.3.4
Fixed
- Couldn't drag a card into a shorter column — dashboard columns were only as tall as their content, so the empty space beneath a short column (e.g. one with a single card) wasn't part of any column and rejected drops. With two columns of very different heights this made cards from the tall column impossible to move into the short one. Columns now stretch to the full dashboard height, so their entire width is a valid drop target. The while-dragging "+" drop-rail for creating a new column was also widened (48→60px) for easier targeting.
Docker images
docker pull krippler52/starr:1.3.4
docker pull ghcr.io/krippler/starr:1.3.4Also published as latest, 1.3, and 1.
v1.3.3
Added
- Grow/shrink dashboard columns by dragging — no Reset needed — while you drag a card, any empty column now shows as a dashed + drop-rail, so you can pull a card into empty space to spin a column back up (1 → 2 → 3, capped by the screen width). Dropping a card into a rail expands it into a full column; emptying a column collapses it again. Previously, once a column collapsed (1.3.2) the only way back to more columns was Reset layout.
Docker images
docker pull krippler52/starr:1.3.3
docker pull ghcr.io/krippler/starr:1.3.3Also published as latest, 1.3, and 1.
v1.3.2
Fixed
- Empty dashboard columns left dead space — after dragging every card out of a column (e.g. consolidating a 3-column layout down to 2), the now-empty column still reserved its share of the width, leaving a blank gap on wide screens. Empty columns now collapse so the populated columns expand to fill the page. (Reset layout restores the default multi-column spread.)
Docker images
docker pull krippler52/starr:1.3.2
docker pull ghcr.io/krippler/starr:1.3.2Also published as latest, 1.3, and 1.
v1.3.1
Fixed
- Dashboard panel titles were pushed to the centre of their headers — the drag grip added in 1.3.0 was injected as a flex child of each panel header, and with
justify-content: space-betweenthat turned every header into three items, centering the title (Connection, Repair Operations, etc.) instead of left-aligning it. The grip is now absolutely positioned in a small reserved gutter, out of the flex flow, so headers lay out exactly as before 1.3.0 with the grip appearing on hover.
Docker images
docker pull krippler52/starr:1.3.1
docker pull ghcr.io/krippler/starr:1.3.1Also published as latest, 1.3, and 1.
v1.3.0
Added
- Rearrangeable dashboard — the main panels (Connection, Repair Log, Operations, Trends, Backups, Schedules, Notifications) are now drag-to-rearrange cards. Hover a panel header to reveal a grip handle and drag it to reorder or move it between columns. On wide screens the panels flow into 2–3 responsive columns (single column on narrow/mobile, identical to before); each width remembers its own arrangement, saved per-browser in
localStorage(same mechanism as the existing panel collapse-state). A Reset layout button restores the default. The live run status (shutdown warning, progress bar, result tiles) stays in a fixed strip above the grid so it never moves mid-repair. Purely a frontend enhancement — no API or backend changes.
Docker images
docker pull krippler52/starr:1.3.0
docker pull ghcr.io/krippler/starr:1.3.0Also published as latest, 1.3, and 1.
v1.2.10
Fixed
- Docker client socket/fd leak — every Docker operation (
docker stop/startaround a repair, and each auto-discovery scan) opened a docker-py client but never closed it, leaking arequestssession + a socket to/var/run/docker.sockeach time. Discovery now runs on every scheduled-repair preflight, so on a long-lived container these accumulated until the process could hit its open-file limit. All clients are now closed after use (repair shutdown/restart,discover(),_self_appdata_root(), and the container-lookup failure path). - Leaked SQLite connection on an unexpected repair error —
_step_repaironly closed its connection on the normal path; a non-sqlite3error escaping the op loop (e.g. anOSErrorwhile stat-ing the file during VACUUM) abandoned an open connection still holding a WAL/exclusive lock on the app's live database. Connection cleanup (rollback + close + clearingactive_conn) now runs in afinally. - Notifications could hang the repair worker forever — Apprise's
notify()takes no timeout and many of its plugins fall back torequestswith no timeout, so a black-holed target would block the worker thread (and its fd) indefinitely, since notifications run inline at the end of every run. Apprise sends are now bounded by a watchdog (APPRISE_TIMEOUT_SECONDS, default 30s); a timeout is reported as an error and the worker proceeds. Signal and webhook sends already had timeouts. - Stale credential overrides on instance delete — deleting a named instance left its saved apikey/url/db_path override on disk, growing the overrides file over add/delete cycles and keeping stale credentials around.
delete()now removes the matching override.
Docker images
docker pull krippler52/starr:1.2.10
docker pull ghcr.io/krippler/starr:1.2.10Also published as latest, 1.2, and 1.
v1.2.9
Supersedes 1.2.8. The v1.2.8 tag was cut from main moments before this
fix was merged, so the published 1.2.8/latest images were built from the
1.2.7 code and did not contain the fix below; 1.2.9 ships it.
Fixed
- Scheduled repairs now self-heal a stale container IP instead of failing until you click "Detect" — a scheduled run resolves the *arr's address from the Docker discovery cache, and if the container had been recreated (Docker reassigns its bridge IP) the run could fail preflight with
Cannot reach <app> at http://<stale-ip>:<port>; it only started working again after visiting the app page / hitting Detect forced a fresh scan. Preflight now detects a first-try connection miss, forces a fresh Docker scan, re-resolves the address, and retries once at the current IP — no manual step. Respects expliciturl/*_URLoverrides (never rescans over a pinned address) and only retries when the re-scanned address actually changed. Discovery's own Docker client timeout was also raised from 10s to 30s (matching the repair client) so a busy daemon doesn't falsely report Docker as unavailable and strand the cache on a stale IP.
Docker images
docker pull krippler52/starr:1.2.9
docker pull ghcr.io/krippler/starr:1.2.9Also published as latest, 1.2, and 1.
v1.2.7
Supersedes 1.2.6. An earlier v1.2.6 tag was created from an incomplete
commit and shipped only the first of the two fixes below; 1.2.7 delivers both.
Fixed
docker stopread-timeouts no longer abort a repair — the Docker client used a 10s HTTP timeout, and docker-py sets a stop's read timeout toclient_timeout + stop_grace(10 + 30 = 40s), so a slow/busy daemon that took longer than 40s to stop a container surfaced asdocker stop failed: … Read timed outand killed the repair — even though the daemon was stopping the container. The client timeout is now 30s (→ 60s of stop headroom), and a stop read-timeout is treated as "maybe still stopping": Starr polls the app for up to 60s and proceeds once it's actually offline, only failing if it stays up. Genuine (non-timeout) stop errors still fail fast.- Repairs now re-scan Docker for the container's current bridge IP — the discovery cache (which holds each *arr's bridge IP) was only refreshed at startup and on the "Detect" button, so if a container was recreated (Docker reassigns its IP) a repair kept hitting the old address and failed with
Cannot reach <app> at http://<stale-ip>:<port>._resolve_request_cfg(manual + scheduled repairs) and_resolve_conn_lenient(restore) now rescan right before resolving the connection, so the current IP is always used. The rescan is gated on Docker actually being in use, is resilient to a transient scan failure (keeps the last-known-good cache), and adds no latency to non-socket setups.
Docker images
docker pull krippler52/starr:1.2.7
docker pull ghcr.io/krippler/starr:1.2.7Also published as latest, 1.2, and 1.