Preface

For heavy Emby users, nothing is more of a headache than migrating an Emby server... You should know that the movie and TV resource information, which is painstakingly scanned and scraped into the media library, is stored locally on the Emby server. If you set up a new Emby server and rescan from scratch, it could take several days if your library is large... And that's just the scanning time. You also have to spend time adding media libraries for different categories of video resources, while adding paths for each of them individually (this might not matter to casual users, like having a single TV show directory for all series, but for someone like me with OCD about categorization, it is absolutely unacceptable). If you encounter someone who uses distributed deployment and needs to subdivide folder paths under each category (like me), it is truly mind-boggling. Take the US TV shows media library, for example:

The same goes for Japanese dramas, Korean dramas, Chinese mainland dramas, Asian dramas, and cartoons. It's terrifying—adding them all manually would take at least an hour. So scary!

Some of you might ask, why make it so complicated? It's all for the convenience of future expansion. My storage structure evolved from: single NAS -> single NAS + USB 3.1 HDD enclosure -> single NAS + two original 4-bay storage units + USB 3.1 HDD enclosure -> dual NAS + two original 4-bay storage units + one original 8-bay storage unit + two custom Synology 4-bay NAS units, and this year I have to buy two more original 4-bay storage units... In such a large-scale distributed storage environment, media library paths must be subdivided because resources for a single media library are very likely distributed across multiple devices.

So why does the title say "high-end"? Because average users won't need this trick; those who do are definitely high-end Emby users. And why am I writing this article? It's because I've learned the hard way too many times—and this is a lesson that maybe I encounter more often than anyone else, at least nearly 20 times... Because I always like to try building Emby servers in different ways (Windows, macOS, QNAP, Debian, Docker). But I have way too many resources. If I completely rescan every time I set up a new Emby server, it takes at least several days. This is no exaggeration at all. Crucially, you can't turn off the NAS during this time, which also wastes electricity... After painful reflection, I finally started researching efficient methods to migrate movie and TV resource information.

---

Why did I suddenly bring this up again? Because yesterday, I crashed the Windows 11 VM on my PVE (Proxmox VE) that I use for the Emby poster wall display... It started because I wanted to enable WSL on it to run Docker. As a result, as soon as the VM booted, it failed to start completely. It couldn't even be repaired, so I had to reinstall the OS... Then, it came down to the issue of redeploying the Emby server again. Actually, I had written about this method in an article before, but many details were left out, which caused me to take a detour and waste at least an extra half hour... So, I'll take this opportunity to document the details and write a quick post.

---

Key point

Actually, there is only one key point, but it's like a thin veil—blurry until you pierce it, and once pierced, it's not even worth mentioning: the programdata directory. No matter what environment Emby is set up in, this folder will exist, and its internal structure is always the same. It contains all kinds of Emby user data, plugins, media library categories, corresponding resource paths, various scrapers, option parameters, and so on. Crucially, it also includes the metadata for all resources. Therefore, after setting up a new Emby server (regardless of whether the deployment method is the same), as long as you copy this entire programdata folder over, you will be amazed to find that all the data is transferred directly.

However, there are two details here:
The path of programdata

For example, migrating Emby on Windows to Emby on another Windows, or Emby on QNAP NAS to Emby on another QNAP NAS, the programdata installation path is the same, such as the default installation path of Win11:

QNAP's installation path:
/share/CACHEDEV1_DATA/.qpkg/EmbyServer/programdata

I don't know the path for Synology, because for NAS with the same performance, Synology is much more expensive than QNAP. At most, I just buy a few Xpenology (cracked Synology) units to reuse old hard drives, but I haven't installed Emby on them, so naturally, I don't know.

In the same environment, the programdata paths are consistent. In different environments, the programdata paths are different, but they can all be found with a little time, and then you can just copy them directly in the same way.
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 image below:

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

Because it is a Windows system, I used the mapped network drive method to mount folders from other devices locally, which is why it is theH:\path. However, if this Windows Emby programdata folder is migrated to QNAP, Emby on QNAP won't recognize this kind of path. Therefore, migration between different environments still cannot escape the step of deleting all path information and re-adding them in a way that the current environment can recognize. Anyway, it takes me about 40 minutes. But compared to a few days, I can still accept 40 minutes of repetitive adding labor.

If it is a migration within the same environment, it depends on where the local resources are. For example, if my movie resources are on the local hard drive of NAS1, and I migrate Emby to NAS2, then the local resources on NAS1 become network resources, and the address still needs to change.

The only plug-and-play environment is when Emby has no local resources at all, and all resources are connected to other storage devices through 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 old and new virtual machines are the same, it can be plug-and-play.

Afterword

Let's also talk briefly about the scraping issue of Emby's MovieDB plugin. From my 2 years of use, as long as there are no network issues, MovieDB's automatic scraping efficiency is very high. Whether it is movies or TV shows, it is basically over 95%. I used to think that only DNS pollution affected MovieDB scraping, but from my test results today, it seems that using only clean DNS is not enough (this conclusion is pending, I haven't confirmed it carefully). The NAS's own traffic also needs to use a proxy/VPN. If that's the case, it seems configuring the NAS's own system proxy is the most convenient? I'll try it when I'm in the mood.