玩 NAS 的人绕不开一个场景硬盘里躺着上百部电影文件夹名字五花八门有的带着字幕组标签有的干脆就叫10101.mkv。打开 Emby 或者 Jellyfin 一看海报全是灰块标题识别成乱码剧集顺序更是惨不忍睹。这个问题的标准解法就是刮削。刮削Scraping就是从 TMDB、TVDB 这些元数据源抓取海报、简介、演员、评分再配合本地 NFO 文件让播放器正确展示。今天要讲的是我用下来最顺手的本地刮削神器 tinyMediaManager下面一般直接叫 tMM。这篇文章会把 tMM 的部署、配置、实操、NFO 原理、媒体服务器联调以及常见坑一次性讲透适合刚入 NAS 影视库、也被刮削搞到头秃的朋友。1. 为什么影视库需要单独的刮削工具1.1 媒体服务器内置刮削的坑很多人一开始会觉得既然 Emby、Jellyfin、Plex 都有自动刮削功能为什么还要单独装一个 tinyMediaManager我最初也是这么想的直到被内置刮削反复折腾了几次才明白问题在哪。内置刮削最大的毛病是“各自为政”。你在 Emby 里刮好的海报和简介换到 Jellyfin 里又要重新刮一遍几个海报参数不一致、简介版本不一样看着也别扭。更麻烦的是内置刮削一旦匹配失败你想手动修正很费劲。比如一部冷门老片Emby 扫出来匹配错成同名电影你在网页端改半天过几天全量刷新媒体库它又给你扫回错误版本。另一个隐患是重复网络请求。媒体服务器每次扫描库都要向 TMDB、TVDB 这些站点发起请求如果库很大刮削一次要跑很久中途断网或者请求超时图片下载一半、NFO 写一半留下各种半成品文件。我见过不少人的媒体库目录里有一堆.nfo空文件、零字节poster.jpg就是中断造成的。说到底媒体服务器内置刮削更适合“小库、偶尔加一两部片子”的情况。一旦你的影视库超过一百部、还有长剧集就非常需要一套独立的、可控的元数据管理方式。1.2 tinyMediaManager 的定位tinyMediaManager 是一个开源、跨平台的本地媒体库管理工具。它本身不负责播放也不接管你 NAS 上的媒体文件索引它只做一件事把电影、剧集的元数据海报、简介、演员、评分等整理好生成标准的 NFO 和图片文件放到对应的媒体目录里。你可能会问这和媒体服务器刮削有什么区别区别在于数据所有权的归属。tMM 刮出来的元数据是“落地”的以文件形式存在不依赖任何特定播放器。今天用 Emby明天换 Jellyfin后天改成 Kodi只要这些软件开了“优先读取本地 NFO”就能直接复用同一套海报和简介不用重新刮。这个思路在影视库大到一定程度以后真的能省下大量时间。tMM 的优势还体现在手动纠错上。它对匹配错误的容错率很高你可以搜索影片原名自己选年份甚至直接填 TMDB ID 或 IMDb ID。相比在媒体服务器网页端里找半天下滑菜单tMM 的桌面界面和批量操作要顺手得多。2. 安装与初始化两种典型部署方式2.1 Docker 还是桌面版怎么选tinyMediaManager 官方其实是提供桌面客户端的Windows、macOS、Linux 都能装。但 NAS 用户通常更喜欢用 Docker 跑一个长期运行的实例。这两种方式各有适用场景我建议你这样判断。如果你只是想把现有的乱糟糟文件整理一遍先在电脑上装一个桌面版通过 SMB 或 NFS 挂载 NAS 的共享目录刮好之后再让媒体服务器扫描这个流程最简单界面响应也快。如果你希望以后每次下载完新片tMM 能自动监控目录并完成刮削那 Docker 版更适合它就是驻留在 NAS 里的一个常驻服务。以 Docker 方式为例社区维护的镜像不少我这里给出一个常见的 compose 写法具体镜像和版本请按你 NAS 平台实际情况确认services: tinymediamanager: image: romancin/tinymediamanager:latest container_name: tmm environment: - PUID1026 - PGID101 - TZAsia/Shanghai - USER_ID1026 - GROUP_ID101 - ENABLE_WEBUItrue - WEBUI_PORT8080 volumes: - /path/to/tmm/config:/config - /volume1/movie:/media/movie - /volume1/tv:/media/tv ports: - 8080:8080 restart: unless-stopped注意几个地方PUID和PGID要换成你 NAS 上用于媒体目录写入的用户 ID否则 tMM 生成的 NFO 和图片文件可能出现权限不对Emby 那边无法读取/config目录用于保存 tMM 自身的数据库、设置和图片缓存务必映射出来否则容器一重建设置全没了。2.2 元数据源设置与 API KeytMM 默认使用 TMDB 作为主要元数据来源剧集还可以配合 TVDB。首次启动后第一件事就是把语言和地区设置好界面语言选“中文简体”媒体元数据语言也选“中文简体”地区可以根据你下载的片子偏好来定。API Key 这块我多说一句。tMM 内置了一个公共请求 Key可以直接用但请求次数有限如果刮削量大容易遇到限流。建议你去 TMDB 官网注册一个开发者账号申请免费的三级 API Key填入 tMM 的“设置 - 元数据”页面过程不复杂但后续刮削会稳定很多。剧集如果依赖 TVDB 的额外信息也可以配置 TVDB 的 API Key。这里也要说明一个现实问题TMDB 和 TVDB 都是海外站点NAS 所在网络如果访问这些站点响应很慢刮削就会频繁超时。遇到这种状况先别急着质疑工具先检查 NAS 的 DNS 是否正常、能否稳定访问站点。网络波动导致的失败通常重试就能解决如果是大量图片下载中断可以在 tMM 里调大超时时间或者把刮削时间安排在凌晨这种网络空闲时段。3. 刮削实操从文件命名到海报落地3.1 文件命名规范刮削的第一道门槛tMM 再强也怕文件名乱来。刮削匹配最主要的依据就是文件名里的“标题 年份”和“剧集名 季集信息”。命名不规范神仙工具也得靠手动匹配。我的个人标准很简单。电影资源最好保证是这种格式之一阿凡达 (2009).mkv Avatar.2009.1080p.BluRay.x264.mkv如果一部电影有不同版本我建议放在独立子文件夹里然后用电影名 (年份) - 1080p、电影名 (年份) - 4K这类后缀区分tMM 和 Emby 都能识别成同一部电影的多版本。剧集的标准结构是这样的老友记 (1994) ├── Season 01 │ ├── 老友记 S01E01.mkv │ ├── 老友记 S01E02.mkv └── Season 02 └── 老友记 S02E01.mkv特别提醒有些下载文件会把发布组标签放在最后例如Friends.S01E01.2160p.WEB-DL.DDP5.1.x264这类命名 tMM 也能识别但如果你还在文件名里加了“精校”“国语”这种非标准词汇建议至少保证S01E01这种季集标记存在。否则 tMM 会把整季当成孤儿资源匹配错乱。3.2 添加目录并完成自动匹配我在 tMM 里的操作路径是这样的左侧导航先切到“电影”或“剧集”标签页然后在设置里添加数据源。数据源指向 NAS 上对应的共享目录。如果你在电脑上用桌面版就指向挂载盘符在 Docker 容器里就指向刚才映射的/media/movie路径。添加完成后点击工具栏的“更新数据源”tMM 会扫描目录中所有影视文件并和自己的本地数据库比对。接着执行“抓取新影视”或“抓取新剧集”tMM 会用文件名自动搜索 TMDB。这一轮自动匹配的成功率完全取决于你前一步的命名质量。如果你严格按“标题 (年份)”来命名匹配率基本能在九成以上。剩余匹配不上的大多是需要手动处理的特殊情况。3.3 手动匹配与元数据微调右击匹配错误的电影选择“搜索并抓取”。在弹出的搜索框里输入标题最好带上年份。如果片名有多个比如大陆译名和台译名差异很大可以先用英文原名搜再在结果里挑对海报和简介。更稳妥的方式是在搜索框里直接输入 TMDB ID比如19995就是《阿凡达》这样 100% 不会错。匹配成功之后tMM 会把可编辑字段列出来标题、原名、年份、简介、类型、导演、演员、IMDb ID 等。你在这一步可以顺手把中文片名改得更顺眼把简介里不合适的段落修掉甚至自定义排序标题。对于电影合集我习惯在“影视库”里把续集关联起来对于多版本资源我会在“电影版本”里手动关联方便 Emby 播放器上出现“播放其他版本”的入口。剧集方面tMM 会把每一季、每一集都展开。如果某一集文件编号错了你可以右键选中手动填入正确的季数和集数然后重新抓取该集信息。处理完这些点击保存tMM 会立即生成对应的 NFO、poster、fanart 等文件。3.4 文件重命名与整理策略很多人的影视目录混乱不只是元数据问题连文件名和文件夹本身都想统一。tMM 内置了“重命名器”可以在设置里定义模板比如电影$title ($year)/$title ($year) 剧集$title ($year)/Season $season/$title - S$seasonE$episode重命名器运行前它会先做一次模拟预览我把这个功能当成安全网凡是预览里出现“红色确认”的条目我都会先点开看看确认不会把文件移错位置才真正执行。操作上还有一个非常重要的坑如果你的资源是从 PT 站或公网 BT 下载的并且还在保种做种重命名或移动文件会导致做种失效。遇到这种情况要么先停用任务再整理要么在 tMM 的重命名设置里选择“软链接方式”把生成的链接文件整理到媒体库原始文件留在种子目录里继续做种。这个技巧在混迹各种资源站的老玩家里几乎是标配。4. NFO 文件与元数据管理机制4.1 NFO 到底是什么NFO 本质上是一个 XML 文件媒体服务器通过它读取影片元数据。不要和电影发布组附带的那些说明文件.nfo混淆这里的 NFO 是刮削工具自己生成的里面存的是标题、简介、年份、流派、评分、TMDB ID、IMDb ID以及海报、背景图文件名。下面是一个典型的电影 NFO 片段?xml version1.0 encodingUTF-8 standaloneyes? movie title阿凡达/title originaltitleAvatar/originaltitle year2009/year tmdbid19995/tmdbid imdbidtt0499549/imdbid plot战斗中负伤而下身瘫痪的前海军战士杰克来到潘多拉星球…/plot runtime162/runtime genre动作/genre fanart thumbfanart.jpg/thumb /fanart /movie媒体服务器扫描时如果当前目录下存在movie.nfo并且你设置的是“本地元数据优先”它就不会再向 TMDB 发请求而是直接读这个文件。剧集的 NFO 结构会多一些嵌套里面有episodedetails、seasondetails这类标签但原理是一样的。4.2 为什么推荐 tMM 生成 NFO而不是手动编辑手动编辑 NFO 看起来很简单实际上很容易踩坑。最常见的是编码问题有人用记事本直接编辑保存成了带 BOM 的 UTF-8或者干脆变成 UTF-16媒体服务器解析到一半就断了。另外字段名写错一个字母就直接导致整部影片信息失效。比如把tmdbid写成tmdb_idJellyfin 可能就不认。所以我的建议是日常操作全部交给 tMM 生成它写出来的 NFO 格式经过大量播放器验证兼容性最好。手动编辑 NFO 只适合两种情况一是批量修正繁殖性的错误比如一部合集电影的年份想批量改成发行年份可以用脚本正则替换二是某些冷门影片的简介想自己写一版更好的文字可以直接在 tMM 编辑后重新保存不用自己手写全套 XML。真正需要小心的反而是 tMM 生成 NFO 的“时机”。当你用外部脚本或文本编辑器改动过 NFO 之后一定要回到 tMM 里执行“更新数据源”否则 tMM 的内存数据库和磁盘 NFO 不同步下一次抓取会把你的手动修改覆盖掉。4.3 图片管理与本地化tMM 可以下载多种尺寸的图片常见的有 poster竖版海报、fanart宽版背景、banner横幅、logo标志等。在设置里可以指定图片大小和是否同时下载多种语言版本。对于家庭 NAS 来说poster 和 fanart 基本就够用。如果你想让海报更好看tMM 支持 fanart.tv 的 API Key。配置之后它可以从 fanart.tv 拉取更统一风格的美工图比 TMDB 默认图质量高不少。设置很简单在 tMM 设置里填入 fanart.tv 的 Personal API Key然后在抓取选项里开启对应图片类型。有一点经验之谈同一部电影不同来源的中文海报视觉效果差异很大。如果你很在意墙上的“海报墙”观感可以在 tMM 的图片预览里手动挑一张最喜欢的再保存。不要全部用自动抓到的第一张搭配好的海报墙观感能提升一个档次。5. 与 Emby / Jellyfin 的联调5.1 让媒体服务器优先读取本地 NFOtMM 刮削完只是第一步真正展示还是靠 Emby、Jellyfin 这类媒体服务器。如果服务器配置不对它会无视本地 NFO又跑出去联网抓一遍那你前面做的所有工作就白费了。以 Emby 为例在媒体库设置里找到“高级”部分把“优先使用本地元数据”打开然后把“元数据读取器”的顺序调整一下把 NFO 相关的读取器放到最前面把联网的 TMDB 读取器放到最后甚至可以直接关闭联网抓取。这样 Emby 扫描时先读movie.nfo、tvshow.nfo、season.nfo本地没有的信息才会去联网补充。Jellyfin 的设置路径类似媒体库高级设置里把 Linux/macOS 的 Nfo 读取器勾选上拖到最上方同时把“自动从互联网抓取缺失的元数据”选项关掉。Plex 对本地 NFO 的支持相对弱一些但也能通过高级设置里的“Prefer local metadata”来开启。5.2 目录结构与权限匹配一个让我折腾最久的点是权限。Docker 里的 tMM 和 Emby 容器各自有独立的 UID/GID如果它们不能读取彼此生成的文件就会出现“tMM 写入的 NFO 在 NAS 里看得见但 Emby 容器权限不足读不了”。我建议所有涉及媒体目录的容器统一使用同一组 UID/GID。比如在群晖上我专门建了一个media用户UID 是1026所有容器环境变量里的PUID和PGID都写成1026:101并把媒体目录的属主递归改成这个用户。这样 tMM 写入的 NFO、Emby 读取时完全无障碍。目录结构我习惯这样组织/volume1/media ├── movie │ └── 阿凡达 (2009) │ ├── 阿凡达 (2009).mkv │ ├── movie.nfo │ └── poster.jpg └── tv └── 老友记 (1994) ├── tvshow.nfo ├── Season 01 │ ├── 老友记 S01E01.mkv │ └── 老友记 S01E01.nfo └── fanart.jpg注意电影目录下最好直接放一个movie.nfo剧集根目录放tvshow.nfo季目录下每集放剧集文件名.nfo这样每个播放器都能准确定位。tMM 默认就是按这个规则生成的但如果你自己移动过文件就要再跑一次更新。5.3 媒体库扫描策略tMM 和 Emby 各自都有扫描机制配合不好容易造成资源占用过高。我的策略是tMM 负责“新增和修改”Emby 只负责“展示和增量刷新”。也就是新片下载后触发 tMM 抓取tMM 保存 NFOEmby 每隔半小时扫一次媒体库目录这时只读本地 NFO速度非常快不会发一堆联网请求。如果你的 NAS 性能一般不建议 tMM 和 Emby 同时执行全量扫描。可以给 tMM 设置一个定时任务每天凌晨更新一次数据源Emby 的自动扫描间隔也错开一两小时。另外tMM 自带“目录监控”功能开启后检测到新增文件就自动刮削体验会好很多。6. 常见问题与排查技巧实录6.1 高频问题速查表下面是我在实际使用中遇到过的典型问题整理成表问题可能原因解决办法刮削出来的简介是英文元数据语言设置不是中文设置里把语言改成“中文简体”重新抓取电影匹配到错误条目文件名年份缺失或错误手动搜索时带上准确年份或用 TMDB ID 精确定位剧集集数对不上文件名 S/E 标记不规范改名时确保保留S01E01结构再手动修正集号海报显示黑块图片未下载完整或权限不对删除 poster 文件重抓图片检查容器 UID/GIDEmby 不读 NFO读取器顺序错误或禁用了本地元数据按 5.1 节调整设置NFO 中文乱码文件被错误编码保存重新用 tMM 保存元数据不要用记事本直接编辑刮削中途失败留下半成品文件网络超时或 API 限流错峰操作调大超时检查网络连通性重命名后发现种子做种失效直接移动了做种中的文件使用软链接整理方案或先停种再整理API Key 请求次数超限公共 Key 被多人使用注册个人 TMDB Key 并填入 tMM电影有多版本但播放器只显示一个未在 tMM 中关联版本编辑影片在“电影版本”中添加其他文件6.2 两个容易忽略的隐藏坑第一个隐藏坑是“刮削后没点保存”。很多新手在 tMM 里匹配完信息看到右侧预览正常就直接关掉了结果什么都没写进 NFO。tMM 的抓取操作默认不会自动写入硬盘你必须在编辑窗口点击“保存”或者用批量操作里的“写入 NFO 与图片”。如果不确定可以到媒体目录里看有没有生成movie.nfo。第二个隐藏坑是“多个工具同时写同一个目录”。比如你一边开着 tMM一边打开了 Emby 的“将图片策略改为覆盖”两边的行为可能会互相覆盖。更糟的情况是 tMM 和另一台电脑上的刮削工具同时操作同一个媒体库导致 NFO 文件被反复改写、媒体服务器频繁刷新。建议一个媒体库只由一台机器上的一个刮削工具负责写入其他播放器只读。6.3 我的避坑习惯最后分享几个我用下来非常受益的习惯。第一每次给媒体服务器大版本升级前先在 tMM 里执行一次“更新所有元数据”确保磁盘上的 NFO 是最新状态。第二不要过度依赖 tMM 的数据库文件它只是一个索引真正要紧的是散落在目录里的 NFO 和图片所以定期清理那些没有 NFO 的“孤儿文件”很重要。第三新片入库后先别急着做全量扫描让 tMM 抓完、确认匹配无误再触发 Emby 刷新误差最小。我从最早用群晖 Video Station 一路换到 Emby最后固定在 tMM Jellyfin 这个组合。整体体会是影视库维护最怕的不是文件多而是元数据不稳定。只要你肯花一个下午把文件命名规则和 tMM 的抓取流程理顺后面的日子会非常省心。最后再分享一个小技巧如果你的剧集中途换过一次片源文件名从S01E01变成了一集一个文件夹或者集数错位最省事的办法是在 tMM 里把整部剧的 NFO 和演员图片目录删掉重新抓取一次不要试图一集一集手动纠偏那样反而容易把数据库搞得一团糟。