NAS服务推荐-本地媒体库
1 前言
之前一直是手动整理喜欢的影视资源，想看时点开看下。后来体验了一些影视公益服，发现 Emby 这软件还挺好用的，界面简洁流畅，海报也比较美观，还能够同步各端的观看进度，体验下来感觉比我的腾讯视频 SVIP 要强，至少没有乱七八糟的广告，也不会有一堆不必要的功能让页面变得卡顿。正好最近也觉得以前那种方式有些单调，就动了搭建本地媒体库的念头。
2 影视媒体库
这里我选用的是 Emby，Jellyfin 虽然提供免费的硬解功能，但想想这功能我其实也不太用得到，因为一般都是在家时才偶尔看动漫电影娱乐下，局域网环境下带宽足够，没必要折腾这个，而且听说 Jellyfin 有很多体验上的小问题，因此还是选择 Emby 了。
2.1 docker部署
这里的话也提供一份 Emby 的 docker-compose.yml 文件。
version: "3"
services:
emby:
image: emby/embyserver:4.8.0.46
container_name: emby
environment:
- UID=1000
- GID=1000
- http_proxy=http://代理服务地址，刮削用，可省略
- https_proxy=http://代理服务地址，刮削用，可省略
volumes:
- ./emby/config:/config # 配置文件路径
- 本地资源路径:/mnt/share1 # 本地资源路径
- HTTPS证书路径:/custom/ssl:ro # HTTPS证书（pkcs12）路径，可省略
- 网盘挂载路径:/yunpan # 网盘挂载路径，可省略
ports:
- 8096:8096 # HTTP端口
- 8920:8920 # HTTPS端口
restart: always
2.2 解决刮削问题
如果在 Emby 使用的过程中，发现海报显示不全，甚至是显示为另外一部剧了，可能有两方面的原因
- 没挂代理，海报数据网站服务器在国外，国内网络不一定能够顺利访问
- 影视资源命名不规范，导致 Emby 无法正确识别
第一点就不说了，一般大家都有一些账号的，Google 下怎么配置就行，主要说下第二点。
Emby 官方有给出一些命名规范，按照这个来命名影视资源，只要目标海报网站有对应的数据，基本都能够刮削到，可问题就出现在这里了。实际操作的的时候，会发现这事是个体力活，流程大概如下
- 到 themoviedb 确认剧集名称和年份
- 建立正确的目录结构
- 给资源规范命名并移动到对应路径下。
最烦人的是最后一步，太费劲了。要是电影还好，算上字幕也就操作两次，但要是电视剧就麻烦了，特别是动漫，一个季度一般 12 集，加上字幕那就是 24 个，要是手头上有几十部存货，岂不是要操作近千次。
所以一般会找些自动化工具来做这个事情，我一开始找的是 nastool，那时软件的作者差不多要停止维护了，而且最新的版本需要认证 pt 账号，可我当时一个都没有，最后只能在网上找了个安全性未知的旧版 docker 容器。体验下来后感觉还行，有相当一部分剧集能够直接识别，失败的也能够手动进行命名处理。不过在家庭服务器环境下跑来路不明的代码让我感觉不太放心，而且剧集识别方面也有点小问题，貌似一旦识别错了，会把以前的文件给覆盖掉，删起来麻烦不说，还得恢复以前的内容。
后来想了想，反正自己需要的就是剧集识别的功能，本身也是做后端开发的，干脆自己写一个得了，应该费不了多少工夫。项目的后端部分差不多完成了，主要用来处理 rss 种子下载和剧集重命名的问题，而且添加了内置识别库，支持导入导出识别数据，可以用来白嫖别人的手动识别成果，来提高资源的识别率。
2.3 利用闲置网盘空间
当你搭建好一套环境后，就会开始想着往里面不断地塞电视剧，然后就会涉及到存储问题了。机械硬盘容量虽然大，可是我拿手上 2.5 寸的 1t 机械盘感受了下，都时不时会冒出咔咔声，更别说 3.5 寸的，估计声音更大，那我感觉出租屋环境下，不太能接受。换固态吧，虽然没声音不怕摔，但是贵，容量的选择也不是很多。
然后就把主意打到了闲置的 115 网盘上，发现还挺合适。它的容量很大，基本都有几十 T，四五年用下来也没和谐过我的任何资源，而且离线功能强大，冷门资源都能够获取到。那么只要将其虚拟为一块外置的存储接入到固态上，就能同时兼具两种存储的优点，静音、容量大。另外资源不用下载了，也可以避免长时间的等待。
目前我的方案就是通过 Alist 把网盘挂载为 Webdav服务 + Rclone 挂载 Webdav 为本地磁盘，并结合之前 Emby 部署的网盘映射，就可以顺利读取到网盘内的影视资源。然后利用我自己开发的剧集识别软件（各位也可以用 nastool，反正都是用来重命名刮削的），在本地硬盘上创建符合命名规范的软链接文件，就可以把网盘资源接入到 Emby 中，同时保证只有观看时才会去拉取网盘资源。体验了几个月后，发现这种方式还是挺可靠的，115 的会员虽然相比以前限速了，但也有 6M/s 的速度，足够观影使用了，除了每隔一个月左右就得去 Alist 重新登录下 115，其它的也没什么缺陷了。
当然了，网盘本身具有不可靠性，说不定哪天就开始和谐资源了，利用 115 网盘来扩充本地磁盘空间这种方式，其实只适合预算有限或者观看新剧的情况，自己确实喜欢的资源，还是在本地盘上也存一份吧。
3 资源获取
既然要搭建本地媒体库了，最好还是有个方便下载资源的渠道，这里推荐用 PT。这个东西大家可能接触得较少，其实不复杂，就是从各个用户的电脑中下载自己所需要的资源，和磁力下载是一样的道理，只不过有所加强。
平时下载热门资源时，磁力下载还是挺快的，但是遇上早点的资源就没辙了，毕竟有这些资源的用户不会一直开着电脑让你白嫖。而 PT 的增强，就是通过记录资源所有者的身份以及上传下载量等数据，让这些用户的分享行为能够得到相应的回报，从而愿意去持续开机进行资源共享，来保证旧资源的下载速度。一般只要资源不是太偏门的那种，跑个几十 MB 每秒都是没问题的。
而且 PT 还有另外一个好处，优秀 PT 站点里面的资源，基本都是经过整理过的高质量内容，清晰度高，也不会有水印之类的，非常适合用来收藏到本地。
4 下载工具
我用到的有两个，下载新资源用 qbittorrent，资源保种用 transmission。
4.1 docker部署
首先是 qbittorrent 的 docker-compose.yml 文件。网页端口可以自行设置，tracker 端口、监听端口和数据上传端口这几个最好还是先删除掉，等登录后确定想要设定的端口，再添加到配置文件中重启一遍。另外，数据上传端口我记得默认配置是不限制的，不过为了方便 bridge 方式部署，可以通过修改传出端口 (下限) 和传出端口 (上限) 为同样的数字，实现只提供一个数据上传端口，从而减少配置文件中要设置的端口映射行数。后面的 transmission 设置也是一样的道理。
version: "3"
services:
qbittorrent:
image: linuxserver/qbittorrent:4.5.5
container_name: qbittorrent
environment:
- PUID=1000
- PGID=1000
- TZ=Asia/Shanghai
- WEBUI_PORT=网页端口
volumes:
- ./qbittorrent/config:/config
- ./qbittorrent/ui/vuetorrent:/ui # 前端页面资源路径
- HTTPS证书路径:/custom/ssl:ro # HTTPS证书路径，可省略
- 资源存储路径:/downloads # 资源存储路径
ports:
- 网页端口:网页端口
- tracker端口:tracker端口
- 监听端口:监听端口
- 监听端口:监听端口/udp
- 数据上传端口:数据上传端口
- 数据上传端口:数据上传端口/udp
restart: no
然后是 transmission 的 docker-compose.yml 文件。
version: "3"
services:
qbittorrent:
image: linuxserver/transmission:2.94-r3-ls53
container_name: transmission
environment:
- PUID=1000
- PGID=1000
- TZ=Asia/Shanghai
- USER=用户名
- PASS=密码
- TRANSMISSION_WEB_HOME=/transmission-web-control/src
volumes:
- ./transmission/config:/config
- ./transmission/transmission-web-control:/transmission-web-control # 前端页面资源路径
- 资源存储路径:/downloads # 资源存储路径
- 种子监听路径:/watch # 种子监听路径
ports:
- 127.0.0.1:9091:9091 # 网页端口
- 监听端口:监听端口
- 监听端口:监听端口/udp
- 数据上传端口:数据上传端口
- 数据上传端口:数据上传端口/udp
restart: no
extra_hosts:
- "tracker地址:cf优选IP"