一天里试了两件事：给 NAS 装一个开源的媒体服务器，和在自家小主机上跑一套 AI 虚拟主播的直播项目。

两件事都跑通了，最后都清掉了。过程里的判断比结果更值钱，记一下。

第一件：Jellyfin 想替代现有方案

起因很直接。现有的媒体服务器是 NAS 自带的，界面做得素，而且硬件转码要付费。Jellyfin 开源免费，硬件转码不收费，海报墙也好看——值得试。

装的过程没难度

容器跑起来只要能想明白三件事：往哪挂、给多少内存、怎么碰核显。

docker run -d --name jellyfin --restart unless-stopped \
  --memory=1g --memory-swap=2g \
  -p <端口>:8096 -e TZ=Asia/Shanghai \
  -v /<配置盘>/config:/config -v /<配置盘>/cache:/cache \
  -v "/<媒体目录>:/media/movies:ro" \
  --device /dev/dri:/dev/dri --group-add 44 --group-add 105 \
  jellyfin/jellyfin:latest

几个实际踩到的点：

• 内存必须设上限。这台 NAS 只有 3.75 GB 内存，还要跑下载器、自动化工具和另外两个常驻服务，swap 已经在用了。不设上限的话，扫描媒体库时触发的是整机内存回收，而不是单个容器被杀
• 媒体目录一律只读。几百部影片的库，一个误操作代价太大
• 容器内路径用 ASCII，中文路径留在宿主侧，不然日志和参数里容易出问题
• 核显直通后，启动日志里能看到 h264_qsv、hevc_qsv 就说明成了

真正花时间的是 API 版本差异

新版 Jellyfin 的初始化和老教程完全对不上，记录几个卡住过我的地方：

认证头必须是 Authorization，不是 X-Emby-Authorization。 用后者会得到一句 Error processing request.，日志里只有一个莫名其妙的 Value cannot be null (Parameter 'request.App')。这不是密码错，是头没被解析——当时差点去重设密码。

建媒体库的所有参数都放在 query 上，中文要用 --data-urlencode，否则乱码。刷新参数的 refreshLibrary=true 还不一定真扫，有时得手动再触发一次。

删库重建必须先重启容器。 我最初把库的类型从「电影」改成「混合内容」，做的是「删 → 立刻重建 → 刷新」，结果新库根本没注册：库列表里看着一切正常，路径也对，容器内 find 能数到文件，但条目永远是 0，状态长时间挂在排队中。决定性证据是启动日志里只有别的库路径，新库的路径压根没出现。正确顺序是「删库 → 重启容器 → 重建 → 再手动触发扫描」。

最后为什么放弃

刮削过不了关。 这台机器的媒体目录是 PT 下载器的做种目录，电影和剧集混在一起，而且不能动（拆了会破坏做种）。Jellyfin 的识别器按 剧名/Season 1/xxx.S01E01.mkv 这种标准结构设计，遇到「剧名目录里直接放集文件」的原始命名就抓瞎：

单文件电影       → 正确识别为 Movie
剧名目录+集文件  → 仍然被归为 Movie，不会归到剧集下

把库类型改成「混合内容」也救不了，因为它先跑电影解释器，命中就不再试剧集解释器。而 NAS 自带的那个媒体服务器是按国内资源命名习惯写的，同一个目录它认得。

内存代价不小。 常驻 360–490 MB，对比之下自带方案空闲只占 49 MB。这台 NAS 的内存本来就紧，为了一点好看多花十倍内存，不划算。

操作体验也不如原生。 电视端装客户端、配服务器地址、登账号，每一步都要折腾；而自带方案在 NAS 上已经配好了。

所以结论很清楚：它没有输在技术上，输在没有解决任何真实痛点。硬件转码免费是优势，但平时看片根本用不上转码；海报墙好看是优势，但那个目录的内容本来就不规整。

清掉的时候连镜像带数据一起删了，端口也释放了。

第二件：复刻一套 AI 虚拟主播直播

