SmartStrm: generating .strm files from cloud drives for Emby

The last mile problem between a cloud drive and a media library

SmartStrm is described as a media library STRM file generation tool, and the one line summary of the project is that it works gracefully with Emby so that media resources flow into the library smoothly, supports 302 direct link playback, and supports synchronized deletion of remote files.

The problem it solves is specific and real. A.strm file, per the linked Emby documentation, is essentially a shortcut to a network resource, which lets a media server request the media directly from the network when it plays, without storing the media file locally. The two benefits the README calls out are that importing is very fast, because scanning the library only has to recognise kilobyte-sized text files instead of reading vast amounts of media data, and that compatibility is wide, covering Emby, Jellyfin, Plex, Kodi and the Chinese fnOS media server (Feiniu Ying Shi).

That combination is the whole value proposition. Cloud storage providers give you cheap capacity but poor streaming integration, and a NAS gives you good integration but expensive capacity. Writing a few hundred bytes per item instead of copying gigabytes is the trick, and the fact that the tool understands many cloud drive back ends is what makes it usable rather than a toy.

The project describes itself as the last mile from mainstream cloud storage into a private media library, achieving invisible ingestion and instant playback, and it positions itself to work with Quark-Auto-Save and CloudSaver transfer tools and with OpenList and Emby.

The target audience is therefore a self hosted media setup with a NAS or server, a collection of cloud drive accounts, and a media server that has to know what exists.

What the tool actually generates and deletes

The feature set in the README is organised around a scheduling engine, so it is worth taking each part in turn.

The drive support is broad. The tool supports OpenList, WebDAV, Quark, 115, Tianyi, Guangya cloud drive, Xunlei cloud drive and other mainstream network storage drivers, so fragmented media resources can be aggregated and managed in one place.

The automation is built on a Crontab based scheduled task system, supporting incremental generation, synchronized deletion and real-time monitoring of local storage. The incremental part matters for cost and for time, because regenerating every pointer file on every run would mean re-listing every remote directory.

The link with other tools is the interesting bit. The tool works closely with QAS, which is Quark-Auto-Save, and CloudSaver, transfer tools, to implement a save triggers a run model. It also supports deletion linkage with Emby, keeping the files and the library consistent. So SmartStrm is not a standalone scanner; it is designed to sit in a chain where a transfer tool saves something to a cloud drive, SmartStrm notices and writes the pointer, and the media server picks it up.

The plugin system extends this. The listed capabilities include filename repair, content regular expression replacement, notification of an fnOS refresh, video cover extraction and advanced scan filtering, which are the kind of tasks that a specific media library always needs and that no generic scanner will have.

The recognition side has a built-in file browser with TMDB based identification and batch renaming, so the pointer files end up with a structure that scrapes correctly.

The 302 direct link playback feature is a separate idea and is marked as a Pro feature. It applies the 302 redirect technique to Emby, Jellyfin, Plex and the fnOS media server, so the video stream connects straight to the cloud drive and does not consume the NAS bandwidth.

Running the container and reaching the admin interface

The documented deployment is Docker, and the quick start is a single docker run invocation:

docker run -d \
  --name smartstrm \
  --restart unless-stopped \
  --network host \
  -v /yourpath/smartstrm/config:/app/config \  # 挂载配置目录
  -v /yourpath/smartstrm/logs:/app/logs \  # 挂载日志目录，可选
  -v /yourpath/smartstrm/strm:/strm \  # 挂载 STRM 生成目录
  # 以上 /yourpath 改为你实际存放配置的路径
  -e PORT=8024 \  # 管理端口，可选
  -e ADMIN_USERNAME=admin \  # 管理用户名
  -e ADMIN_PASSWORD=admin123 \  # 管理用户密码
  cp0204/smartstrm:latest

The compose file is the recommended route, and it is a short one:

name: smartstrm
services:
  smartstrm:
    image: cp0204/smartstrm:latest
    container_name: smartstrm
    restart: unless-stopped
    network_mode: host
    volumes:
      - /yourpath/smartstrm/config:/app/config # 挂载配置目录
      - /yourpath/smartstrm/logs:/app/logs # 挂载日志目录，可选
      - /yourpath/smartstrm/strm:/strm # 挂载 STRM 生成目录
      # 以上 /yourpath 改为你实际存放配置的路径
    environment:
      - PORT=8024 # 管理端口，可选
      - ADMIN_USERNAME=admin # 管理用户名
      - ADMIN_PASSWORD=admin123 # 管理用户密码

Three things are worth noting. The management interface is on port 8024, and the README says that after deployment you visit http://yourip:8024 to reach the admin backend. The network mode is host, which is what makes the 302 proxy feature possible, since the media server has to reach it without an extra hop. And the three mounted directories are config, logs and the strm output directory, with the logs mount marked optional.

The default admin credentials are in the example, admin and admin123, and the environment variable names are ADMIN_USERNAME and ADMIN_PASSWORD, so you would change them at deployment. The documentation points to a full deployment guide for more environment variables and techniques.

The five step setup, from adding a drive to a playing library

The user guide gives a five step sequence, and it is short enough to be worth quoting because it shows the intended shape of the deployment.

