最近在看动漫，每一季都有几百集，如果缺少几集不太容易发现。
希望增加一些功能，来检查是否缺少集数。
我觉得你可以在你的媒体服务器中检查它们。
我并不觉得这是一个好主意，其他软件都有的功能，怎么到这里，就是要在媒体服务器来检查呢？我们通过直连连接网盘服务的，就低贱一些呗？
Hi @james,
I’m circling back on my forum post from a while ago, which has remained unanswered so far. I’m not sure if it slipped through the cracks or if this is simply not a priority for the team — but either way, I’d appreciate some clarity.
Could you please take a look and let me know if this is something that might be implemented in the foreseeable future? If the answer is no, I’d rather hear it straight so I can adjust my expectations accordingly.
A brief reply would mean a lot. Thanks.
能否说明一下您希望在这里看到什么内容？
例如，如果您拥有100集中的99集，而第65集缺失，那么Infuse会在这里显示什么内容？
剧集库完整性提示功能
一、需求背景
Infuse 当前对电视剧集的管理以“季”为单位进行展示，但缺少“该季应有总集数”与“本地实际拥有集数”的对比提示。
对于使用 WebDAV、阿里云盘、SMB 等直连协议的用户而言，文件目录完全由用户自行维护。当某一季有数百集时（如《海贼王》超过 1000 集、《名侦探柯南》超过 1100 集），手动核对缺失哪几集几乎是一项不可能完成的任务。用户往往要播放到某一集时才发现文件不存在，体验割裂。
更隐蔽的问题在于：当用户启用“自动播放下一集”功能时，播放器会无缝衔接到下一集，用户极少主动关注右上角的集数编号。若缺失的是某一集而非整季，系统会直接跳过——缺一集时，用户看到的是第 104 集结束后自动播放第 106 集，中间没有任何提示。对于剧情连贯的作品，用户可能会因“剧情接不上”而察觉；但对于单元剧（如《哆啦A梦》《银魂》《黑镜》等每集独立成篇的作品），观众几乎不可能发现少了一集。他们只会觉得“这一季好像短了点”，然后就此翻篇，永远不会知道自己错过了什么。
以下是两个典型场景，用以说明当前体验的不足：
场景一：单元剧的“沉默缺口”
用户 A 是一位《哆啦A梦》爱好者，通过阿里云盘直连 Infuse，存放了水田版动画某季共 156 集。实际目录中缺失了第 89 集和第 112 集（均为独立单元故事）。用户 A 每晚睡前看 3-4 集，启用自动播放。
第 88 集结束 → 自动播放第 90 集，两集剧情毫无关联，用户毫无感知。整季看完后，用户 A 的观感是“这季好像少了点东西”，但说不清具体少了什么。直到某天在论坛看到别人讨论第 89 集的剧情，才意识到自己根本没看过这集——而此时已经过去了两个月，网盘资源早已失效。
场景二：长篇连载的“中断式追番”
用户 B 正在追《海贼王》和之国篇，网盘里存了第 890 到 1085 集，但缺失第 1032 集（关键战斗回）。用户 B 从第 890 集开始连续自动播放，每天看 10 集。到达第 1031 集时，路飞刚进入最终形态；1031 集结束后，自动播放跳到了第 1033 集，剧情已经切换到其他战场。
用户 B 隐约觉得“怎么跳了一段”，但受限于对日语原文的不熟悉和字幕组翻译风格的差异，他以为是剧情留白处理。继续看了 50 集后，在某次贴吧讨论中才发现自己漏掉了整场关键战斗，但此时网盘里该文件已无法补档。
场景三：缺失多集的“累积损失”
用户 C 存放了某季共 100 集，实际缺失 8 集（第 17、34、56、67、78、82、91、94 集）。在自动播放模式下，这 8 次跳转分布在数十小时的观影过程中，每次间隔数小时甚至数天。用户 C 几乎不可能通过人工记忆来还原缺失名单，最终结果是“看完了一整季，实际上漏掉了近 10% 的内容”而不自知。
上述三个场景共同指向一个问题：用户并非不愿意补全资源，而是根本不知道自己缺了什么。播放器作为内容消费的最后一环，是最适合承担“完整性提示”这一职责的位置——它拥有最多上下文信息（已刮削的元数据 + 本地文件索引），也是最贴近用户观影行为的节点。
二、需求目标
在 Infuse 的“季（Season）”详情界面中，以轻量、非侵入式的方式，直观展示该季的集数完整性状态，帮助用户在观影前快速评估资源完备性，在观影中及时察觉缺口。
核心目标：
-
用户打开任意季详情页，3 秒内即可判断该季是否完整。
-
若缺失，用户可一目了然知道缺了哪几集，无需手动翻目录比对。
-
避免用户因自动播放的“无缝体验”而错过缺失集数，导致追番不完整。
三、具体功能说明
3.1 展示位置
位于“季”详情页的剧集列表顶部，即当前显示季名称、简介、播放按钮的区域下方，剧集网格/列表上方。该位置处于用户浏览剧集时的天然视线焦点，无需刻意寻找即可接收信息。
3.2 展示内容
以一行简洁的状态条呈现，包含以下信息：
| 元素 | 说明 | 示例 |
|---|---|---|
| 集数状态 | “已有集数 / 总集数” | 已有 97 / 总 100 |
| 完整性标识 | 完整（绿色圆点/对勾）或不完整（橙色圆点/警告图标） |  不完整 |
| 缺失概要 | 缺失数量及首尾缺失区间（数量少则直接列出） | 缺失 3 集：第 65、78、99 集 |
| 展开详情 | 点击状态条可展开完整缺失列表（可选交互） | 点击后展示全部缺失集数，并可一键复制 |
3.3 状态定义
| 状态 | 判定条件 | 视觉风格 | 典型场景 |
|---|---|---|---|
| 完整 | 已有集数 = 总集数 | 绿色 · 显示 ✓ 完整 | 用户已完成资源收集 |
| 部分缺失 | 1 ≤ 缺失数 ≤ 总集数的 20% | 橙色  显示缺失集号 |
下载时漏了几个文件 |
| 大量缺失 | 缺失数 > 总集数的 20% | 红色 显示缺失数量及区间 |
仅下载了部分剧集，尚未补齐 |
3.4 数据来源
-
总集数：优先使用 TMDB/TheMovieDB 返回的该季
episode_count字段。若 TMDB 无数据，可降级使用 TVDB 或用户手动输入（长期可考虑）。 -
已有集数：直接读取 Infuse 本地索引中该季已扫描到的文件数量及具体集号（
episode_number）。 -
缺失列表：对总集数集合
{1, 2, ..., N}与已有集号集合取差集。
3.5 边界情况处理
| 场景 | 处理方式 |
|---|---|
| TMDB 无该季总集数数据 | 不显示完整性状态条，或显示“总集数未知 · 无法校验”的灰色提示 |
| 文件命名不规范导致集号未正确解析 | 按 Infuse 现有刮削逻辑处理，仅对成功匹配集号的文件计入“已有”。未被刮削的文件可在“其他”或“未识别”区域查看，不计入完整性统计（避免误报） |
| 包含特典/SP（Special）集数 | 仅统计 Season 内的常规集数。SP 可在剧集列表中以特殊标识独立展示，但不参与完整性计算 |
| 单季文件数量为 0 | 不显示状态条，显示“该季暂无剧集”提示 |
| 总集数为 1（单集特别篇） | 正常显示完整/缺失状态，逻辑不变 |
四、范围界定（明确不做的事）
| 不做 | 原因/说明 |
|---|---|
| 不自动下载/补全缺失文件 | 纯信息提示，不涉及任何文件系统操作，规避权限与安全风险 |
| 不弹窗、不强提醒 | 避免干扰观影流程，仅作静态信息展示，尊重用户的沉浸式体验 |
| 不依赖媒体服务器 | 完全基于 Infuse 本地索引 + TMDB 元数据，直连用户与媒体服务器用户均可平等使用 |
| 不作为“媒体服务器”功能的替代品 | 本功能定位为“提示”，而非“管理”。它与媒体服务器提供的库管理能力不构成竞争或替代关系，而是 Infuse 作为播放器本职范围内的信息呈现 |
五、用户价值
对直连用户：
首次在 Infuse 原生界面中获得集数完整性的可视化反馈，结束了“盲猜-踩坑-后知后觉”的被动状态。用户可以在开始追番前就发现缺口，主动去补齐资源，而不是在看完 100 集后才发现错过了 8 集。
对媒体服务器用户：
提供一层额外的前端校验。即便媒体服务器端已有完整性信息，用户仍需在 Infuse 内获得一致的提示，无需在多个应用间切换比对。
对所有用户：
帮助用户在“决定是否开始看这部剧”之前，准确评估资源准备情况。避免追到一半发现缺集导致的强制中断，也避免“全看完了但漏了 10%”而不自知的遗憾。
对 Infuse 自身：
以极低的开发成本（数据已具备，仅需展示层加工），填补一项长期被竞品（如 VidHub、Fileball）用户拿来对比的功能空白。同时，该功能直接回应了直连用户群体的核心诉求，有助于巩固 Infuse 在“播放器 + 云盘直连”这一细分场景中的领先地位。
六、技术可行性评估
| 评估维度 | 说明 |
|---|---|
| 数据已有性 | Infuse 在刮削阶段已完成“文件名 → 集号”的映射，TMDB 也已返回季的总集数。两组数据均已存在于本地索引数据库中 |
| 开发复杂度 | 核心逻辑为集合减法（总集数集合 - 已有集号集合），UI 为状态条展示，不涉及底层架构调整，属于展示层优化 |
| 性能影响 | 差集计算在数据量级（单季通常 ≤ 500 集）下为纳秒级运算，不影响列表加载性能 |
| 兼容性 | 不改变现有数据结构和播放流程，对旧版本库文件无影响，向前兼容 |
一句话概括：把数据库里已有的两列数字（应有 / 已有）做个减法，将差集画在屏幕上。
七、补充建议（可选）
如团队考虑后续迭代，可在此功能基础上延展：
-
全局概览：在剧集（Show）主页面显示各季完整性摘要，如“S1 ✓ · S2
缺 3 集 · S3 ✗ 缺 21 集”。 -
补全联动：点击缺失列表中的集号，触发网盘重扫描或提示“尝试重新匹配文件名”（不涉及文件下载）。
-
播放前提醒：用户点击“播放下一集”时，若下一集缺失，在播放按钮附近显示 subtle 的提示（非弹窗）。
本回复由DeepSeek（一个源自中国的AI）在投喂了本帖上下文后自动生成。
我已将您建议的英文版本移至“建议”版块中的一个现有帖子中。请关注该帖子以获取最新动态。谢谢。
光移动并不能解决问题，你们要不看一下那个建议的发布时间呢？
从2023年到现在，你们做了多少版本了？从来没有考虑过这一个小小的需求。
总体而言，Infuse团队的开发进度，令人失望，和中国竞争对手相比，落后许多。而且你们的新功能路线图，我真的一个都不用不到