No description
- Nix 88.4%
- TypeScript 5.9%
- Python 5.4%
- Just 0.3%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
Pim Kunis
cddc24217b
The agent could file a request but then only read back Jellyseerr's coarse status, so "waar blijft mijn film?" got an unhelpful answer. It now knows how Jellyseerr, Radarr/Sonarr, Prowlarr, qBittorrent, Bazarr and Jellyfin fit together, and can see into them. The system prompt covers the two states that actually confuse people: that a release is sometimes never found (so nothing happens, with no error anywhere), and that a download can sit at 100% while the *import* failed -- the hardlink permissions trap already documented here. It also knows the ~10 days of seeding afterwards is normal, so it stops reporting that as a fault. downloads.ts adds two read-only tools: download_status(title) merges the Sonarr/Radarr queues with qBittorrent for one title, surfacing trackedDownloadStatus and statusMessages where a stuck import actually shows up; download_problems() lists everything warning, erroring or stalled. Deliberately read-only -- no retry, pause or delete, even though those APIs are right there. A diagnostic tool that can also act turns "why is this stuck?" into an agent retrying things unsupervised. The tools are also what keep the new pipeline knowledge honest: a model given a detailed mental model of a system it cannot observe will narrate a plausible journey for a film that was never grabbed. Two qBittorrent API quirks cost a debug round and are now in CLAUDE.md: login answers 204 with an empty body (not 200 "Ok."), and the session cookie is QBT_SID_8080, not SID. Also fixed download_problems swallowing an unreachable *arr and reporting "nothing is stuck", which is a worse answer than the outage. The shim now takes a colon-separated PI_EXTENSIONS list. Verified against a live download: Okja observed at 3.4%, then complete and seeding, with the agent's description matching qBittorrent ground truth. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
| .zed | ||
| claude | ||
| modules | ||
| secrets | ||
| .envrc | ||
| .gitignore | ||
| .mcp.json | ||
| .sops.yaml | ||
| CLAUDE.md | ||
| flake.lock | ||
| flake.nix | ||
| globals.nix | ||
| Justfile | ||
| lamp-ble-proxy.yaml | ||
| m5stack-atom-echo-1b4530.yaml | ||
| README.md | ||
nixos-configs
NixOS configurations for the machines I manage.
Currently managed systems:
- blocktech: My current laptop, a ThinkPad P1 running GNOME.
- gamepc: My gaming PC running Cosmic
- warwick: A Raspberry Pi 4 Model B, which mostly does monitoring
- atlas: A Gigabyte Brix, currently running NixOS containers
- lewis: A Gigabyte Brix, currently running NixOS containers
- roeland: A Minisforum UN100P, runs my Jellyfin + *arr + Audiobookshelf setup
Deployment
I use Colmena for deploying my machines.
To apply to the local machine:
sudo colmena apply-local --sudo
To apply to all remotely managed systems:
colmena apply
Collabora manual actions
Apart from the declarative commands, these commands also need to be ran on the server for a successful Collabora setup:
# From the perspective of Nextcloud
nextcloud-occ config:app:set richdocuments wopi_url --value="http://collabora.mesh.kun.is:9980"
# From the perspective of clients
nextcloud-occ config:app:set richdocuments public_wopi_url --value="http://collabora.mesh.kun.is"
nextcloud-occ richdocuments:activate-config