网盘挂载做Jellyfin媒体库，扫描一晚上没完？换成strm，几KB的文本文件顶4个G

上个月我把阿里云盘挂载进了飞牛，当天晚上就干了件想当然的事：把挂载目录直接加进Jellyfin的媒体库，想着第二天海报墙就齐了。结果第二天早上一看，扫描进度条卡在四十来部电影，没完。电视上点开媒体库，海报稀稀拉拉几十张，剩下全是等待扫入的黑格子。

更心疼的是流量——打开网盘App一看，一晚上从云上拉下来两个多G。我买的可是本地硬盘没动的假动作，等于花着网盘的限速额度，买了一堆没人看的文件头。这篇就把这个坑的病根和我的解法写清楚，网盘挂载想进海报墙的，别照我第一晚那么干。

先说病根：扫库不是看文件名，是每个文件都要读一遍头

我一直以为Jellyfin扫媒体库就是列个文件清单，按名字去TMDB匹配海报就完事。翻了资料又盯了自己机器半天才发现不是这回事：每个视频文件入库前，它要用ffprobe把文件头读一遍，搞清楚封装格式、视频编码、音轨、字幕轨、时长这些信息，这些是播的时候转码判断要用的。

本地硬盘上读个文件头是毫秒级的事，无所谓。可挂载盘不一样。我在网盘挂载那篇里写过，OpenList这类挂载本质是NAS替你去网盘拿数据，读文件头也得真实下载几MB过来。一部电影几MB看着不多，我家媒体库里本地加网盘加起来317部电影、86部剧，剧集一部七八个文件，全部算上大几百个文件排队。更要命的是Jellyfin扫描是并发着读的，几十个ffprobe同时砸向挂载层，网盘那边被限着速（我没买权益包，16线程也就9MB/s上下），队伍越排越长。

所以那晚的景象就是：扫描在等下载，下载在被限速，限速是因为并发太多，死循环。这不是Jellyfin的bug，是拿网盘当本地盘扫库的天然矛盾——读文件的活儿有多少，网盘的流量和等待就有多少。

strm是个什么东西：几KB顶4个G的账

解法说出来特别不高级：给每部电影生成一个strm文件。它就是个纯文本，后缀名.strm，里面只装一行字——这部电影的播放地址。文件名照着媒体库规范起，比如「阿凡达(2009).strm」，放在「电影/阿凡达(2009)/」目录底下。

Jellyfin、Emby、Kodi这仨都原生认strm，把它当一个媒体文件加进库。关键差别在这：扫描的时候它只拿文件名去刮削匹配海报和简介，不会去把strm里那行地址真的打开读一遍。也就是说，原来入库要读4个G电影里真实的几MB头信息，现在只需要看一个4KB文本的文件名。几百个文件，几秒钟的事。

真正去网盘拉流的时间点被推迟到了你点播放的那一刻。这中间的账很好算：建库阶段从「大几百次受限速的下载」变成「大几百次本地读文件名」，流量从两个多G变成零。播放的时候该限速还是限速（那是权益包的账，两篇不重复算），但至少你不看的电影一个字节都不会动。

我先拿三部电影手工验证：一行命令的事

上工具之前我习惯先手工跑通最小闭环，也顺便确认这方案在我家环境里到底成不成。新建了个目录，三部电影，每部两条命令：

mkdir -p /vol1/1000/strm/电影/阿凡达\(2009\)

echo "http://192.168.31.10:5244/d/阿里云盘/电影/阿凡达(2009).mkv" > /vol1/1000/strm/电影/阿凡达\(2009\)/阿凡达\(2009\).strm

地址里那串是OpenList的直链接口格式，5244是我家OpenList的端口。把这个strm目录加进Jellyfin媒体库，几秒扫完，海报、简介、演员表全出来了——因为刮削只看「阿凡达(2009)」这个名字，跟TMDB对上了。电视上点播放，画面出来的速度和本地盘没拉开明显差距，因为播放器拿到的是OpenList递过来的302纸条，直接从网盘CDN拉流，不走我NAS的转发带宽，这套机制我在挂载那篇里验证过。

三部验证完我就放心了：原理成立，剩下的就是批量生成的体力活。

批量生成交给AutoFilm，地址写哪种有讲究

几百部手工敲肯定不现实。这活儿有个现成的开源工具叫AutoFilm，专门给Emby和Jellyfin生成strm用，Docker一条命令拉起来。它的活儿逻辑是：连上你家的OpenList（或Alist），把你指定的网盘目录扫一遍，照着目录结构在本地批量落strm文件，还支持定时任务增量更新——网盘里新存了电影，它定期再跑一遍把新的strm补上。配置就是填OpenList的地址、账号密码、要生成哪个目录，具体格式它仓库README写得比我转述清楚，照着填就行。

比工具本身更值得想清楚的是strm里那行地址写什么，我踩完总结出三种写法，差别不小：

第三种是网上不少教程图快直接给的写法，我的态度是绕开。直链是网盘临时签发的，有效期一过你媒体库里几百个strm集体变摆设。走OpenList的接口地址等于每次播放实时换一张新纸条，慢那半秒换来的是不用维护。

三个坑，和一类不该折腾这个的人

跑通之后陆续又撞了几个小坑，都不难解但提前知道能省时间：

第一个是网盘里的文件名太野。「阿凡达2009蓝光国英双语.mkv」这种名字TMDB多半认不出或者认错，刮出来一部张冠李戴的海报。strm的好处是改文件名零成本——它就一文本文件，改名不动数据，把名字修成「名字(年份)」的规范格式再重扫这一部就行。AutoFilm生成的时候也能配置文件名处理规则。

第二个是字幕。strm只是个指针，字幕得自己想办法：外挂srt放到strm同名旁边，Jellyfin认；片源内嵌的字幕轨跟原文件走，不受影响。

第三个是别把鸡蛋全放网盘里。strm方案有个先天软肋：OpenList停了、网盘接口改了、账号出问题了，整个媒体库瞬间变几百个死链接，一部都放不出来。我的做法是混合——本地4T盘放常看和舍不得丢的，网盘strm放冷门和随缘的，Jellyfin里一个媒体库挂两个目录，海报墙看起来是一家，底下的存储是两层。顺带一提，strm几乎不占空间，317部加起来1MB出头，存储池那本账（我翻4T盘的那篇）可以完全把它忽略。

至于哪些人不用折腾：如果你跟我在电视直接播NAS电影那篇里写的路线一样，偶尔在电视文件管理器里点开挂载盘挑一部看，压根不用媒体库，那strm对你没有意义，挂载直读就够了。它服务的是「要海报墙、要继续观看、要按类型整理」的重度用法。还有本地盘党，本地文件扫库本来就没这些痛苦，别为了赶时髦多加一层抽象。

收尾给个顺序：先把挂载跑稳（上篇的功课），拿三部电影手工建strm验证一遍地址写法，确认电视上能出画面，再上AutoFilm批量生成，末了把本地常看片和网盘strm并进同一个媒体库。一晚上变几分钟，就是这个方案全部的卖点。