Running a Jellyfin media library on a cloud drive, scanning all night without stopping? Switching to strm, a text file of several KB is equivalent to 4GB
last month, I imported Alibaba Cloud Drive into Feiniu, and that very night I did something impulsive: I added the mount directory directly to Jellyfin's media library, thinking the poster wall would be complete the next day. But the next morning, when I checked, the scanning progress bar was stuck at about forty movies, and it wasn't finished. On the TV, I opened the media library, and dozens of posters were scattered everywhere, with only black grids waiting to be swept in.
most heartbreaking is the data—when you open the cloud drive app, you see over 2GB downloaded from the cloud overnight. What I bought was a fake fix that didn't touch the local hard drive, basically using the speed limit of the cloud drive to buy a bunch of files that no one reads. This article will clearly explain the root cause of this pitfall and my solution. If you want to upload to the poster wall via cloud drive, don't do what I did on the first night.
let's start with the root cause: scanning the database isn't about looking at the file names; you have to read the top of every file
I always thought Jellyfin's browsing of media libraries was just a file list, matching posters on TMDB by name, and that was it. After checking the materials and staring at my own machine for a long time, I realized it wasn't the case: before each video file is stored, it uses FFPROBE to read the file header to clarify the packaging format, video encoding, audio track, subtitle track, duration, and other information. These are used for transcoding during broadcasting.
reading a file header from the local hard drive is a matter of milliseconds, so it doesn't matter. The mounting trays are different. I wrote in my about cloud drive mounting that OpenList mounts essentially have the NAS fetch data from the cloud drive for you, and the file header actually downloads several MB from the file header. A movie of a few MB isn't much, but in my home media library, local and cloud storage totaled 317 movies and 86 dramas. Each series required seven or eight files, totaling hundreds of files in the queue. What's worse, Jellyfin scans are read concurrently, with dozens of ffprobes hitting the mount layer at once. The cloud drive is limited in speed (I didn't buy the privilege pack, 16 threads only about 9MB/s), and the queue keeps getting longer.
so the scene that night was: scanning was waiting for downloads, downloads were being slowed, and the speed limit was due to too much concurrency—a vicious cycle. This isn't a Jellyfin bug, but a natural contradiction of using cloud drives as local drives for database sweeping—the more the file reading task, the more the cloud drive's traffic and waiting times.
What is
strm: a few KB equals 4GB of account
solution is quite unsophisticated: generate an STR file for each movie. It's just plain text, with the .strm extension, and only one line of text inside—the playback address for this movie. File names should follow the media library's specifications, for example, "Avatar (2009).strm" and placed under the "Movies/Avatar (2009)/" directory.
Jellyfin, Emby, and Kodi natively recognize strm and add it to the library as a media file. The key difference is this: during scanning, it only uses filename to scrape and match the poster and description, and doesn't actually open the address in the strm to read it again. In other words, previously, you had to read the actual number of MB of information from a 4GB movie before entering the database; now you only need to look at a 4KB file name. Hundreds of documents, just a matter of seconds.
the actual time to boost streaming on cloud drives is postponed to the moment you click play. The accounting in between is easy to calculate: during the database creation phase, the data goes from "hundreds of speed-constrained downloads" to "hundreds of local file name reads," and data drops from over two gigabytes to zero. When playing, the speed limit should still be limited (that's the of the benefit package, so the two videos don't count twice), but at least the movies you don't watch won't change a single byte.
Let me first manually verify three movies: a single line of command
Before
tools, I usually manually run the minimum closed loop and check whether this solution works in my home environment. A new catalog was created, three movies, each with two commands:
mkdir -p /vol1/1000/strm/movie/avatar\(2009\)
echo "http://192.168.31.10:5244/d/ Aliyun Drive/Movie/Avatar (2009).mkv" > /vol1/1000/strm/Movie/Avatar\(2009\)/Avatar\(2009\).strm
The string in
address is the direct link port format for OpenList, and 5244 is the port for my OpenList. I added this STRAM catalog to the Jellyfin media library, and in just a few seconds, the poster, synopsis, and cast list all appeared—because the scratch only showed the name "Avatar (2009)," which matched TMDB. When I play on the TV, the speed of the screen doesn't differ significantly from the local drive, because the player receives a 302 note from OpenList and pulls directly from the CDN on the cloud drive, without using my NAS's forwarding bandwidth. I verified this mechanism in the where I mounted it in .
After
three parts of verification, I felt relieved: the principle worked, and the rest was just the physical labor of batch generation.
batch production orders are made to AutoFilm, which address should be carefully selected
hundreds of handmade pieces are definitely unrealistic. There's a ready-made open-source tool called AutoFilm for this job, specifically for generating strm for Emby and Jellyfin, and Docker pulls it up with a single command. Its operating logic is: connect to your OpenList (or Alist), scan the directory you specify, batch load strm files locally according to the directory structure, and supports incremental scheduled task updates—if a new movie is saved on the drive, it periodically runs it again to add the new strm. The configuration is to fill in the OpenList address, account password, and which directory to generate. The specific format is clearly described in the repository's README, so just follow the instructions.
more important than the tool itself is what to write in the of the address line in the strm. After stepping on it, I summarized three ways to write it, and the differences are significant:
| address writing | how data flows during playback | my review |
| OpenList 302 port address | the player takes the 302 note and connects directly to the cloud drive CDN | the one I chose, NAS improper transit |
| local mount path | data is advanced to the NAS mount layer and forwarded to the player | NAS which requires bandwidth, and N100 is working overtime for nothing |
| cloud drives, bare direct links, | save a bit of a jump, but direct links have expiration timeliness—they expire after a few days | but the trade-off is that the entire inventory fails every few days, so don't use it |
The third method is that many tutorials online are written with quick images, but my attitude is to avoid them. Direct links are temporarily issued by cloud drives. Once the validity period expires, hundreds of strm files in your media library collectively become decorations. Using the OpenList interface address means that every playback is replaced with a new note in real time; the delay of half a second means no maintenance is needed.
three pitfalls and a group of people who shouldn't be messing with this
after running through, I hit a few smaller potholes, none of which were hard to fix, but knowing in advance saved me time:
the first is the file name Taye in cloud drive. The name "Avatar 2009 Blu-ray Chinese-English.mkv" is something TMDB probably can't recognize or misidentify, resulting in a mismatched poster. The advantage of strm is that renaming files costs zero—it's just a text file, renames without changing data, just rename it to the standard format of 'Name (Year)' and then rescan. When generating AutoFilm, you can also configure file name handling rules.
second is subtitle . strm is just a pointer; subtitles require your own figure: put the external srt next to strm with the same name, Jellyfin recognizes it; The embedded subtitle track of the source runs with the original file and is unaffected.
third don't put all your eggs on the cloud drive . The strm solution has an inherent weakness: when OpenList stops, the cloud drive interface changes, or accounts encounter issues, the entire media library instantly becomes hundreds of dead links, with not a single one available. My approach is mixed—local 4TB drives are kept for frequent viewing and those I can't bear to discard, cloud drives for Strm and Shuyu (random) ones, Jellyfin has one media library with two directories, poster walls look like one thing, and the storage below is two layers. By the way, strm takes up almost no space; 317 titles together take just over 1MB, and the storage pool account ( the I read from a 4TB drive) can completely ignore it.
As for who doesn't need to bother: If you're like the route I wrote in my about playing NAS movies directly on TV, occasionally opening the drive in the TV file manager to pick a single video without using the media library, then STR doesn't matter to you—direct reading is enough. It serves heavy usage of "wanting poster walls, continuing to watch, organizing by type." And for local server enthusiasts, local file scanning doesn't have the pain of this. Don't add an extra layer of abstraction just to chase trends.
finish with a sequence: first ensure the mount runs smoothly ( the previous ), manually create strm for three movies to verify address writing to confirm the TV can display images, then batch generate them in AutoFilm. Finally, combine local frequently watched movies and cloud drive strm into the same media library. Turning a few minutes into one night is the whole selling point of this solution.
