前情提要
一年多前我写了一篇随笔记录过使用Jellyfin和Finamp的体验，在之后我也使用了音流、Poweramp来听歌也用着十分满意，其中音流不知是因为接的Audio Station打了歌词插件还是别的什么原因，居然自带歌词搜索，只是不能保存在本地和Jellyfin实现联动着实可惜。
而音流的离线模式没有专辑图片着实不爽（也可能是自己没设置对），并且到底也就是移动端用用音流没有Jellyfin那么全面，所以依然是Jellyfin+Finamp这套组合最深得我心。
两年间几次出门在外打开Finamp阅读歌词听音乐都成为了我最快乐的回忆之一。
然而有一天在外却发现Jellyfin莫名远程连不上了，本以为是网络或者Nginx的问题想回上海再处理，但回家后打开NAS却发现是Jellyfin本身居然启动不了了，能看到的现象是开启NAS正常启动，但是一访问网页打不开、套件也会强制结束，再看套件中心已经是非启动状态了（图片后来补截的，图里已经完整卸载了，悲）。
这里要说一下，我是直接加社区的软件源安装的第三方套件，即没有使用docker也没有使用群晖官方的Jellyfin套件（应该是当时没下载下来或版本太低了）；没有使用docker的主要原因是当初不知为什么找不到可以正常部署在Container Manager里面的docker包（要不就是都拉不下来，我现在依然不怎么使用docker也是实在不想碰docker源的拉取问题）。
既然坏了就想着按步骤：
先试着修；
修不好就保留数据卸载重装；
装不好拉媒体库和配置跑路。
第一步和第二步很快宣告失败，由于我此前是安装即用，我根本不清楚哪里能看到异常信息，ssh登陆进NAS也没找到Jellyfin这个服务的蛛丝马迹，而且重装也是一样启动后访问就挂。
于是很快我就决定从头开始安装，但由于感受到无法自己排查问题的无力，我的心态已经发生了一点变化：我还是得自己部署一下Jellyfin，毕竟它带给了我很多快乐，我不想轻易失去它。
好在出于一些别的项目需要，我早就为NAS所在的局域网配备了一台安装Ubuntu22.04的主机，在正式开始部署前，先列一些笔者设备的信息：
NAS型号：群晖DS718+（已扩展DX517）
NAS系统：DSM 7.2.1-69057
PC型号：天钡GEM12 MAX（R9-6900HX）
PC系统：Ubuntu22.04
NAS和PC网络示意：
此次记录的内容有点多，本来想分上下两篇的，但出于连贯与完整考虑，还是都放在一起，着急解决问题或是想快速判断本文是否有益的朋友快速定位二级标题即可。
一、为PC部署 Jellyfin Server 10.10.7
就写这篇随笔时Jellyfin10.11.x依然没有十分稳定（也不知道有啥感兴趣的新特性），我选择10.10.7版本进行部署，先去官网 https://jellyfin.org/downloads/server/ 找到下载链接，看到可以为自己的“呆唯系统”下载.deb进行安装。
有.deb这就很简单了，不过也是踩了个小坑，就是要老实使用sudo apt install而非sudo dpkg -i，否则jellyfin-server的几个依赖不会随安装而下载（我居然从没有踩过这个坑，一直是看心情随机使用apt和dpkg......）。
如果有重复安装jellyfin-server后提示服务需要unmask而启动不了的情况，论坛上也给出了方法：
正确使用apt安装好后按理会自动启动Jellyfin Server的服务，我观察了安装过程，看到服务就叫jellyfin.service。用systemctl检查一下状态（不知道为什么这张图片b站上传不上来，只能口头描述了），发现红字提示“Failed to start Jellyfin Media Server.”又给我来了个下马威。
我自己在终端试着启动，根据输出日志提示在网上搜索解决办法，看了几个issue和论坛上的解答，有换安装方式的、也有手动做软链接的。但感觉无非都是缺少了两样东西：jellyfin的客户端（我理解就是webui）和一个叫jellyfin-ffmpeg的库。
而且这个问题好像由来已久，几年间都有人遇到过类似的问题，比如下面这两个issue：
二、解决缺少 jellyfin-web 的问题
好吧，根据缺啥补啥的道理，得先了解一下从哪里才能搞到这两个东西，因为网上提到解决jellyfin-web缺失的软链接方法中需要执行类似 ln -s /usr/share/jellyfin/web/ /usr/lib/jellyfin/bin/jellyfin-web ：
而我却连/usr/share/jellyfin/web/这个都没有，只得回到Jellyfin项目中去找，发现Jellyfin开发组下的项目有这些内容：
把这红框出的jellyfin-web和jellyfin-ffmpeg补上应该就万事大吉了，不过其实我在jellyfin10.10.7项目源码目录中已经发现了这个jellyfin-web，也不用多找了，直接把它复制到/usr/share/jellyfin/web/并补上软链接。
三、解决缺少 jellyfin-ffmpeg 的问题
这个问题我其实没有在网上找到现成的直接方法，但根据几位开发者和网友的提示，自己找了个可行的方法（可能有点野，不一定是好的方法，but it works）。首先要感谢这位老哥的提示：
大意提醒的是Jellyfin这种服务运行往往需要环境变量，你无法在shell中直接输入jellyfin运行（即便你可以）来观察日志排查问题。这个道理应该很多开发人员都懂，正确的做法是使用journalctl，比如使用 journalctl -u jellyfin -f 来定向展示jellyfin服务的输出，这提醒了我要回到项目的配置和环境变量中排查启动不了的原因。
于是我通过服务指向的配置文件jellyfin.service.conf检查了配置并对比了日志输出：
就是默认配置指向的/usr/lib/jellyfin-ffmpeg/ffmpeg并不存在，本来计划将jellyfin-ffmpeg安装一下的，但是我在仓库里面并未找到能够对应ubuntu22.04的版本，全是妹妹debain的deb文件，甚至也没看到它们和jellyfin的版本有何对应关系（应该本来就没有关系），难道我自己随便整个家庭影院还要搞源码安装吗......
于是转变思路，检查起这个jellyfin-ffmpeg项目本身来，其中虽然有很多开发项，却基本属于是jellyfin对于经典框架ffmpeg的一个fork项目，那么我猜想直接使用ffmpeg未必不可行，jellyfin指向的或许只是个fork出来的bin而已。
那这不巧了吗，我PC中本身就安装有ffmpeg，于是我直接修改配置项指向系统内的/usr/bin/ffmpeg，版本是apt默认安装版本7:4.4.2。
不知什么时候安装的ffmpeg，版本感觉还挺新。
sudo systemctl restart jellyfin.service 重启服务后，jellyfin就正常了：
但是我自己都还没复盘这个方法到底是不是长期靠谱的，按理说jellyfin-ffmpeg和ffmpeg相比肯定是有些改动的。但是能够启动就能试着使用，我迫不及待去浏览器打开localhost:8096，真的能正常登陆了！
四、通过NFS将NAS目录挂载到Ubuntu
虽然能够在PC端启动Jellyfin了，但是PC的存储和NAS的可完全不是一个量级，我原先的媒体全部都在NAS上，移动到PC存储根本不现实，于是就需要远程访问共享文件夹了。
NFS（Network File System）即网络文件系统，详细的内容就不多说了，它适用于两台Linux主机之间进行网络文件共享，十分符合我这次部署的使用场景。此前我因为其他项目已经将部分NAS的目录挂载到PC。不同品牌NAS开启NFS的方法应该都不尽相同，运行Ubuntu的PC方应该不用安装额外的包（由于是之前开的NFS，PC这边有没有安装小工具已经忘了www）。
要开启群晖NAS的NFS需要打开 控制面板->文件服务->NFS，将启用NFS服务勾选上，我选用的是NFSv4协议。
随后要对应配置共享文件夹的NFS权限，可以设置多条权限规则。新建一条规则，服务器名称或IP地址填想开启访问权限的PC端的局域网ip，这里我本来想只配置只读，但测试下来还是需要读写权限Jellyfin才可以列出文件夹：
有了完整权限就可以让PC去挂载NAS的共享文件夹了，当然完整的设置是需要配置自动挂载。在配置前我们可以先命令行测试一下，以我想将NAS方的/volume1/music目录挂载到PC下的/mnt/nas_music为例，正常挂载命令是 sudo mount -t nfs4 192.168.3.80:/volume1/music /mnt/nas_music，挂载完可以从PC侧访问到NAS上的文件目录。
自动挂载则需要修改/etc/fstab，这是Linux系统的自动挂载配置文件，一条完整的nfs挂载条目可以是 192.168.3.80:/volume1/music /mnt/nas_music nfs vers=4,port=2049,_netdev,noauto,x-systemd.automount 0 0 。此前我将Jellyfin读取的媒体都保存在music和video两个目录下，设置完后我的配置文件是这样的（新增两条），这样PC启动就会自动挂载上新的这两个目录，不用每次手动挂载了：
既然挂载上了就开始添加媒体库吧，时隔多月我又去github下载了最新的Finamp稳定版（0.9.20版本），我的媒体库终于都回来了！
好像Jellyfin还支持有声书籍，下次可以扩展一下书库www。
至于旧Jellyfin数据其实我还是从NAS拷贝出来了，但是后来并没有派上用场：设置还是在Web端操作，至于元数据大部分都保存在媒体文件夹一起，所以很快就刮完了。
如果真的有需要的可以参考下面图片中的目录，群晖套件安装的Jellyfin数据就保存在@appdata下面，而@开头的应该都是需要su权限访问的隐藏目录，如果要拷贝需要ssh登陆群晖后进入su权限，cp到用户可视目录下（比如/volume1/homes/Username/）就可以从群晖的DSM界面上下载了。
五、NAS和PC的共同启停
随着Jellyfin成功在PC上完成部署，自己忽然意识到NAS和PC的启动和关机都比较独立：
NAS和PC都没有常开，一是我认为常开不利于硬盘寿命，二是一直开着确实有点吵会打扰到家人，一时间不用服务也就不会开启了；
NAS此前一直通过蒲公英组网盒子（P5）提供的WOL唤醒功能唤醒，晚上定时关闭；
PC设置的上电自启动，电源接在可远程控制开关的插座上，有时关机就直接下电（更多时候是根本忘记关掉）。
现在看来它们两个已经彼此紧密关联，需要把它们看作一体来简化启动和关机了，于是就准备新增一条从PC唤醒NAS的WOL线路，并为PC设置定时关机，示意如下：
具体分为以下几步：
sudo apt install wakeonlan 安装发起魔术包的工具；
根据NAS和唤醒方是否在同一子网选择不同命令测试（不在同一子网需要指定ip或广播）；
设置一个wakeonlan_nas.service服务指向存放wakeonlan命令的shell脚本（记得chmod给到可执行权限）。
由于我的机器和NAS在同一局域网内，直接使用wakeonlan <NAS的MAC地址>就成功了。
解决完同步启动，再配置（伪）同步关机，通过cron工具设置周期性任务，将PC关机时间设置得和NAS保持一致就符合我的需求了。
这里注意需要 sudo crontab -e 编辑加入关机任务，因为shutdown是需要sudo权限的，执行后选择顺手的编辑器（一般nano或者vim）打开后能看到如下文件：
以每日定时关机为例，可直接在最后一行添加 0 23 * * * /sbin/shutdown -h now ，或根据注释提示添加你想设置的周期。
设置完任务后可以sudo crontab -l检查一下是否已完整添加（我添加的是每日12点50分和1点关机，12点50分是为了一开始设置时测试用）：
先提前关闭NAS，待测试时间一到PC自动关机，随后用我的远程开关给PC下电后上电，PC正常上电启动，没多久NAS接受到PC发送的唤醒也正常启动，这一轮共同启停就设置完了。
六、重新配置Nginx以支持QuickConnect远程访问
在旧Jellyfin健在的时候，我就已经手动在NAS上新增过了一条Nginx代理规则，将群晖quickconnect地址的/jellyfin代理到本机8096端口，如下链接操作：
https://blog.csdn.net/u013005016/article/details/128997711
这一转发的成功点在于要同时设置Jellyfin内部的基础URL为相同的/jellyfin（与Nginx转发设置保持一致即可，可以叫别的名字）。
有了这两方设置，quickconnect远程访问就能够顺利转发到Jellyfin服务器了，原理其实和群晖自己支持的文件以及相册Station远程访问一致。
我想有了这些个配置基础应该能很快转发到新的Jellyfin服务器上，不过令我担忧的是Nginx转发有时不是万能的，不知道Jellyfin代理到局域网其他ip会不会有新的问题（比如跨域之类的），好在没有遇到，只是将原有的NAS本机IP改为PC的局域网IP就大功告成了。
七、为自建的Jellyfin添加代理和第三方插件
自己部署就能够搞点以前黑盒安装时做不了的操作了，就比如为Jellyfin设置代理实现科学上网刮削元数据。在群晖Jellyfin中我能够知道的只是在Jellyfin管理界面添加代理，也没去尝试过（因为看上去好像不是很好用）。但既然已经在Ubuntu中部署，设置个代理、搞点之前用不了的插件那还不手到擒来。
这里设置代理主要是参考 https://blog.csdn.net/AAMahone/article/details/128966904?utm_medium=distribute.pc_relevant.none-task-blog-2~default~baidujs_baidulandingword~default-0-128966904-blog-145459102.235^v43^pc_blog_bottom_relevance_base8&spm=1001.2101.3001.4242.1&utm_relevant_index=3
里面写的很详细了，我采用的是EnvironmentFile的写法，有点不一样的是，我安装完Jellyfin启动服务后看到下面已经挂有.conf文件，所以是直接vim这个文件添加的环境变量。
顺带一提我用的kexueshangwang的工具是N开头的（好像已经不再维护了），话密一下就叫它“猫瑞”吧。这里做了如下两步操作：
为了保证Jellyfin和代理能够同时存在，我也给猫瑞勾选了开机自启和保留上一次记录；
为了自己在PC开着代理访问群晖的体验还在猫瑞上配置了需要直连访问的IP（取消代理），因为不额外设置的话，开着代理在局域网连群晖IP进DSM就连不上了。
如下在猫瑞的路由设置里面给局域网网段192.168.3.0加上直连，局域网访问群晖DSM就不需要先关代理了：
这里还有个值得说道的直连ip就是127.0.0.1（即本机），如果不设置本机直连会发生Jellyfin请求本机HTTP服务无响应、返回为空的情况。这是在参考 https://liuhouliang.com/post/jellyfin_metatube/ 添加Metatube插件时发现的问题（至于你问我为什么要加这个插件，我说感觉这是一个很好的练手作业你信吗，咳咳）。
根据参考链接里面的大纲，需要让这个插件能够完整Work需要如下几步工作：
也就是说这个插件是可以指定后端并依赖一个后端服务的，我自然想将这个后端服务也安装在PC上集中管理。我选择的是下载Linux可执行文件来部署，没有选择docker（不用docker原因同上，真心觉得docker不好用）。安装插件、配置插件和启动服务的过程都比较顺利，只是先后遇到了两个问题：
Jellyfin侧提示使用Metatube插件时JSON解析错误；
解决完问题1后，后端服务HTTP请求404。
问题1的答案就是上上一张图中猫瑞路由设置中的127.0.0.1，我通过curl命令检查HTTP请求发现开着代理时127.0.0.1本机请求没有正常处理（localhost正常处理了，但是给插件Server设置localhost也无作用）。
问题2的答案仅仅是和为Jellyfin设置代理一样，我也要为Metatube的后端服务提供代理的环境变量，否则不会通过代理端口去请求。于是复用一下之前给Jellyfin配置的EnvironmentFile，随后再测试就能够看到双方HTTP请求正常，并且猫瑞处的日志也能看到Metatube后端服务发来的请求了。呼，一切大功告成。
后记
这次折腾完也没有什么高深的见解，自2022年以来生活的混沌感越来越重，值得拒绝却没有拒绝的事接踵而来，积压的想写的东西、想完成的事却一点没有减少。
只是这种为自己小天地添砖加瓦的安心感又给了我些许去往天南海北的勇气。