在 GitHub 上看到一个项目：给 OBS 用的 1920×1080 直播场景，一个虚拟角色在邮局里讲一小时故事，观众能发弹幕点歌、能改剧情走向、送礼物会道谢。

技术上不复杂：一个 Node 服务 + 前端页面 + AI 生成文本 + TTS 朗读 + 弹幕长连接。依赖只有两个 npm 包。

本机条件基本齐了

Node 运行时        已有
OBS                已有
PipeWire 音频      已有
核显硬编           已有
缺                 浏览器（项目脚本写死了 Windows 路径）

跑通的部分

AI 生成接的是自建网关。 把接口地址指向自己的中转服务，模型名换成对应标识，一条回放弹幕的回复质量超出预期：

（笑了笑，把信往灯下挪了挪）今晚讲《鲸鱼邮局的第七封信》——就是这封，收件地址是一百年前的灯塔。

TTS 用的是在线音色。 项目自带一个环境变量钩子，可以指定 Python 解释器，所以我在项目内建了个虚拟环境装依赖，没污染系统 Python：

引擎    edge · 中文女声 · 降 10Hz · 慢 8%
耗时    2.17 秒 / 22 字
输出    30KB mp3

服务本身极轻。 Node 进程常驻 74 MB、CPU 0.4%，故事在跑、页面在渲染，就这么点开销。

加上浏览器渲染和 OBS 推流，全套估算 700 MB–1 GB 内存、2 核左右——对这台 31 GB 内存、4 核的小主机来说不算负担。

卡住的地方全在平台侧

内容生成、配音、渲染、弹幕接收，本地全部能做。真正过不去的是推流到平台这一步。

抖音：2023 年就关闭了 OBS 模式，现在只能用官方的直播伴侣。而直播伴侣只有 Windows 和 macOS 版。跑 Linux 的小主机，官方途径没有推流手段。网上有截取推流码的第三方工具，但那是绕过平台限制。

B 站：2025 年 5 月改了规则，第三方推流（也就是 OBS）需要 5000 粉以上，官方明说「客服渠道无法降低门槛」。低于 5000 粉只能用官方直播工具，而工具同样只有 Windows/macOS，或者只能手机播。

两条路都指向同一个结论：想用自己渲染的 1920×1080 画面，得有一台 Windows 或 Mac 设备来拿推流码。

还有一个更大的问号：收益

在决定投入前先算了一笔账：

更要紧的是合规。2026 年 6 月起《人工智能生成合成内容标识办法》强制落地，虚拟主播、AI 声音、AI 图片全部属于必须标注的范围，违规阶梯是「下架限流 → 限制发布 → 封号并纳入全网黑名单」。而平台的虚拟主播规范还强调「不得是循环播放预制好的动画」——这个项目用的正是几个 webm 循环动画。

也就是说：这套东西播起来，形态上就在规则的边缘。

于是也清掉了

项目目录、后台服务、临时文件、虚拟环境全部删除，端口释放。留下的只有结论。

一天下来学到什么

技术可行和事情可行是两件事。 两个项目都能跑起来，但一个没解决真痛点，一个撞在平台门槛上。跑通不等于值得做。

先确认最后一步能不能走通，再投入前面。 如果一开始就查「抖音能不能用 OBS」「B 站第三方推流要多少粉」，那两个小时的内容制作就不用做了。链条越长，越要先验证末端。

评估一个自托管服务，要连着代价一起看。 功能数量好看，但内存、磁盘、维护成本都是真实的。为 5% 的体验提升多花十倍资源，在小机器上是不划算的。

别把「能自动化」当成「应该自动化」。 隧道看门狗我最终做成了只通知不重启——因为重启会打断全家网络，这种决定权应该留给人。

能力会沉淀，项目不会。 这两个项目都删了，但「接自己的模型网关」「用 TTS 做配音」「容器里给服务设资源上限」「按目标把流量分流」这些具体做法留下来了，换个场景直接能用。