刮削：元数据、海报与剧集识别

命名规范落实之后，刮削就是水到渠成的事。本篇解释 Jellyfin 的刮削机制：数据源怎么配、扫描怎么跑、识别错了怎么改，以及让海报墙长期整齐的几个习惯。

一、数据源与语言配置

Jellyfin 刮削时按媒体类型查询不同数据源：电影查 TheMovieDb（TMDB），剧集查 TheTVDb，音乐查 MusicBrainz。配置入口在控制台的“媒体库”设置里，每个库可以分别指定元数据下载来源与语言优先级。

语言设置的关键是“显示语言”与“原始语言”的组合。中文环境习惯这样配：条目名称与简介优先中文，缺失时回落原文。评分与演员资料不随语言变化，多数欧美剧集的中文简介靠社区维护，质量参差属于常态，介意的话可以在个别条目上手动修订。

本篇的结构顺序也由数据源决定：先把它放在最前面介绍，因为整库扫描的成败最大程度取决于这一层。配错语言最多是显示别扭，配错来源却是全库识别失败。

数据源连接偶尔会抽风：数据源站点临时维护或网络波动时，扫描会静默跳过下载环节，识别出的条目仍然出现但海报空缺。定期检查一下海报墙的灰色占位比例，忽然增多时手动触发一次扫描重试即可，这不是你本地的问题。

刚建库的玩家常问一个顺序问题：先配数据源还是先加库扫描？答案是先配数据源。加库扫描是一次性消费大量数据源请求的操作，语言与来源若先配错，扫出来的几百分条目要逐个修，不如花两分钟先设置好再开始。库加错了也能改库级设置，但已写入的元数据不会自动按新设置重来。

二、扫描与匹配过程

一次正常的媒体库扫描分四步：遍历目录找到候选文件、按命名规则解析片名与编号、向数据源发起查询、把结果写入本地配置目录。这四步对应四个可能的故障点，识别失败时可以对号入座。

扫描有两种触发方式：手动扫描整个库或只扫描新增内容。媒体量上千的大库，全量扫描一次可能要几十分钟，所以日常依赖增量扫描；只有怀疑元数据大面积出错时才需要全量重扫，并配合“清除元数据”选项重来。

扫描背后还有一个机制值得知道：Jellyfin 默认会监听媒体目录的文件变化，新文件落进去之后通常不需要你点任何按钮，稍等几分钟海报墙就自动多出一格。这个行为对下载工具直落媒体的场景非常友好，但也意味着下载中的临时文件有可能被扫成半成品条目——下载目录与媒体目录分开，是避免这个尴尬的简单办法。

定期的全库扫描也建议保留一个习惯：每季度手动触发一次“扫描全部媒体库”，顺手清理残余的空条目与已删除文件的幽灵。这个动作五分钟做完，却能让海报墙与实际文件永远保持一致，是低维护运转的固定节奏之一。

三、识别失败的修正

最常见的修正场景是“匹配到了错误条目”。在条目详情页的“识别”设置里，可以搜索正确片名并永久绑定到指定编号（TMDB 编号或 TVDB 编号）。绑定之后无论文件名怎么变，这个条目都认准这个编号，相当于给刮削器一个确定的答案。

第二常见的是海报不理想。条目的“图片”管理里可以上传本地图片、从数据源候选图里换一张，或调整主图。Jellyfin 支持每个条目存多张图（海报、横幅、缩略图、背景），客户端按类型自动选用。

手动修订的优先级规则值得单独记住：本地内容永远大于在线数据源。这意味着你手动绑定的编号、替换的海报、编辑的简介都不会被下一次扫描覆盖，这是 Jellyfin 刮削体系里最重要的一条规则。反过来，如果你发现某条目一直匹配错，记得先手动锁定再修改，否则下次扫描又会被数据源带偏。

第三个常见问题是连不上数据源：打开控制台的“数据源”配置页，检查电影与剧集对应的 TMDB、TheTVDb 是否可达。国内网络环境下这两个站点的访问质量并不稳定。如果整库大面积识别失败，先怀疑这一层而不是怀疑自己的命名——数据源连通性是最先该排查的因素。社区里常见的应对是给 Jellyfin 容器配置可用的解析与网络出口，具体做法属于网络范畴，《软路由指南》 与 《OpenWrt 必备》 有网络层的铺垫。

