AutoFilm writes .strm files so Emby and Jellyfin can serve an Alist library

The problem is that a media server cannot read a network drive directly

Emby and Jellyfin are built to scan local files. When the actual media sits on an Alist instance reachable over the network, the usual workarounds are either a WebDAV mount, which makes the server do slow directory listings, or copying everything locally, which fills the disk. AutoFilm takes a third route. It walks the Alist storage through the official API and writes a .strm file for each video, and a .strm file is just a text file pointing at the real URL. The media server scans a small tree of text files, builds its library from them, and streams from Alist when playback starts.

The project describes itself as a small tool for Emby and Jellyfin that generates strm files, follows anime series, and draws library posters. The stated advantages of the .strm route are a lighter Emby server with lower disk requirements, and better search, built in scrapers, and multi device playback progress sync compared with pointing the server at WebDAV directly. A separate tool, MediaWarp, is needed for playback speed not to be limited by the Emby or Jellyfin server bandwidth. The audience is therefore specific: people running a media server in one place and their storage in another.

The 2.0.0 rewrite changed the language and the config file together

AutoFilm started in Python. The version history records Cython compilation of the Python files inside the Docker container for a performance gain in 1.3.1, a scheduled background task system built on AsyncIOScheduler in 1.2.0, and an Alist official API client replacing WebDAV access in 1.1.0. All of that is history now. The 2026.7.23 entry for v2.0.0 records a rewrite in Rust with a large performance improvement and much lower memory use, and it warns in the same line that the configuration file changed considerably and needs to be set up again.

That is the whole upgrade story: a 1.x user cannot carry a config file over. The Cargo manifest confirms the current state, with the package named autofilm, version 2.0.0, and edition 2024. The dependency list is a good map of what the tool actually does. There is alist, aliased to the local alist-client-rs path, for talking to storage. There is reqwest with the rustls feature and no default features, so the HTTP client is built on rustls rather than the platform TLS stack. There is image and imageproc with ab_glyph for the poster rendering, and tokio with the multi thread runtime, time and signal features, plus tokio-cron-scheduler for the scheduled jobs. The separate serde_yaml crate handles the config file, and clap with derive handles the command line.

Running the binary takes a config file and nothing else

The README gives two ways to run AutoFilm, and Docker is the recommended one, with the compose file at docker/compose.yaml. The binary route is the second option. Two commands are shown, and the first is only there to print the usage information.

./autofilm --help
./autofilm --config /path/to/config.yaml

The second command is the one that matters: it points the binary at a YAML config file, and the full config structure is documented in config/config.example.yaml in the repository. The project ships a Docker image under the name akimio/autofilm on Docker Hub, and the release profile is tuned for size and speed rather than build time. The Cargo profile sets codegen-units to 1 and lto to "fat", with a comment in the file explaining that this gives LLVM much more room for inlining and dead code elimination and a smaller binary, at the cost of slower release compilation. opt-level is 3 and strip is "symbols", so the shipped binary carries no debug information or symbol table.

One more thing is easy to miss. The readme points to an external documentation post at blog.akimio.top for the detailed explanation, which means the README itself is a summary rather than the full manual. Configuration details beyond the example file should be confirmed there.

Four modules map onto the stages of a media pipeline

The changelog names the moving parts, and they correspond to distinct jobs rather than one monolithic sync. Alist2Strm is the core: it enumerates the Alist storage and writes the .strm files, and the 1.2.5 entry introduced a sync function for it, with 1.2.6 adding a sync ignore option. Ani2Strm arrived in 1.2.2 and Ani2Alist is the anime following module, whose runtime logic and performance were both touched in 1.3.0. LibraryPoster, added in 1.4.0, renders the covers shown in a media library.

The safety mechanisms in Alist2Strm are worth noting because they are the difference between a tool that helps and one that deletes a library. Version 1.5.1 added a .strm smart protection feature to prevent large scale accidental deletion, and 1.3.3 added the ability to add and remove empty directories. Earlier entries show the project learning to be careful with a remote API: 1.3.2 added a configurable interval between file traversals to avoid triggering rate limits, and 1.5.0 added support for the BDMV Blu ray disc directory structure. Version 1.5.1 also split public_url from the internal address so that one Alist instance can serve different URLs to different networks.

LibraryPoster reimplements the poster generation in Rust

The poster module is the part with a visible visual output, and it ships four styles: blur, card, collage and split. The README states that the visual design was inspired by two other projects, jellyfin-library-poster and the mediacovergenerator plugin for MoviePilot, but that the image processing pipeline was reimplemented in AutoFilm using Rust. That distinction matters for the dependency list, since the image crate with gif, jpeg, png and webp features, the imageproc crate and ab_glyph for fonts are all pulled in for this work, and the repository carries a fonts directory to supply the typefaces.

The alternative approach here is doing the rendering in Python with Pillow inside the Docker image, which is what the 1.x releases did, with a 1.5.1 entry noting an update to the Docker Python version and the Pillow dependency. The Rust path exists to cut memory use and runtime for a job that runs over a whole library. The trade-off is that a self built binary needs a Rust toolchain, and the 1.x Docker image approach was simpler for anyone who did not want to compile anything. The open source poster generators remain an option if you only want covers and not the strm pipeline.

What is missing, and what the licence means

The TODO list is honest about the gaps. API triggered tasks are still unchecked, so the tool runs on its scheduler rather than being called by another application. Notifications are also unchecked. And the TMDB work for classification, renaming and scraping was struck through and replaced: a pull request to MoviePilot adding support for operating on Alist server files has been merged into the main branch there, so scraping is delegated to MoviePilot rather than built into AutoFilm. A separate MediaWarp project is what removes the server bandwidth limit during playback.

Licence is the sharpest edge. The repository carries a LICENSE file, and GitHub cannot classify it as one of the standard licences, which means it is a custom grant rather than MIT, Apache 2.0 or GPL. The README does not summarise its terms, so anyone deploying this in a service, or in a company, has to read the LICENSE file directly and cannot assume the permissions they would get from a familiar open source licence. On maintenance, the last push was on 2026-10-03, the project is not archived, and the release list shows v2.0.0 on 2026-07-23, v1.5.1 on 2026-06-03, and a pre-release on 2026-08-02.

Editorial conclusion

AutoFilm suits self hosted setups that keep media on an Alist instance and want Emby or Jellyfin to index it without copying files to the media server. It is a poor fit for a small library on local disk, where plain symlinks or direct mounting are simpler. Before upgrading from a 1.x release, budget for a full reconfiguration, because the 2.0.0 rewrite changed the config format substantially, and read the LICENSE file yourself since the project uses a custom licence that GitHub cannot classify.

Frequently asked questions

Official sources

1. AkimioJR/AutoFilm on GitHub
2. Issues
3. README
4. Releases