Emby STRM 播放体验优化：MediaInfo 预热工具搭建与部署

建议可以给ai提供github链接，让他帮你部署调试出适合你的配置，搭配热处理。

Emby STRM 媒体信息预热工具：提前跑 MediaInfo，减少首次播放等待

最近折腾 Emby + STRM 媒体库时，发现一个比较影响体验的问题：

有些 STRM 影片第一次点播放时，Emby 会临时调用 ffprobe 去探测真实媒体信息。

如果后端是 302 直链、网盘直链之类的方式，这一步有时候会比较慢，表现出来就是：

点击播放 → 等一会儿 → Emby 探测媒体 → 才真正开始播放

所以写了一个小工具：

Emby STRM Prewarmer

GitHub：

https://github.com/ado-uta/emby-strm-prewarmer.git

📌 这个工具是干什么的？

简单来说就是：

在真正播放之前，提前让 Emby 把 STRM 对应真实视频的 MediaInfo 跑一遍。

程序通过 Emby API 主动触发 PlaybackInfo，让 Emby 提前获取真实媒体的：

• 分辨率
• 视频编码
• 音频编码
• 码率
• 音轨
• 容器信息
• 其他 MediaInfo

探测完成以后，信息由 Emby 自己保存到媒体库数据库。

这样后面真正播放的时候，如果媒体信息已经完整，就可以减少首次播放前临时 ffprobe 探测带来的等待。

✨ 主要特点

• ✅ 不下载完整视频
• ✅ 不修改 STRM 文件
• ✅ 不修改 NFO
• ✅ 不伪造 / 注入 MediaInfo
• ✅ 直接通过 Emby API 触发真实媒体探测
• ✅ 已经有完整 MediaInfo 的影片自动跳过
• ✅ 新增 STRM 可以增量预热
• ✅ 支持失败重试
• ✅ 支持失败日志
• ✅ 支持限制单次处理数量
• ✅ 支持 systemd 定时执行

比较适合：

Emby + STRM + 302 直链 / 网盘直链 这类媒体库。

🚀 快速使用

1、下载项目

git clone https://github.com/ado-uta/emby-strm-prewarmer.git.git
cd emby-strm-prewarmer

然后执行安装脚本。

安装后默认目录：

/opt/emby-strm-prewarmer

2、配置 Emby API Token

进入 Emby：

控制台 → 高级 → API 密钥

创建一个 API Key。

然后写入：

/opt/emby-strm-prewarmer/token.txt

Token 文件建议设置权限：

chmod 600 /opt/emby-strm-prewarmer/token.txt

⚠️ 注意不要把自己的真实 Token 发到 GitHub 或论坛。

3、配置 STRM 媒体目录

编辑：

/opt/emby-strm-prewarmer/config.ini

例如：

[emby]
url = http://127.0.0.1:8096/emby
token_file = token.txt

[libraries]
roots = /data/media/movies/
        /data/media/tv/

这里有一点需要特别注意：

填写的是 Emby 容器内部看到的路径。

例如 Docker 映射：

volumes:
  - /home/media:/data/media

宿主机文件虽然在：

/home/media/movies

但是配置里应该写：

/data/media/movies/

🔍 建议第一次先 Dry Run

正式跑之前可以先看看哪些影片需要处理：

python3 prewarmer.py \
  --config config.ini \
  --dry-run

--dry-run 只检查，不会真正触发媒体探测。

第一次正式测试也建议先限制数量：

python3 prewarmer.py \
  --config config.ini \
  --max-items 10

确认没有问题以后，再跑完整媒体库。

♻️ 后续新增影片不用全部重跑

这一点是我比较想要的功能。

新增 STRM 后，再运行同样的命令即可。

程序会自动判断：

已有完整 MediaInfo  → 跳过
新增 / 信息不完整   → 预热

所以已经处理完成的影片不会每次都重新探测。

对于媒体库比较大的情况，这样会省很多无意义请求。

⏰ 支持定时增量预热

项目自带 systemd timer，可以直接启用：

systemctl enable --now emby-strm-prewarmer.timer

默认逻辑是：

• 开机一段时间后执行
• 后续定时执行
• 自动检查新增 STRM
• 已有完整 MediaInfo 的项目直接跳过

这样基本可以做到：

新片入库 → 定时任务自动预热 → 后面第一次播放直接用已经探测好的信息。

📄 日志和失败项目

正常运行日志：

tail -f /opt/emby-strm-prewarmer/logs/prewarmer.log

失败项目也会单独记录：

cat /opt/emby-strm-prewarmer/logs/failures.jsonl

单个项目失败不会导致整个任务停止，后面的影片会继续处理。

❓几个可能比较关心的问题

会不会把整部电影下载一遍？

不会主动下载完整视频。

本质还是 Emby / ffprobe 为了识别媒体信息读取所需数据。

具体读取多少，会受到媒体封装格式、远端服务器以及 ffprobe 行为影响。

会不会修改 STRM？

不会。

会不会修改 NFO？

不会。

MediaInfo 存在哪里？

工具本身不另外维护一套媒体信息数据库。

探测结果还是由 Emby 自己保存，通常会进入 Emby 的媒体库数据库。

重启 Emby 会不会没了？

正常重启、刷新页面、普通媒体库扫描，一般不会导致已经保存的媒体信息消失。

如果删除媒体库、重建数据库、删除/改名 STRM 等，则有可能需要重新探测。

🧩 为什么写这个东西？

主要还是因为 STRM + 302 / 网盘媒体库有一个比较明显的体验问题：

很多成本都集中在“第一次播放”这一刻。

如果把 MediaInfo 探测提前放到后台慢慢做，用户真正点播放的时候就可以少等一点。

它并不改变 Emby 原本的媒体处理逻辑，也不往数据库里面硬塞假数据。

本质上只是：

把原本可能发生在第一次播放前的媒体探测，提前触发一次。

如果你的 STRM 媒体库第一次播放经常会卡在探测阶段，可以试试看。

🔗 项目地址

GitHub：

https://github.com/ado-uta/emby-strm-prewarmer.git

目前主要是自己使用和测试。

如果大家有不同的 Emby / STRM / 302 环境，也欢迎反馈实际运行情况、Bug 或改进建议。