I have a QNAP which has a lot of storage, but unfortunately the hw transcoding isn’t working well.
I also have a NUC with an intel i5 6260, which does support hw transcoding.
So I was thinking that I could install the Plex media server in a LXC on proxmox on the nuc, and map the drives from the NAS into the NUC.
So far this is working, I have the hw transcoding tested, I have some of the folders imported.
Secondly, does the folder structure need to be the same?
On the QNAP everything is mounted under /share and some of the folders have capital letters.
So do I need to mimic this on the new system for the metadata to work?
In general, yes. However, you can likely leave out Crash Reports/, Diagnostics, and Logs/ if you’d like. They are only relevant to the existing install, but it won’t harm anything to take them and they are a relatively small part of the installation.
No, your media doesn’t need to be in the same path(s) on the new system. Just pay very close attention to the section in the article “Edit Your Libraries.” Particularly the part where it says to leave the current locations in-place until after the new locations are added and scanned. And make sure to disable “Empty trash automatically after every scan” prior to starting the move.
Finally, and this is just an opinion, unless you have a good reason don’t install in a container. Just use the native package. Installing PMS in a container won’t gain you much (or maybe anything, at least as far as Plex is concerned) and could cause you some additional configuration headache due to drive mounting/mapping/permissions.
Thankyou for clearing that up, the container is an LXC, so it’s almost a normal vm, and this way I can get the hw acceleration to work.
I use the NUC for other things as well (home assistant), so at the moment I can’t dedicate one to this (trying to stay as green as possible), so it can’t be a “complete computer install” for Plex.
The re-scanning is normal, but it should detect all the items in their new locations as duplicates of what was already in the library (if you left the existing paths in place). It sounds like it doesn’t see the old database and metadata at all, which means something likely went awry in the transfer process. Before you added the new paths and started the scan, did it show your existing library and metadata?
Ok, then all the existing items should still be there, as long as you didn’t Empty Trash for the libraries. You can perform a Merge on old and new items which it didn’t properly pick up as duplicates.
It’s strange that it didn’t work automatically for you. As long as your file names match the guidelines, you didn’t have to Fix Match on when you added things originally, and you didn’t change the matching agent after the items were initially added (on the old or new systems), things should “just work.”
I think it was set to empty trash automatically at first, but before adding any new paths I unticked that. I wonder if that made it go wrong? I still have the files, so I guess I could just start over tomorrow
I’d try it again with Empty Trash Automatically disabled from the start. Ideally, this would be disabled on the source system before attempting the transfer. If that’s not possible, make sure the library is not scanned before disabling it.
I started over, disabled it on the source system, and transferred everything again.
I still see ‘fetching metadata’ and ‘matching’ in the alert list. Don’t know if it has to do that?
The matching doesn’t surprise me, it still has to match the “new” files; even the fetching isn’t necessarily a bad thing as there could be new metadata available. But the end result should be that (almost?) everything in your libraries should show up as duplicates when it is all done. Look for the small number in the upper-left poster of an item’s poster (a movie, a particular TV show episode, etc…). If that doesn’t happen it means it wasn’t able to associate the items in their new locations with the existing metadata.
Reasons why it wouldn’t be able to do so:
The agent for the library was changed at some point after the item was originally matched. For example, if your library was originally configured to match with the Plex Movie agent, and you later changed to The Movie Database, all movies before the change will be matched with Plex Movie and all ones after to The Movie Database. When you change a library’s agent it doesn’t automatically go back and re-match the existing items. So, when you migrate your system, it will match all the new items with the new agent and not associate them with the existing metadata for movies matched with the old one. In this case you’ll end up with the same item in your library twice, not as a duplicate. These can be merged.
The item was never properly matched to begin with due to a naming issue, and potentially corrected by doing a Fix Match. This case is similar to the first in that you could potentially end up with a mis-matched agent between what the old system matched to and the new system does.
Either way, hopefully you’ll end up with a new system with most items matched and showing duplicates and any outliers can be corrected. Ultimately the outcome of this process will depend upon how good a shape your libraries were in on the source system.