Mediary Scout: an agent that transfers media into your Chinese cloud drive and checks what landed

The gap Mediary Scout targets: acquisition as state, not as a download

Most media automation tools split into two unsatisfying halves. One half searches well but has no idea what you already own, so you re-acquire the same season. The other half moves files but never confirms that the move completed, so a failed transfer looks identical to a successful one until you open the drive. Mediary Scout's README frames the problem directly: it treats acquisition as a state problem, driven by an agent that acts from evidence. The intended user is someone whose library lives on a Chinese cloud drive rather than a local disk, and who wants a queue of missing episodes filled without babysitting each one.

The scope is narrower than a general-purpose media server. It does not play anything, does not scrape metadata for a library wall in the Plex sense, and, per the README, it transfers shares and magnets into your drive rather than downloading to local storage. That last point is the design centre. If your media already sits on a NAS volume, most of what this project does is irrelevant to you.

How the agent loop works: indexers in, verified transfers out

The flow the README describes is: you ask for a movie, show or anime; an LLM agent scouts resources across your indexers; it transfers the best match into your own drive; it verifies what landed; and it keeps tracking what is still missing. Selection is not a fixed quality profile alone. The README states the agent reads real search results and picks by quality preference, Chinese-subtitle needs and de-duplication, then verifies the transfer afterwards. That ordering matters, because de-duplication is what stops a second sweep from re-acquiring an episode you already have.

