前言

对于emby的重度用户而言，最头痛的事莫过于迁移emby服务器了。。。要知道平时辛苦扫描多媒体库并刮削生成的影视资源信息都是存储在emby服务器本地的，如果重新架设新的emby服务器并重新扫描，资源库大的话可能需要好几天的时间。。这还只是扫描花的时间，还要花时间添加不同类别影视资源的媒体库，同时还要分别添加路径(粗旷的人可能没啥，比如一个剧集目录存放所有连续剧，但是对于我这种有分类强迫症的人来说，是绝不能接受的)，如果是遇到采用分布式部署并且每个类别下面还要细分文件夹路径的人来说(比如我)，那真是要头大死了，例如美剧的媒体库：

其他同样的还有日剧、韩剧、陆剧、亚剧、卡通，很恐怖的，全部手动添加起码1小时起，好吓人！

可能有同学要问了，为啥搞这么复杂？还不是为了以后扩容方便，我的存储结构从：单一NAS—>单一NAS+usb3.1硬盘柜—>单一NAS+2个原厂4盘位存储+usb3.1硬盘柜—>双NAS+2个原厂4盘位存储+1个原厂8盘位存储+2个黑群晖4盘位NAS，今年又要买2个原厂4盘位存储。。在这种大型分布式存储的环境下，媒体库路径是必须要细分开来，因为很可能一个媒体库的资源是分布在多台设备上。

那为啥题目要说高端？因为一般人用不上这个技巧，能用得上的肯定是高端emby用户了。而为什么我会写这么一篇文章？还不是因为吃了太多亏了，而且这个亏说不定就我一个人最常遇到，起码将近20次了。。因为我老是喜欢尝试用不同的方式新建emby服务器（win，macos，qnap，debian，docker），但是我的资源实在是太多了，每次新建一个emby服务器都完全重新扫描的话，起码会消耗几天的时间，这个可真是一点都不夸张，关键期间不能关nas，所以又浪费电。。。痛定思痛后，我才开始研究高效迁移影视资源信息的方法。

---

为啥我忽然又提起这事？因为我昨天把我用来做emby海报墙展示的pve上的win11虚拟机搞崩了。。。起因是我想在上面启用WSL来跑docker，结果一起虚拟机就直接无法启动，修复都修复不了，只能重装系统。。然后就又涉及到重新部署emby服务器的问题。而我以前其实也用文章来写过这个方法，但是很多细节没提到，害得我自己走了弯路起码多花了半个小时。。所以将就这次机会记录一下细节，随便水一篇文章。

---

关键点

其实最关键的点只有一个，不过这个就像一层纱，不捅破就模模糊糊，一旦捅破就不值一提：就是programdata这个目录。不管emby是架设在哪种环境里，都会有这个文件夹，并且这个文件夹里面的结构都是一样的：包含了emby的各种用户数据、插件、媒体库分类、对应资源的路径、各种刮削器，选项参数等都一应俱全，关键还包括了所有资源的元数据，所以新建一个emby服务器以后(不管部署方式是不是一样)，只要把这个programdata文件夹整体拷贝过去，那么你会惊奇的发现所有数据都直接过去了。

不过这里有个2个细节：
1、programdate的路径

比如win的emby迁移到另一个win的emby，qnap nas的emby迁移到另一个qnap nas的emby，programdate安装路径是一样的，比如win11的默认安装路径：

qnap的安装路径：
/share/CACHEDEV1_DATA/.qpkg/EmbyServer/programdata

群晖的路径我不知道，因为相同性能的NAS，群晖比qnap贵多了，我顶多就是买几个黑群晖来利旧老的硬盘，却没有在上面装emby，自然也就不知道了。

相同环境programdata的路径都是一致的，不同环境programdata的路径不一样，不过花点时间都能找到，然后还是一样的直接拷贝即可。
2、媒体库路径

经过第一步之后，你会发现新emby服务器上的媒体库信息都在，类似下图：

但是问题在于，媒体库里对应的路径往往是有问题的，为什么？我们看回上面那张图：

因为是win系统，我是用的映射网络驱动器的方式把其他设备上的文件夹挂载到本地，所以才是H:\的路径，而如果这个win的emby programdata文件夹迁移到了qnap，qnap上的emby可不认识这种路径，所以，不同环境之前的迁移还是逃不过删除所有路径信息再用当前环境能识别的方式重新添加这一步，反正我这边要40分钟。可和几天时间比起来，40分钟的重复添加劳动我还是能够接受的。。

如果是相同环境迁移，要看本地资源的在哪里，比如我电影资源在NAS1上的本地硬盘上，如果我把emby迁移NAS2上，那NAS1上的本地资源就变成了网络资源，地址还是要变的。

唯一一种可以即插即用的环境，就是emby本地啥资源都没有，全是通过本地网络连的其他存储设备上的资源，这种可以通过将所有网络资源设置为一样的本地路径，比如我的win11虚拟机上的映射网络驱动器盘符，只要新旧虚拟机上盘符是一样的，就可以做到即插即用。

后话

随便再说说emby的MovieDB插件刮削的问题。从我这2年的使用来看，只要网络不存在问题，MovieDB的自动刮削效率是非常高的，不管是movie还是TV，基本都是95%以上。我以前认为影响MovieDB刮削的只是DNS污染，但是从我今天的测试结果来看，似乎只用无污染DNS也不行(这个结论待定，我没有仔细确认过)，NAS本身流量也采用科学的方式才行，如果是这样似乎还是配置好NAS本身的系统代理才最方便？有心情的时候试试吧。