Preface

For heavy users of emby, the most headache-inducing thing is to migrate the emby server. . . You should know that the film and television resource information generated by scanning the multimedia library and scraping it is stored locally on the emby server. If you re-set up a new emby server and re-scan it, it may take several days if the resource library is large. . This is just the time spent on scanning. You also need to spend time adding media libraries of different categories of film and television resources, and add paths separately (it may not be a big deal for rough people, such as storing all series in a series directory, but for people like me who have classification obsession, it is absolutely unacceptable). If you encounter someone who uses distributed deployment and has to subdivide the folder path under each category (such as me), it will be a headache. For example, the media library of American TV series:

Other similar ones include Japanese dramas, Korean dramas, Chinese dramas, Asian dramas, and cartoons. It's scary. All of them have to be added manually for at least 1 hour. It's so scary!

Some students may ask, why is it so complicated? It is for the convenience of future expansion. My storage structure is: single NAS -> single NAS + USB3.1 hard disk cabinet -> single NAS + 2 original 4-disk storage + USB3.1 hard disk cabinet -> dual NAS + 2 original 4-disk storage + 1 original 8-disk storage + 2 Black Synology 4-disk NAS. This year I will buy 2 more original 4-disk storage. In this large-scale distributed storage environment, the media library path must be subdivided, because it is very likely that the resources of a media library are distributed on multiple devices.

Why is the title "high-end"? Because ordinary people can't use this technique, and those who can use it must be high-end emby users. And why did I write such an article? It's because I have suffered too much loss, and this loss may be the most common for me, at least nearly 20 times. Because I always like to try to create a new emby server in different ways (win, macos, qnap, debian, docker), but I have too many resources. If I completely rescan every time I create a new emby server, it will take at least a few days. This is not an exaggeration. The nas cannot be turned off during the critical period, so electricity is wasted. After learning from the pain, I began to study methods to efficiently migrate film and television resource information.

---

Why am I bringing this up again? Because yesterday I crashed the win11 virtual machine on the pve that I used to display the emby poster wall... The reason was that I wanted to enable WSL to run docker on it, but the virtual machine couldn't start directly, and I couldn't repair it, so I had to reinstall the system. . Then it involved the issue of redeploying the emby server. I actually wrote about this method in an article before, but I didn't mention many details, which made me take a detour and spent at least half an hour more. . So I'll take this opportunity to record the details and write an article casually.

---

key point

In fact, there is only one key point, but it is like a layer of gauze, which is vague if you don't break it, and once you break it, it is not worth mentioning: the programdata directory. No matter which environment emby is set up in, there will be this folder, and the structure in this folder is the same: it contains emby's various user data, plug-ins, media library categories, corresponding resource paths, various scrapers, option parameters, etc., and the key is that it also includes the metadata of all resources. So after creating a new emby server (regardless of whether the deployment method is the same), just copy the programdata folder as a whole, and you will be surprised to find that all the data is directly transferred.

But here are 2 details:
1. The path of programdate

For example, if you migrate a Windows emby to another Windows emby, or migrate a QNAP NAS emby to another QNAP NAS emby, the programdate installation path is the same, such as the default installation path of Windows 11:

Installation path of qnap:
/share/CACHEDEV1_DATA/.qpkg/EmbyServer/programdata

I don't know about Synology's path, because for NAS with the same performance, Synology is much more expensive than Qnap. At most, I bought a few black Synology to recycle the old hard drives, but I didn't install Emby on them, so naturally I don't know.

The paths of programdata in the same environment are the same, and the paths of programdata in different environments are different, but you can find them with some time, and then you can just copy them directly.
2. Media Library Path

After the first step, you will find that the media library information on the new emby server is all there, similar to the following figure:

But the problem is that the corresponding path in the media library is often problematic. Why? Let's look back at the picture above:

Because it is a win system, I use the method of mapping network drives to mount folders on other devices to the local computer, soH:\If the emby programdata folder of win is migrated to qnap, emby on qnap does not recognize this path. Therefore, the migration between different environments still cannot escape the step of deleting all path information and re-adding it in a way that the current environment can recognize. Anyway, it takes 40 minutes here. But compared with a few days, 40 minutes of repeated adding labor is still acceptable to me.

If you are migrating the same environment, you need to see where the local resources are. For example, if my movie resources are on the local hard disk on NAS1, if I migrate emby to NAS2, the local resources on NAS1 will become network resources, and the address still needs to be changed.

The only plug-and-play environment is that emby has no local resources, and all resources are on other storage devices connected to the local network. This can be achieved by setting all network resources to the same local path, such as the mapped network drive letter on my win11 virtual machine. As long as the drive letters on the new and old virtual machines are the same, plug-and-play can be achieved.

Afterword

Let me talk about the scraping problem of emby's MovieDB plugin. From my experience in the past two years, as long as there is no problem with the network, the automatic scraping efficiency of MovieDB is very high, whether it is movie or TV, it is basically above 95%. I used to think that it was only DNS pollution that affected MovieDB scraping, but from my test results today, it seems that using only non-polluted DNS will not work (this conclusion is pending, I have not carefully confirmed it), and the NAS itself The flow must also be scientifically configured. If this is the case, it seems that it is most convenient to configure the system proxy of the NAS itself? Try it when you are in the mood.