SuggestArr: Turning Watch History into Seer Requests
Effortlessly request recommended movies, TV shows and anime to Jellyseer/Overseer based on your recently watched content on Jellyfin, Plex or Emby—let SuggestArr handle it all automatically, keeping your library fresh with new and exciting content!
At a glance
- What is it?
- SuggestArr is a Python service that reads recently watched items from Jellyfin, Plex or Emby, queries TMDb for similar titles, and files download requests with a Seer instance. The design is opinionated about approval, and that is where most of its operational weight sits.
- Who is it for?
- Adopt SuggestArr if you already run Jellyfin, Plex or Emby alongside a Seer instance and want a scheduled loop that keeps filing requests without anyone opening a browser. Do not adopt it if you have no Seer deployment, no TMDb API key, or a household that would object to automated library growth.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap between a watch history and a request queue
Media servers record what people watched. Seer instances accept requests. Nothing in either product connects the two on a schedule. SuggestArr occupies that gap. It retrieves recently watched content from Jellyfin, Plex or Emby, searches TMDb for similar titles, and sends download requests to Seer. The README describes the audience indirectly through its prerequisites: a TMDb API key, a configured media server, and a configured Seer instance. If you are missing any of those three, the project has nothing to do for you. This is not a discovery tool for people without infrastructure. It is plumbing for people who already have it and are tired of the manual step in the middle.
History in, TMDb similarity out, Seer requests filed
The pipeline has three visible stages. First, retrieval: SuggestArr pulls recently watched items from the configured media server. Second, expansion: it queries TMDb for titles similar to those seeds. Third, submission: it sends requests to Seer. Two optional inputs widen the seed set. Trakt watch history can be linked per user, and the README states that recent Trakt watches can serve as recommendation seeds while fully watched Trakt items can be added to a skip-watched set. That skip set matters more than it sounds, because a recommendation loop that keeps suggesting things you already finished is noise. A second optional layer is AI. The README labels AI-Powered Recommendations as beta and says it uses any OpenAI-compatible LLM (OpenAI, Ollama, Gemini, LiteLLM) to generate suggestions from watch history, with reasoning attached to each pick. A separate AI Search feature accepts a natural-language description and returns matching titles with one-click request to Seer. Both are marked beta in the feature list, which is the honest signal to treat them as the least settled part of the pipeline.
The approval workflow is the real control surface
New jobs follow a global setting called Approve requests before sending them to Seer, which the README says is disabled by default under Advanced. Each job can inherit that setting or override it to always approve or always send automatically. When approval is required, results are held and appear on the Requests page, where the job owner or an administrator can send them to Seer, reject them, or blacklist them globally. Two further brakes exist. A job can be paused while its SuggestArr suggestions await review, and suggestions left pending for a configured number of days can be rejected automatically. Separately, scheduled recommendation jobs can pause when a user has not watched a SuggestArr request within a configurable number of days, though manual runs remain available. Read together, these are guardrails against the obvious failure mode of an automated requester: a queue that fills faster than anyone watches. The default of sending without approval is the choice worth pausing on. It means a fresh install with a working cron schedule will file requests unattended.
Running it from Docker Compose
The README gives a Compose example using the image ciuse99/suggestarr:latest, with the container named SuggestArr, restart set to always, a port mapping driven by the SUGGESTARR_PORT variable and defaulting to 5000, and a volume mount of ./config_files to /app/config/config_files. The only environment variables shown are LOG_LEVEL, defaulting to info, and SUGGESTARR_PORT. Images are also published to GitHub Container Registry as ghcr.io/giuseppe99barchetta/suggestarr:latest. Start with docker-compose up, then open http://localhost:5000, or your custom port, to configure the media service and manage cron schedules. Configuration is done in that web interface rather than in files, and the README states that API keys and URLs are validated during setup. For Trakt, the sequence is: create an OAuth app at trakt.tv/oauth/applications, open Services then Trakt in SuggestArr, enter the Client ID and Client Secret, save, and have each user go to Profile then Trakt Account and click Link Trakt. The supplied README text is truncated mid-sentence at the point where the user enters the Trakt code, so the final step of that flow is not confirmed here. Admins configure only the shared Trakt app credentials; each user links their own account.
Where the automation works against you
The most concrete limitation is stated in the README itself: only local Seer users are supported for the specific-user request flow. If your Seer instance authenticates people through an external identity provider, that feature is unavailable. The second limitation is structural. Every recommendation is a TMDb similarity lookup, so the quality ceiling is TMDb's related-titles data, not your taste. The LLM layer is offered as the answer to that, but it is labelled beta, and a beta path that depends on an external model endpoint adds a dependency the core loop does not have. Third, the cleanup automation, which can prune old SuggestArr-originated requests and files when users never favorite them in Plex, Jellyfin or Emby, is the one feature here that deletes things. The README describes it as optional and does not detail its matching rules in the supplied text, so treat the scope of what it considers SuggestArr-originated as unverified. Finally, content filtering can exclude requests for titles already available on streaming platforms in your country. That is a per-country setting, and it will suppress requests for content you may have deliberately wanted in your own library.
How it differs from Seer's own discovery features
Seer instances already surface trending and recommended titles, and users can request them by hand. That approach is driven by what the instance decides to show, and the request is a deliberate click. SuggestArr inverts both: the trigger is your own watch history rather than a global list, and the request is filed by a scheduled job rather than a person. The difference in practice is the approval queue. Seer's browsing model produces requests at human pace. SuggestArr can produce them at cron pace, which is why the Approve requests toggle, the pending-review pause and the automatic rejection of stale suggestions exist at all. If you want curated discovery inside Seer, SuggestArr adds nothing. If you want the request step to disappear from your routine, that is the specific thing it removes.
Maintenance load and the MIT licence
The release cadence is visible: v2.14.0 in September 2026, v2.13.0 in August, v2.12.0 earlier in August. That is roughly a minor release every two to three weeks, which implies you should expect to pull new images rather than pin one for a year. Configuration lives in a mounted directory, so image upgrades should not touch it, but the README does not describe a migration procedure for the database schema, and external PostgreSQL or MySQL support is listed as an option alongside the default SQLite. If you switch to an external database, you own its backups. The project is MIT licensed, which permits commercial and private use and modification; the README also links a donation page and a Discord server, neither of which affects the licence terms. This is not legal advice, and if you redistribute SuggestArr or ship it inside a product, read the MIT text yourself rather than relying on a summary.
Editorial conclusion
Adopt SuggestArr if you already run Jellyfin, Plex or Emby alongside a Seer instance and want a scheduled loop that keeps filing requests without anyone opening a browser. Do not adopt it if you have no Seer deployment, no TMDb API key, or a household that would object to automated library growth. Before trusting it, verify one manual job end to end: confirm the TMDb key validates in the setup pre-test, watch a title appear on the Requests page, and check whether the global Approve requests setting under Advanced matches what you actually want to happen unattended.
Community notes