数据源问题还有一个特征可以帮助判断：它是阵发性的。今天扫描全失败、明天又能成功八成属于网络波动；如果连续一周识别率稳定为零，更可能是容器内的网络配置或域名解析问题。记录下每次扫描的结果再判断，比拍脑袋换设置靠谱得多。顺手在控制台看看“最近任务”里的扫描日志，失败原因往往直接写在记录里。

四、剧集与分季的几个深坑

剧集识别比电影复杂，坑集中在三个地方。其一是播出顺序与DVD顺序：部分海外剧集的播出集序与发行版集序不同，TheTVDb 提供两种排序，选错季内集序就全错。其二是特别篇：特别篇、圣诞特辑等非正式剧集放在 Season 00 下用 S00Exx 编号，混在正式季里会导致季集数错乱。其三是年番与季间间隔：长寿剧集跨季时的命名分裂（比如同一剧名的多部作品）需要靠年份区分。

再展开一点剧集整理的实操：一季文件夹的内部结构越统一越好，连续剧用 SxxExx、特殊集归 Season 00、番外短期合集单独一个目录。不少玩家会在剧集库建好后特意检查一遍每季集数与播出页面对得上，一次核对能避免之后一整季的观看错乱。家庭共用的库尤其值得做这个检查——家人不会来报告集数好像不对，他们只会默默看到错的集。

五、让海报墙长期整齐

刮削是长期工程，几个小习惯性价比很高：新增媒体后立刻检查识别结果，当场修正成本最低；把常用系列整理成合集（比如漫威系列、宫崎骏合集），海报墙浏览效率显著提高；冷门作品直接配合上一章说的本地 NFO 与海报图，不依赖在线数据源的运气。

还有一个常见误区：频繁重新扫描解决不了识别问题。识别错的根源在命名或数据源，重扫一百遍还是同一个错误答案。正确的动作链是：看症状、判断原因（命名/绑定/数据源）、对症改正、最后再扫描。这四步的顺序不能颠倒，否则只会浪费大库的扫描时间。

还可以给每个库设置“首选图片语言”与“默认元数据语言”，整库一次性成型，避免逐条手动改。命名规范一旦固化，新增媒体按模板照抄，之后扫描基本是零交互的自动过程。刮削与目录、命名三者构成了媒体库的“地基”，这三件事做到位，后面客户端与远程观看都是顺水推舟。存储与目录的具体搭建，可参考 《NAS 自建指南》 的文件共享部分；群晖用户对照 《群晖 DSM 指南》 的共享目录与权限章节会更顺畅。

对合集与多人共用的库再补一句：Jellyfin 的合集是海报墙的“第二级组织”，适合主题系列与导演合集；家庭成员各自独立的观看进度则由用户系统处理，两件事互不干扰。多用户的具体玩法见第三章。

刮削这件事的回报曲线很有意思：前期投入大、后期近乎隐形。命名规范、数据源配置、手动锁定关键条目，这些工作做完之后，新增媒体时系统自己就能把海报、简介、集数排得整整齐齐。反过来，如果前期偷懒，后面每加一部片都要手动修一遍，维护成本永远降不下来。

最后给一个识别率自测的方法：往库里新建一个测试目录，放五部冷门影片，按规范命名后扫描。五部全部识别成功，说明你的命名与数据源配置处于健康状态；识别出三到四部，属于数据源覆盖的正常缺口；只识别出一两部，就需要回到命名或网络层面排查了。这个小实验做过一次，以后心里就对自己库的识别能力有数。

把第四章故障排查的思路提前用在这里：识别问题先分“命名错”、“数据源错”与“绑定错”三种，分别对应改名重扫、换数据源、手动指定编号三种修法。养成先分类再动手的习惯，刮削相关的麻烦会减少一多半。

刮削与命名、目录共同构成媒体库的地基，三件事的边界值得再厘清一次：目录决定库的类型边界，命名决定识别准确率，刮削决定展示效果。三者顺序也不能颠倒——先把文件放对地方，再让名字说得清楚，最后才轮到海报与简介的精修。地基稳固之后，海报墙最终的好坏差异，只在数据源运气与手动修订的投入上，这一篇也就完成了它的使命。

延伸阅读

• 命名规范的具体写法见本篇目录规划一篇；
• 字幕的获取与挂载见本篇字幕一篇；
• 海报墙的整理与修订见第四章相应篇目。