从零搭建YuE家庭媒体中心：NAS影视库与多端访问实践

“YuE”这个词第一次出现在我手机备忘录里的时候其实就俩字母——Y和E。当时我正坐在客厅沙发上电视遥控器在茶几上排成一排手机里装了四五个视频App想找一部电影却翻来覆去搜不到NAS硬盘灯在角落一闪一闪里面躺着几百部电影、几千首无损音乐和我爸妈扫描出来的老照片却几乎没有被打开过。那一刻我突然意识到问题不在内容而在入口太乱。YuEYour Entertainment就是从这个念头里长出来的把散落在NAS里的电影、剧集、音乐、电子书、照片全部汇到一个统一入口电视、手机、平板、电脑随时能看能听。这个项目不追求复杂的自动化也不做所谓的内容平台它只做一件事——把你已经拥有的资源用最舒服的方式组织起来全家人都愿意打开。适合谁参考呢家里有NAS但长期吃灰的觉得各家流媒体订阅费越来越肉疼的还有想给孩子和老人准备一块干净可控内容区的都可以看看我这一路的方案取舍和踩坑记录。1. 项目背景与设计思路拆解1.1 痛点很清晰但解法不是再多买一个会员过去两三年各家视频平台把版权切割得非常碎想看的电影分散在不同App里每个App的播放器体验、画质策略、搜索逻辑又各不相同。我实测过如果想在同一台电视上看完自己常追的片单至少要装四五个App每年订阅费加起来超过千元。而另一边我手里其实已经积累了大量本地媒体文件——蓝光原盘、无损音乐、Kindle书库、家人扫出来的老照片这些东西的价值完全没有被释放出来。YuE的第一条设计原则就是“本地优先”。所有内容存在本地播放走局域网既不受外网带宽影响也不存在“这个资源在A平台、那个资源在B平台”的割裂感。你要做的不是再买一个平台的会员而是把内容入口统一起来。当时我也考虑过直接买一台成品NAS、用厂商自带的全家桶但看了看那些软件在中文媒体刮削、多端播放上的表现还是决定自己组一套。1.2 整体拆解YuE要解决的五件事动手之前我列了一张需求清单最后收敛成五个模块影视库电影、剧集的分类展示海报墙自动刮削元数据多端播放音乐库无损音乐的整理、封面匹配、手机端和客厅端播放阅读库电子书的格式转换和在线阅读、漫画的翻页体验相册库老照片、手机照片的备份与时间轴展示访问入口电视、手机、平板、PC四端的统一接法以及出门在外时的安全访问这五个模块各自独立但共享同一个存储池和同一套权限体系。架构上我用Docker Compose把它们编排在一起每个服务跑一个容器互不污染配置和依赖后续升级某个模块不影响其他服务。这个决定在后面维护时省了大量心思。1.3 为什么叫YuE名字背后是产品思维项目名“YuE”最初只是“Your Entertainment”的缩写后来我越用越觉得它更像一个动词——“娱乐一下”。打开电视说一声“YuE一下”其实就是打开全家的娱乐中心。名字这个东西确实不重要但它时刻提醒我这个项目的目的不是折腾技术而是让家里人每周愿意打开它、使用它。任何会影响这个目标的复杂度都应该被砍掉。所以在后面选型时我有一个原则能少配置一个组件就少配置一个组件能少暴露一个端口就少暴露一个端口。YuE的核心价值是稳定和易用不是功能堆叠。2. 硬件选型与系统规划2.1 三套方案我为什么选了N100迷你主机先交代一下我考察过的三类承载方案。第一类是成品NAS群晖DS423、威联通TS-464这类。优点非常明显开箱即用系统稳定套件丰富国内外社区资料多。缺点是价格偏高同等配置下比DIY方案贵出一大截而且自带的Video Station对中文刮削支持并不算好很多玩法还是要靠第三方Docker套件来补那不如一开始就上通用系统。第二类是旧电脑或旧笔记本改造。性能足、零成本前提是手头有闲置机器但整机功耗通常30W起步风扇噪音放在客厅里比较明显24小时开机的话电费也不容小觑。如果家里客厅不是单独设备间这款体验一般。第三类就是我最终选的方案迷你主机加硬盘柜。我用的是N100型号的迷你主机8GB内存起步后面升到了16GB配一个四盘位硬盘柜通过USB接口连接。N100自带Intel UHD Graphics核显支持Quick Sync Video硬解实测下来可以同时处理多路1080P转码任务。整机功耗在8W左右几乎没有噪音放在电视柜侧面完全不觉突兀。总预算也控制在四千元以内包含主机、硬盘柜和四块4T硬盘。最终选它的核心原因有三个功耗低适合7×24小时运行体积小能塞进客厅预算可控后期硬盘不足还能换大容量盘。当然如果你更追求省心、不想折腾系统成品NAS依然合理——YuE这套软件栈完全可以用Docker跑在群晖和威联通上下面的配置思路是通用的。2.2 硬盘、网络与供电这三件事决定“稳不稳”先说硬盘。我选的是NAS专用盘酷狼4T×4组RAID 5阵列可用容量约10.9TB。RAID 5允许坏一块盘不丢数据同时比RAID 1节省空间适合媒体库这种大文件连续读写的场景。如果你预算高一些也可以考虑酷狼Pro、红盘Plus主要差别在质保年限和转速使用层面区别不大。再说网络。千兆有线是底线电视、迷你主机、主路由之间一定尽量走网线Wi-Fi留给手机和平板。如果家里预埋了六类网线直接组千兆内网就行没有预埋的话用Mesh路由器做有线回程也比电视直接连Wi-Fi稳定。我在实际使用中感受到Jellyfin加载大体积原盘文件时有线网络基本能做到秒拖进度条Wi-Fi偶发卡顿体验差距在客厅场景下体现得非常明显。最后说供电。UPS不间断电源是我强烈建议加的一项一百多块的入门型号就能起到保护作用。媒体服务器最怕的不是断电本身而是断电瞬间硬盘正在写入导致文件系统损坏或者出现坏道。给迷你主机和硬盘柜配上UPS断电后自动安全关机这个投入比多买一块硬盘还值。我自己用的APC BK系列设置好自动关机脚本后家里停电几次都没出过问题。2.3 为什么用Debian加Docker而不是装个图形化系统很多新手会直接给迷你主机装Windows然后开共享文件夹、用播放器直接拉文件一开始我差点也这么干。但仔细想了一下Windows有三四个问题绕不开自动更新会半夜重启导致服务中断系统本身占用内存高远程管理不方便权限体系也比较松散。所以我最终装了Debian 12的无桌面版本再用Docker Compose管理所有服务。Docker在这里最大的价值是把每个服务的依赖隔离干净。Jellyfin需要ffmpeg做转码Navidrome又要自己的音频解析组件Calibre-Web还要依赖Calibre的数据库这些依赖如果直接装在同一个系统里版本冲突只是时间问题。用Compose文件一次性定义好所有服务一条 docker compose up -d 就能把整个YuE拉起来升级某个容器也不会影响其他服务。3. 核心搭建实操与节点实现3.1 磁盘初始化与共享目录规划先说磁盘初始化的思路。我用Linux下的mdadm工具把四块4TB硬盘组成了RAID 5阵列格式化为ext4挂载到 /data 目录。操作过程大致是安装mdadm、创建RAID设备、格式化和挂载、最后写入fstab让系统开机自动挂载。这一步如果用群晖或威联通的图形界面直接在存储管理器里划存储池和共享文件夹就行思路一样只是命令换成鼠标操作。目录规划是很多人容易忽略的细节。我建议用“媒体类型/内容类型/具体文件”三层结构/data/media/movies /data/media/tv /data/media/music /data/media/books /data/media/photos /data/downloads为什么要单独留一个 /data/downloads因为下载和整理是两个阶段下载目录保持“原始状态”整理完成后再移动到媒体目录。这样即使自动整理脚本抽风也不会把原始文件搞乱最多是在待整理目录里多留几份文件。3.2 影视库Jellyfin的部署与调优影视库是YuE里最核心的模块我用的方案是Jellyfin。在Plex、Emby和Jellyfin三个选项里Jellyfin完全开源免费没有会员限制硬件解码、多用户、家长控制这些功能全部开放而且中文社区案例非常多遇到问题几乎都能搜到解决方案。部署方式用Docker Compose核心片段大致这样jellyfin: image: jellyfin/jellyfin container_name: jellyfin volumes: - ./jellyfin/config:/config - /data/media:/data/media devices: - /dev/dri/renderD128:/dev/dri/renderD128 ports: - 8096:8096 environment: - TZAsia/Shanghai这里最关键的配置是把核显设备 /dev/dri/renderD128 映射进容器这样Jellyfin才能调用Intel核显硬解做转码。如果漏掉这一行转码就会走CPU软解N100这种低功耗处理器立刻露出原形并发一多就卡。第一次启动后进入初始化向导我建议把电影和剧集分开添加媒体库刮削语言选简体中文元数据提供方选TMDB。这一步最影响刮削成功率的是文件命名最规范的格式是“电影名 (年份).mkv”比如“流浪地球2 (2023).mkv”剧集则是“剧名/Season 01/剧名 S01E01.mkv”。命名规范之后海报墙基本一遍就能刮出来后面再微调个别条目就行。3.3 音乐库Navidrome与移动端搭配音乐模块我用了Navidrome一个轻量的开源音乐流媒体服务器。它界面风格偏向老牌的Subsonic但后端是Go写的容器启动很快内存占用也就一两百兆几乎没有存在感。它支持直接输出无损音频FLAC、APE、WAV这些格式都能直接播放不需要转码。音乐目录的整理是重点。Navidrome和大多数音乐服务器都按“艺术家/专辑/曲目”三级目录识别/data/media/music/李健/拾光/01. 贝加尔湖畔.flac目录规范之后Navidrome会自动读取音频文件内嵌的ID3标签自动匹配封面。如果音乐文件本身内嵌了封面基本不会出现“封面找不到”的问题如果没内嵌封面把 cover.jpg 放在专辑目录里也能识别。整理老唱片时如果标签缺失或者混乱我推荐先用MusicBrainz Picard批量补TAG再丢进音乐库效率会高很多。手机端我用的播放器是substreamer和play:SubiOS和Android都有打开后填入Navidrome的地址、用户名和密码就能同步整个曲库。在客厅里还可以通过浏览器的Web界面直接播放或者用支持DLNA的设备连接Navidrome场景覆盖比较完整。3.4 阅读库Calibre-Web与Komga各管一摊书籍和漫画的体验需求完全不同我把它拆成两个服务。电子书用Calibre-Web它后端复用Calibre的数据库能力支持epub、mobi、azw3和PDF等格式在线能读也能做格式转换和元数据编辑适合构建私人书库。漫画我用的是Komga专门处理CBZ、CBR这类压缩包格式支持连续滚动阅读手机上比直接用PDF阅读器舒服很多。这两个服务流量不大内存占用也小各分配100MB左右就够用了。唯一要注意的是不要让它们直接读取原始下载目录。Calibre书库有个特点它会按作者和书名重新组织文件如果你往书库里直接丢文件很容易把目录结构搞乱。正确做法是先用Calibre桌面版把书导入书库让服务端做格式转换和元数据整理然后让Calibre-Web只读这个书库目录。4. 访问入口与自动化流程4.1 局域网里四个终端的接法核心服务搭起来之后关键是让家里每个屏幕都能用起来。先聊电视端。如果电视是Android系统直接装Jellyfin官方TV客户端打开后它会自动扫描局域网里的服务器输一次账号密码就行。如果是老款电视或者电视盒子可以用浏览器打开Jellyfin的Web界面遥控器操作稍微麻烦点但也能看。手机和平板直接用各平台的Jellyfin AppPC端我倾向于直接用浏览器Web播放器已经足够好用了不需要额外装客户端。音乐和阅读的终端逻辑也一样。Navidrome的Web界面可以在浏览器里直接放歌漫画我主要在平板上用浏览器或者Komga的App看。这里我一度有个误区觉得所有内容应该合到一个App里。实际用下来发现分开反而更合理影音归影音、音乐归音乐、书归书每个工具只服务一个场景界面更干净家里人学起来也快。4.2 出门在外想访问家里三条路线对比余下这个问题很多人迟早都会遇到——出门在外怎么安全地访问家里的媒体服务。我的建议是先分清自己的网络环境有没有公网IP路由器支不支持端口转发运营商有没有屏蔽常见端口。不同环境适合的方案不一样。我实际测试过三条路线动态域名解析加路由器端口映射适合有公网IP的用户。优点是延迟低不依赖第三方中转缺点是配置相对复杂要面对运营商端口封禁的问题。如果家里上行带宽够大播放原盘也没压力。开源内网穿透工具frp这类需要一台有公网IP的中转服务器家里客户端主动连出不在家庭网络开放任何入站端口安全性更好。缺点是带宽受限于中转服务器的上行自建中转的话还要额外维护一台服务器。异地组网产品Tailscale等把手机、电脑、平板都放到同一个虚拟局域网里在公共场所也能像在家一样访问NAS。优点是完全不需要公网IP配置简单流量自动加密缺点是部分网络环境下需要额外处理。我目前的方案是“DDNS加端口映射”和“异地组网”双保险在家里走局域网出门默认走异地组网特殊情况下走DDNS。这三条路线解决的都是远程访问需求而且都是在合规的远程访问范畴里做的没有额外引入任何不安全手段。关键原则是能不开端口就不开端口能用加密组网就不用裸暴露。4.3 文件不用手动收拾自动化整理脚本媒体文件多了以后最累人的不是看片而是整理文件。我写了一个小脚本用inotifywait监听 /data/downloads 目录一旦发现新文件落盘就根据扩展名和文件名规则自动分类电影文件移动到 movies剧集文件移动到 tv音乐文件移动到 music电子书移动到 books。移动完成后通过Webhook通知Jellyfin、Navidrome、Calibre-Web分别刷新对应媒体库。脚本的核心逻辑很简单就是一个文件监控循环配合几条分类规则。需要注意的点是文件名必须规范脚本只处理命名规律的文件遇到不认识的命名就丢进“待整理”目录人工确认后再入库。这个设计避免了脚本误判导致的错误归类。除了自动分类我还给文件做了命名规范化处理检测文件名里的“S01E01”这类剧集标记或者“xxxx.2023.xxx”这种年份模式把来源比较乱的文件名统一成“剧名 S01E01 集标题”或“电影名 (年份)”的格式。这一步是刮削成功率的根本保障后面的海报墙再智能也要先有规范的文件名才能识别。5. 体验调优与内容编排5.1 海报墙刮削的调优经验Jellyfin的海报墙是YuE的门面刮削效果直接决定了家里人愿不愿意天天打开它。这块我踩了不少坑总结了三条实践经验。第一命名永远是最重要的。文件名“蜘蛛侠纵横宇宙 (2023).mkv”比“Spider-Man - Across the Spider-Verse 2023 2160p.mkv”更容易被刮削正确因为中文名和年份在文件名里位置固定刮削器解析成功率更高。当然英文原盘资源保持英文名也完全可以关键是年份一定要写清楚。第二优先启用TMDB刮削器并把刮削语言设为简体中文。如果某些老电影在国内资料站找不到中文条目可以把语言顺序调整为“中文、英文”用英文条目做兜底这样即使海报和简介是英文的也不至于整条记录丢失。第三剧集目录一定按“季”分开。Jellyfin识别多季剧集依赖“Season 01”“Season 02”这样的目录结构如果全季文件堆在一个平铺目录里识别结果会把所有集混在同一列表里整理起来非常痛苦。5.2 多用户权限与家长控制家用环境下权限设计也要认真对待。我建了四个账号管理员我自己、大人账号、儿童账号和访客账号。Jellyfin的原生多用户系统支持给不同用户分配不同的媒体库儿童账号只开放动画标签和G、PG级别的内容访客账号只能读电影库不能看家庭照片库。这个配置不光保护了孩子的观看内容也避免了访客误改媒体库里的配置。音乐和阅读服务我就没有做这么细的账号隔离了Navidrome和Calibre-Web各自建一个共享账号开放给局域网和可信设备就够了。它们没有公网端口暴露只在内网范围使用安全风险可控。5.3 转码与播放兼容性调优播放卡顿的原因里有八成是转码策略没调对。Jellyfin默认情况下如果检测到播放器不支持某种编码格式就会自动转码。要是核显没正确映射进容器转码就会落到CPU软解N100这个级别的处理器立刻捉襟见肘。我实测下来的结论是N100核显可以同时硬解三路1080P H.264或者一路4K HEVC转1080P。再往上就不是硬解能力问题了而是内存和磁盘IO会成瓶颈。所以日常使用建议开“原画直出”只在字幕烧录或格式不兼容时才触发转码。还有两个细节值得注意。一是把Jellyfin的转码临时目录放到空间充足的磁盘上否则转码大文件后磁盘空间会被临时文件占满二是字幕文件命名把 .srt 和视频放在同目录且同名Jellyfin会自动加载比在播放器里手动挂载方便很多。6. 常见问题与排查技巧实录6.1 我实际踩过的几个坑第一个坑是硬解不生效。Jellyfin界面一直显示“检测不到可用硬件”排查了很久才发现是容器启动时漏传了 /dev/dri/renderD128 设备。加上之后转码速度从0.3倍速提升到10倍以上肉眼可见的差距。如果你也遇到类似情况先确认容器里能不能看到这个设备文件。第二个坑是中文文件名乱码。自动化整理脚本用Python写的脚本文件本身没有声明UTF-8编码导致移动中文文件时名称全部乱掉。后来在脚本头部显式加上环境编码声明问题才解决。这个坑在中文场景下非常经典任何处理中文文件的Python脚本都值得留意。第三个坑是刮削器匹配到了错误条目。典型场景就是两部同名电影刮削器总是识别成旧版。解决办法是在Jellyfin里对条目手动“识别”输入正确的TMDB ID或IMDb ID刷新后即可纠正。第四个坑是外网访问速度奇慢。排查来排查去最后发现是局域网内用了Wi-Fi中继电视和主机本身又都在无线网络中。换上网线之后速度问题直接消失。家庭内网的基础布线永远是媒体体验的地基。第五个坑是Docker容器日志涨到好几个G。Jellyfin长时间运行后日志文件不断膨胀最后居然把磁盘占满了。解决方法是在Docker的daemon.json里配置日志轮转限制单个日志文件大小和保留份数之后再也没复发过。6.2 故障排查速查表我把这些经验整理成了一张速查表遇到问题直接对照排查症状可能原因排查与解决硬解转码不生效未传递核显设备确认 /dev/dri/renderD128 已映射进容器海报墙大量缺失文件命名不规范检查“电影名 (年份)”格式手动刷新元数据局域网外访问失败没有公网IP或端口未映射改用异地组网或内网穿透方案音乐封面不显示标签和封面未内嵌用MusicBrainz Picard批量补TAG播放频繁缓冲转码路径空间不足加大缓存目录空间改用原画直出中文剧集不识别目录结构不合规使用“剧名/Season 01/剧名 S01E01.mkv”结构容器日志占满磁盘日志轮转未配置设置Docker日志轮转保留最近3个文件6.3 数据备份与灾难恢复方案YuE里的媒体文件大多是可以用时间重新获取的但照片、家庭录像和书库整理记录是真正不可再生的数据。我的备份策略分三层照片和文档每天用rsync同步到另一块独立硬盘Jellyfin的配置目录包含所有用户的播放记录和媒体库设置每周打包备份到网盘四块硬盘组成的RAID 5阵列为整库提供硬件冗余。另外我坚持每个季度做一次真实的恢复演练。拔掉一块硬盘确认阵列降级后数据依然能正常读取然后再插回去做重建。这个测试虽然听起来有点多此一举但真等到硬盘报警再去摸索恢复流程心态完全是两回事。做完一次演练你对这套系统的信任度会高很多。最后说一点个人体会。YuE这个项目的价值不在于技术堆得多高而在于它让全家人在同一个地方找到想看的内容。搭建过程里最花时间的不是装软件而是整理目录、规范文件命名、调试刮削器。把这些“脏活”做完之后的使用体验会非常顺畅。如果你想做类似的东西不用一步到位先跑起影视库再慢慢加音乐和阅读让家人先看到成果再逐步完善。每当我看到客厅电视上整整齐齐的海报墙就知道这些折腾是值的。