Step one is to add storage, connecting your Quark, 115 or WebDAV drive. Step two is to create a task, configure the scan path and generate the .strm files with one click. Step three is directory mapping, mounting the generated strm directory into the Emby container. Step four is scanning into the library, adding that directory in Emby and scanning it, and the README claims the library is populated almost instantly, which follows from the fact that only text files are read. Step five is the 302 proxy, marked as Pro, which configures the redirect so that video streams come straight from the cloud drive rather than the NAS.

The order matters more than it looks. The scan has to exist before Emby is pointed at the directory, and the media server has to be able to reach the generated files over the network, which is why the container runs with host networking. The 302 layer comes last because it changes how the media server fetches the actual stream, and doing that before the library is populated gains nothing.

The documentation set is linked in the README header and covers the project documentation, a quick deployment guide, a beginner tutorial, advanced usage around webhooks, a FAQ and a changelog. The webhook page in particular suggests the tool can be driven by events from other services, which is the natural extension of the save triggers a run model.

Closed source, and the terms that come with it

This is the part of the project that has to be read before anything else, and it is the main constraint on adoption.

The licensing section states that SmartStrm is a closed source project that stands on the shoulders of several open source libraries, and that the author respects and complies with their open source licence requirements, with the notice file linked from the README.

Three conditions follow. First, the project nature and purpose: the application aims to improve the efficiency of using network services through automation, does not involve cracking third parties, and only wraps and calls existing APIs, and to get the best experience the user still needs a paid plan on the relevant platform. Second, data sources and limits of liability: the data the application processes comes directly or indirectly from third parties, and the developer is not responsible for the legality, accuracy, integrity, security or any infringement of content users upload and store, with the user expected to assess and bear the risk. Third, non-commercial use and a ban on illegal use: the application is for personal study, research and exchange only, the developer prohibits any commercial use, and a user who uses it illegally bears all legal responsibility themselves.

Continuing to use the application is treated as full acceptance of those terms. The copyright line reads Cp0204, 2025 to present.

So the practical position is that this is a free binary distribution of a closed source application with non-commercial terms, distributed through Docker Hub and a Telegram channel, with a separate paid Pro tier sold through a licence server for the 302 proxy and the tutorial exchange arrangement. The repository itself contains no source code, only a README, a VERSION.md, a version.json, an open source notice, an img directory and a tools directory.

For a home lab, that is a reasonable trade. For anything commercial, and for an organisation with a procurement process, it is not, and the open source notice does not change that because it covers the libraries SmartStrm uses rather than SmartStrm itself.

Where this stops working, and what to use instead

There are limits that come from the architecture rather than from the implementation.

The first is that a .strm file is a pointer, not a copy, and every constraint of that follows. Your media server needs credentials for the cloud drive, or something in front of it does, and the access tokens for those accounts end up in your media server configuration. Deleting a file in the cloud drive does not remove it from the library unless the deletion linkage is configured, which is why the README lists synchronized deletion as a feature rather than assuming it.

The second is that the 302 proxy is a Pro feature, so the headline benefit in the project description, playback that does not use NAS bandwidth, is not in the free tier. Anyone evaluating it should be clear about which half they are getting.

The third is the dependence on third party APIs. The licensing section says so itself: there is no cracking, only wrapping and calling existing APIs, and the best experience requires a paid plan on the platform. That means a change in a provider's API, or the expiry of a subscription, can break the pipeline, and the closure is not under the project's control.

The alternatives differ in approach rather than in feature list. A direct cloud drive integration built into the media server avoids the pointer layer entirely, since the server talks to the drive itself, at the cost of depending on that server's support for your provider. A local cache or a mount that presents the cloud drive as a filesystem to the media server removes the .strm machinery and the 302 proxy in one go, at the cost of the local storage you were trying to avoid. And a traditional NAS library with the files on disk is the simplest thing that works, which is still the right answer for a large enough collection.

What SmartStrm is really for is the specific case where the content lives in a cloud drive you cannot easily mount, the media server is one of the listed ones, and copying everything locally is not an option. Outside that case, the closed source terms and the Pro split make it a harder sell than the alternatives.

On maintenance, the repository is not archived and the last push was on 2026-09-25, with releases v0.5.0 on 2026-09-25, v0.4.20 on 2026-09-08 and v0.4.19 on 2026-07-31. The primary language is recorded as Shell, which matches a container image with an entrypoint script, and the topic tags name the drives and servers it targets, including Emby, Jellyfin, Plex, OpenList, alist, 115, 123pan, quark, tianyi and fnos.

Editorial conclusion

Adopt SmartStrm if you keep media in cloud storage and want Emby, Jellyfin or Plex to index it without copying files to a NAS, and you are comfortable running a closed source container in your media stack. Do not adopt it for a commercial deployment or for a library you have to hand to clients, because the project states it is for personal study and exchange only. Verify first that the drives you want are supported, that the container can reach the media server, and that the licence terms in the repository match the use you have in mind.

Frequently asked questions

Official sources

1. Cp0204/SmartStrm on GitHub
2. Issues
3. Project website
4. README
5. Releases