Underneath, the repository is a TypeScript monorepo with npm workspaces over apps/* and packages/*, and package.json requires Node >= 22.13.0. The Dockerfile comment says one container runs both the Next.js app and an in-process queue worker, started through apps/web/instrumentation.ts, so there is no separate worker service to schedule. The data layer is chosen by the MEDIA_TRACK_SQLITE_PATH environment variable rather than by which shell you run: the desktop build sets it automatically and uses SQLite, while Docker defaults to Postgres. Season-level tracking is described as a state machine, and a scheduled sweep returns only for shows that still have missing episodes.

Resource discovery has two sources. Prowlarr is the indexer side, and PanSou is a separate resource search service that the compose file pulls from ghcr.io. Both are configured in Settings rather than in files.

Connecting a drive: five brands, two very different transfer paths

The drive list is where adoption decisions actually get made, because the brands are not equivalent. Quark (夸克) supports share-link transfer and, per the README, has no magnet web API, but it has by far the largest share pool on PanSou. 123网盘 is dual-path: share links of the form 123pan.com/s/... and magnets through its native offline-download API, which resolves, submits and polls. The README notes free 123 accounts can transfer because a server-side copy costs no download quota. 115 is the other dual-path brand, with share links and a built-in offline path plus Prowlarr. GuangYaPan (光鸭云盘), a Xunlei-family drive, is magnet, ed2k and BT only through its offline-task API and does not transfer share links in v1, which makes it a poor fit unless you have Prowlarr feeding it. Tianyi (天翼) handles share links from cloud.189.cn and the README calls its PanSou share pool the smallest, weak for movies and workable for shows and anime.

Auth differs per brand too: QR login with roughly a 90-day token for 123, token auth for GuangYa, QR or a pasted SSON cookie for Tianyi. The README points each brand at its own section of docs/deploy.md. Read the row for your drive before you install anything, because the wrong pairing (GuangYa without an indexer, Tianyi for films) is a setup that will look broken when it is merely mismatched.

Install and first acquisition

There are two supported paths and the README is explicit about which suits whom. The desktop app is the recommended one for personal use on macOS (Apple Silicon) and Windows x64. The macOS DMG is signed and notarized; the Windows EXE installer is unsigned, so SmartScreen prompts and you click run anyway. It bundles its own SQLite data layer and runs the engine inside an Electron shell, so there is no Docker, no Postgres and no terminal. After installing, open the app, go to Settings, connect a drive and add an LLM endpoint, then search a title and hit 获取.

The Docker path is for a NAS or server that should keep patrolling. The README gives two commands, and the .env copy is optional because most configuration can be set in the UI:

cp .env.example .env   # optional — most config can be set in the UI
docker compose up -d

After that, open http://<host>:3000 and configure in Settings. The compose file starts three services: the web container, Postgres 16-alpine with database mediatrack and user mediatrack, and a PanSou container pulled from ghcr.io. If you are on a mainland China network and Docker Hub is unreachable, set a mirror prefix in .env and the compose file applies it to the Postgres and node images together:

DOCKER_MIRROR=docker.1ms.run

The compose comments list docker.1ms.run, dockerproxy.net, docker.m.daocloud.io and hub.rat.dev as mirrors that worked at the time of writing, and warn that public mirrors fail in rotation. Note the boundary: PanSou comes from ghcr.io, so DOCKER_MIRROR does not affect it, and a blocked ghcr needs PANSOU_IMAGE set instead. The build stage needs the same value, either as a build argument or via .env, which compose passes through automatically. The build argument NPM_REGISTRY defaults to https://registry.npmjs.org and can be pointed at a faster mirror.

Building from source is possible but clearly the less-travelled route. The root scripts are build:workflow, dev:web, build:web, test, typecheck and lint, and dev:web runs the workflow build before starting Next with the turbopack flag. Node 22.13.0 or newer is required.

Where Mediary Scout is the wrong tool

The sharpest limitation is the desktop app's patrol behaviour. The README's comparison table marks always-on patrol as unavailable on desktop, with the note that it runs when the app is open, and available under Docker. If your reason for wanting this project is that missing episodes get filled while you sleep, the desktop build does not do that, however much simpler it is to install.

Multi-user is the second boundary: it is listed as Docker-only, and remote access on desktop is local only, while Docker expects Tailscale or Cloudflare Tunnel. So a household sharing one instance is a server deployment, not an app install.

The agent itself is a dependency you supply. The README describes adding an LLM endpoint in Settings and calls it BYO-key, and package.json depends on ai and @ai-sdk/openai-compatible. Nothing in the README suggests a bundled model or a fallback when the endpoint is down, so an unconfigured or unreachable LLM is a hard stop for acquisition rather than a degraded mode. That is worth weighing if you wanted a purely deterministic rule engine.

Drive coverage is the third constraint, and it cuts both ways. Five brands are supported; anything else is not, and the README says adding a brand is a contained plugin rather than a configuration change, which is a developer task. Within the supported five, capability is uneven: GuangYa cannot take share links in v1, Quark cannot take magnets, and Tianyi has the thinnest PanSou pool. Finally, cloud-native means cloud-only: there is no local download path, so this is not a replacement for a download client if your library sits on disk.

Alternatives and the real difference in approach

The closest thing to a direct alternative is running Prowlarr plus a download client such as qBittorrent or a 115 offline task by hand. The difference is not search quality, it is where the state lives. With that stack, the indexer returns candidates and the download client holds a queue; nothing knows that season 3 is missing two episodes, and nothing confirms that a transfer finished. Mediary Scout puts a season-level state machine and a post-transfer verification step in the middle, which is why its README contrasts tools that search well but do not know what you are missing against tools that move files but never verify what landed.

A second alternative is the *arr family with a local library. That stack is stronger if your media ends up on a disk you control, because it owns the whole path from indexer to file on disk. Mediary Scout deliberately does not take that path: it transfers shares and magnets into the cloud drive using 秒传 or save, so there is no local file to manage and no disk to size. If you want a local library, the *arr approach is the one that matches your storage model.

A third option is doing nothing automated and using PanSou or a share search site manually. That is genuinely fine for a handful of films. It stops being fine when you are tracking an airing show across a season, which is the case the scheduled sweep exists for.

Licence, release cadence and the upgrade cost you are taking on

The licence is 0BSD, a permissive licence with no attribution requirement, and the README links to LICENSE for the text. That is about as unencumbering as it gets for self-hosted use, but it also means no warranty and no obligation on the maintainer to keep a drive plugin working when a vendor changes an API. Since every drive integration talks to a Chinese cloud provider's private endpoints, that is the realistic maintenance risk rather than anything in the licence itself. This is not legal advice; read LICENSE if the terms matter to your situation.

The release history shows v1.4.1 on 2026-08-06, v1.4.0 on 2026-08-01 and v1.3.2 on 2026-07-23, and the last push to the repository was on 2026-09-04. The v1.4.0 notes describe Mediary Connect, a paid remote-access feature. That is a commercial element alongside an open-source codebase, and the README does not document what happens to that feature if you never pay for it, so treat it as something to check before you build a workflow around remote access.

Upgrade cost splits by install path. The desktop app is a download and reinstall, with the README noting that releases are gated: CI installs the freshly built Windows package on a clean runner, boots the app and requires an HTTP 200 health response, while the macOS build must pass native-ABI verification, signing and notarization, and both platforms publish together so a failed gate blocks both assets. Docker is a rebuild and a compose restart, and the build argument surface (DOCKER_MIRROR, NPM_REGISTRY, NODE_IMAGE) is where a network change will bite you rather than the app code. The README does not document a rollback procedure, so pinning a release tag or image digest before you upgrade is your own precaution to take.

Editorial conclusion

Adopt Mediary Scout if you already pay for one of the five supported Chinese cloud drives and want acquisition treated as tracked state rather than a one-off download. Skip it if your library lives on a local disk, if you need a drive brand outside the five, or if you want everything running without an LLM endpoint, since the agent needs one. Before committing, open Settings and confirm your drive brand's auth path works, check whether your drive can consume the magnets your indexers return, and decide between the desktop app and Docker on whether you need patrol to run while nothing is open.

Frequently asked questions

Official sources

1. fancydirty/mediary-scout on GitHub
2. License: 0BSD
3. Project website
4. README
5. Releases