Emby 服务器 CPU 过高 — 软解转码、元数据扫描、实时扫描三大嫌疑

排查顺序

CPU 飙高时，先看 Dashboard → Home → Active Sessions 和 Server Info，判断是哪种情况：

场景一：软解转码（最大嫌疑）

现象

Active Sessions 里显示 Transcoding = Yes，CPU 飙到 80~100%。

这是 Emby Server CPU 高的头号原因——远程访问多人同时看片、或者媒体文件编码不兼容客户端需要转码时，没开硬件加速就只能软解，CPU 瞬间拉满。

解决办法

开硬件加速转码。这是最有效的手段：

Dashboard → Transcoding → Hardware video decoder：

• Intel 核显（Quick Sync）→ 选 Quick Sync 或 Auto
• NVIDIA 独显 → 选 NVENC
• AMD → VAAPI
• 不知道选什么 → Auto

硬件转码需要 Emby Premiere。开了之后 CPU 占用通常从 80~100% 降到 10~20%。

Docker 环境额外要做

Docker 里用硬件转码必须把核显/独显设备透传进容器。参照 Docker 容器部署 和 硬件加速转码 里的设备透传参数。

验证硬件加速生效

Dashboard → Transcoding 页面应该能看到 "Hardware acceleration enabled"。转码时 Active Sessions 里 Transcoding 那个视频的编码器应该显示 h264_qsv（Quick Sync）或 h264_nvenc（NVENC）而不是 libx264（软解）。

场景二：元数据扫描

现象

刚往媒体库里扔了一堆新文件，Emby 正在扫描，CPU 飙高。

正常现象——Emby 扫描文件结构、解析文件名、联网拉元数据、下载海报、生成缩略图。这个过程中 CPU 忙是正常的，扫完就下来了。

加速办法

• 先给文件起对名字：Emby 能更快匹配，减少重试
• 扫的时候别同时跑其他消耗（DVR 录像、大量转码）
• 缩略图缓存不要重建：Dashboard → Library → 对应库 → Settings → 不要手动重建缩略图
• 已经稳定的库不要频繁全量 Refresh

异常扫描：一直扫不完

如果 CPU 高了很久（> 30 分钟）还在扫，可能：

• 某个文件损坏导致 Emby 卡在解析它
• 媒体路径里有符号链接或循环目录（Emby 一直在绕圈子）
• 文件数量极多（几万+）且实时扫描在同时跑定时扫描

排查：Dashboard → Help → Logs → 看日志里最近在处理哪个文件/目录。

场景三：实时扫描 + 定时扫描叠加

现象

没人在看片，但 CPU 一直 30~50%，有上下波动。

可能是 Real-time monitoring + 定时扫描同时在跑：

• 实时监控检测到有文件变化 → 触发扫描
• 定时扫描的周期到了 → 触发全库扫描
• 两个扫描同时跑 → CPU 叠加

解决办法

1. Dashboard → Library → Advanced Settings：

• Scan interval：如果你已经开了实时监控，把定时扫描改成 Weekly 甚至 Never
• Enable real-time monitoring：如果实时监控不稳定（文件系统不支持），关掉它，只靠定时扫描（Daily 够了）

1. Dashboard → Advanced → Library → Run Scan On Startup：关。Server 启动时不要自动全量扫描
2. Throttled Scan：Dashboard → Library → Advanced → 勾上这个，让扫描低优先级运行，不抢播放资源

场景四：Auto-Convert（Premiere）

现象

固定时间（比如凌晨 2 点）CPU 准时飙高。

解决办法

Dashboard → Auto-Convert（Premiere 功能）：

• 检查有没有配置定时自动转码任务
• 如果配了，调整时间（比如凌晨 3 点避开扫描），或减少并发转换数量
• 或者暂时关掉，改成手动触发

场景五：缩略图缓存生成

现象

媒体库刚重建（或第一次扫），每个视频都在截帧生成缩略图。

Emby 在扫描时会自动为每个视频提取缩略图（作为快进时的视觉参考）。几百部电影一起生成缩略图会吃 CPU 和磁盘 IO。

解决办法

• Dashboard → Library → 对应库 → Advanced → Extract chapter images during the library scan：关掉（需要时手动生成）
• 或者保持默认，让它慢慢跑（首次扫描通常慢，后续增量扫描不影响）

场景六：插件狂跑

现象

CPU 高但 Active Sessions 里没人在看，日志一直在刷某个插件的名字。

排查

Dashboard → Help → Logs → 搜日志里的插件名称。如果某个插件（比如 Notifications、Trakt、Open Subtitles）一直在刷日志，可能是：

• Notifications 一直在发同一条通知失败重试
• Trakt 同步一直在跑（很多条目要同步）
• Open Subtitles 一直在搜字幕但搜不到，不断重试

解决办法

1. Dashboard → Plugins → My Plugins → 找到嫌疑插件
2. 进 Settings 看有没有"自动重试"、"同步频率"之类的设置
3. 实在不行 → 暂时 Disabled 那个插件，看 CPU 降没降

场景七：Emby Server 被攻击

现象

CPU 突然飙高 + 日志里有大量奇怪的访问请求（类似 SQL 注入、扫描端口的请求）。

Emby Server 暴露在公网（配了端口转发）就可能被扫。虽然 Emby 不是高危目标，但还是要注意：

防护措施

1. 不要用默认端口：把 HTTP 端口从 8096 改成别的（比如 18096），减少被扫的概率
2. 强密码：管理员和所有用户都用强密码
3. Emby Connect 优先：如果能用 Emby Connect 远程访问，就不用手动端口转发（少暴露一个口子）
4. WAF / 路由器访问控制：ASUS/OpenWrt 路由器有 WAF 和 IP 黑名单功能
5. Dashboard → Help → Logs 里定期看登录日志

CPU 类型和硬件转码支持

如果你 CPU 不够但预算有限，买一块二手 NVIDIA GT 1030（几十块） + PCIe 扩展槽，就能解锁 NVENC，比换 CPU 便宜得多。