best procedure to reinstall Plex on existing hardware but new operating system?

General Discussions
1

Hi,

I studied this, which is about moving to a different machine, figuring it would be close to what I want. But it looks to me like Plex ignored my existing data.

Here’s the background: I have a PMS with the operating system on one drive, all the data on other drives. Call them data drives. When I first installed Plex way back when I put it (ie, plexmediaserver directory) on a data drive. Every week I run scheduled backups that archive all of the directories from the plexmediaserver directory and on down. The archive is stored on the same data drive and a copy of the archive is stored on another data drive.

Now I’ve updated the operating system, including a reinstall of Plex. Before I updated the operating system I forced another backup so I would have the most current Plex data saved.

One complication: I’m using a drive pooling product that yields a different path name for the root directory of my videos, but really points to the same place. For example, the full path to the TV folder before and after the OS update:

old: /media/9b55d2c2-1cc9-40eb-99dd-f9a8032a0f4c/TV
new: /media/8880fb3a-466e-4da2-b244-2a36015f041b/TV

The paths look different, but they’re pointing to the same place really. But this may be enough to hurt. Read on.

After updating the operating system I reinstalled Plex, pointing Plex to the location of the existing plexmediaserver directory. When I started Plex he didn’t know about any Libraries. When I added a Library (TV for example), he of course found the TV videos but started rebuilding all the metadata about them. I was hoping he’d see that the data already existed. But noooooooooooooooooo!

It’s possible that what I concluded about reinstalling Plex isn’t correct. Maybe I have to restore the archived data on top of the existing plexmediaserver directories, because maybe the reinstall of Plex reset some information and/or wiped out the data in the existing directories. Or maybe I’m just out of luck because the path names have changed.

Thoughts please?

Thanks,
Mark

2

What are you installing on? While I’m pretty confident it’s a linux distribution, your reference to drive pooling is a but confusing as the UUID mount points imply the system is doing the mount automatically versus you taking manual control of where / how to mount the drives.

If I am correct, we can ‘migrate’, by use of symlinks, from an uncontrolled/unpredictable mount point structure to a predictable one.

Please advise and help me with as much information as you can about actual distro and your desired storage configuration.

3

This is Debian Jessie with OpenMediaVault 3 installed on top of it. The UUIDs for the existing data drives have not changed between OS upgrades. Except for the UUID for the pooling product: mergerfs

I have a support question out to mergerfs about whether the changed UUID can be set back to the old value.

Here’s what the relevant fstab entries for the data drives & mergerfs looked like before the upgrade:

    UUID=c32f97f7-2d5a-4dc1-905f-f328799918f4 /media/c32f97f7-2d5a-4dc1-905f-f328799918f4 xfs defaults,nofail,usrquota,grpquota,inode64 0 2
    UUID=9631a1ae-6197-4bce-8359-db150bb7fe85 /media/9631a1ae-6197-4bce-8359-db150bb7fe85 xfs defaults,nofail,noexec,usrquota,grpquota,inode64 0 2
    UUID=538c1184-17bd-455f-8455-09c0a7901c70 /media/538c1184-17bd-455f-8455-09c0a7901c70 xfs defaults,nofail,noexec,usrquota,grpquota,inode64 0 2
    UUID=44e5d790-13ef-4433-a08f-df03683682a3 /media/44e5d790-13ef-4433-a08f-df03683682a3 xfs defaults,nofail,noexec,usrquota,grpquota,inode64 0 2
     UUID=f0e62054-1871-4bda-85cd-4a108e1667ba /media/f0e62054-1871-4bda-85cd-4a108e1667ba xfs defaults,nofail,noexec,usrquota,grpquota,inode64 0 2
    UUID=14d8e6d6-81c6-41df-820a-b58d825b5e1e /media/14d8e6d6-81c6-41df-820a-b58d825b5e1e xfs defaults,nofail,noexec,usrquota,grpquota,inode64 0 2
    UUID=bca59104-556f-4380-8180-494e9feed56d /media/bca59104-556f-4380-8180-494e9feed56d xfs defaults,nofail,noexec,usrquota,grpquota,inode64 0 2

/media/9631a1ae-6197-4bce-8359-db150bb7fe85:/media/538c1184-17bd-455f-8455-09c0a7901c70:/media/44e5d790-13ef-4433-a08f-df03683682a3:/media/f0e62054-1871-4bda-85cd-4a108e1667ba:/media/14d8e6d6-81c6-41df-820a-b58d825b5e1e:/media/bca59104-556f-4380-8180-494e9feed56d /media/9b55d2c2-1cc9-40eb-99dd-f9a8032a0f4c fuse.mergerfs defaults,allow_other,use_ino,category.create=epmfs,minfreespace=20G 0 0

and here’s after the upgrade:

UUID=c32f97f7-2d5a-4dc1-905f-f328799918f4 /media/c32f97f7-2d5a-4dc1-905f-f328799918f4 xfs defaults,nofail,noexec,usrquota,grpquota,inode64 0 2
UUID=9631a1ae-6197-4bce-8359-db150bb7fe85 /media/9631a1ae-6197-4bce-8359-db150bb7fe85 xfs defaults,nofail,noexec,usrquota,grpquota,inode64 0 2
UUID=538c1184-17bd-455f-8455-09c0a7901c70 /media/538c1184-17bd-455f-8455-09c0a7901c70 xfs defaults,nofail,noexec,usrquota,grpquota,inode64 0 2
UUID=44e5d790-13ef-4433-a08f-df03683682a3 /media/44e5d790-13ef-4433-a08f-df03683682a3 xfs defaults,nofail,noexec,usrquota,grpquota,inode64 0 2
UUID=f0e62054-1871-4bda-85cd-4a108e1667ba /media/f0e62054-1871-4bda-85cd-4a108e1667ba xfs defaults,nofail,noexec,usrquota,grpquota,inode64 0 2
UUID=14d8e6d6-81c6-41df-820a-b58d825b5e1e /media/14d8e6d6-81c6-41df-820a-b58d825b5e1e xfs defaults,nofail,noexec,usrquota,grpquota,inode64 0 2
UUID=bca59104-556f-4380-8180-494e9feed56d /media/bca59104-556f-4380-8180-494e9feed56d xfs defaults,nofail,noexec,usrquota,grpquota,inode64 0 2

/media/538c1184-17bd-455f-8455-09c0a7901c70:/media/44e5d790-13ef-4433-a08f-df03683682a3:/media/bca59104-556f-4380-8180-494e9feed56d:/media/14d8e6d6-81c6-41df-820a-b58d825b5e1e:/media/9631a1ae-6197-4bce-8359-db150bb7fe85:/media/f0e62054-1871-4bda-85cd-4a108e1667ba /media/8880fb3a-466e-4da2-b244-2a36015f041b fuse.mergerfs defaults,allow_other,use_ino,category.create=epmfs,minfreespace=4G 0 0

The key difference is the last line in each, which is the mergerfs entry. That’s how the paths that I use in Library creation are formed.

I think I understand what you’re saying about symbolic links, but I don’t know whether that’s safe to do while mergerfs is handling the pooling.

I guess if I knew whether or not this even mattered would help a lot. Maybe Plex doesn’t really care about the paths to the videos changing. He’s pointing to the same videos as before and provided he doesn’t key on the full path to match the metadata for them, he might be okay. If that’s the case, then maybe the install of Plex hosed the existing data and I just need to copy my archived data into the existing plexmediaserver directories.

It’s 500 GB of library data so I don’t want to experiment without at least a little more knowledge first.

Thanks!
Mark

PS Sorry, I can’t get the Code formatting to work correctly with these multi-line blocks.

4

Okay, mergerfs support just got back to me. mergerfs doesn’t give a hoot what the UUID is, it’s just a mount point. I will change the mergerfs fstab entry to use the old UUID.

But I’m still hanging on whether I’ve done the upgrade correctly as far as Plex is concerned. Namely, point Plex to the existing plexmediaserver? Not replacinig the existing plexmediaserver content with archived?

5

No problem on the editing. I helped out for both our sakes. Little trick: Double line spacing before attempting to Code format the highlighted paragraph. :slight_smile:

Now, Where I’m thinking is:

Step 1

  1. You know the old UUID where it was mounted. (the last line)
  2. You know the new UUID where it is mounted.
  3. If the entry for the OLD is not present, AND there is no danger to your FS integrity by creating a symlink,
  4. Create a symlink from the old which resolves to the new.

Step 2

  1. Create a more Human-readable mount point somewhere
  2. After all those mounts are complete, at the bottom of /etc/fstab,
  3. Perform a ‘bind’ mount of the UUID mount point to the human-readable mount point.
  4. Point PMS at the Human-readable mount point.

If this makes sense and you want to continue, I’ll help with the procedure but it’s not that difficult.

6

We posted simultaneously.

We can retain the PMS metadata / watched flags if we reference BOTH old and cross-mounted new locations before removing the old.

This is the equivalent symlink trick I referenced above.

e.g.

Mount on /disk/A, PMS knows /disk/A
Change mount to /disk/B but also create symlink /disk/A -> /disk/B
Start PMS
Add /disk/B to the list of Library directories and update the library (watch it show duplicates).
after all dupes register in all libraries,
Remove /disk/A from the list of Library directories.

7

Oh, dear. I’m confused. Let me be clear on one thing, then I’ll come back to you with more questions:

Is it correct to point Plex to the existing data when reinstalling? Should I replace the current data with the archived data? Perhaps the existing data is at least partially hosed because Plex was building metadata for a library when I stopped the service.

8

'Allo 'allo?

9

Sorry, I’m “up to my eyeballs in alligators whilst trying to drain the swamp” :slight_smile:

When you transfer your system… moving from one to another, PMS must know (when it makes its library scan) the media still exists somewhere).

Here are a few support articles which can probably answer your questions better than I in a 1-1 exchange

10

@ChuckPA said:
When you transfer your system… moving from one to another, PMS must know (when it makes its library scan) the media still exists somewhere).
WHICH media? The actual videos, all 15 TB of them? Or the Plex data ABOUT the media, which I assume is plexmediaserver dir and below.

I’ve read the support articles and I’m always stumbling over the same points when I try to apply it to my scenario. Anyway, I can’t find any support article about re-installing Plex on the SAME hardware with everything in the ONE and ONLY location it’s in and always has been in. I’m not moving the videos or the Plex data. Surely there’s a way to re-install Plex and point it to the existing data and be done?

11

No… I wasn’t implying moving the actual media. That would not be practical.

What I am referring to is the typical cases where

a) the data is on a NAS and you wish to take the PMS ‘installation’ (all the metadata) to another computer
or
b) you have a bunch of local HDs and now want to move to the NAS

These are the most common.

When you are moving from dissimilar OS types (Windows v Linux), mapping things becomes more complex because of how the top level is named (X:\ versus /nas/movies as example).

For you, Let assume your data is in the same place, on a NAS and you’re moving from Linux - Linux. The only thing you need do is emulate the old mount points long enough to transition to the new mount points (edit the directory names associated with each library).

Am I making sense?

12

Let me follow up based on our earlier posts:

  1. You installed the new OS.
  2. You have the existing Plex ‘Library’ (containing all the information Plex knows ABOUT your media)
  3. In order to make the transition “after the fact”" we perform the emulation of the old mountpoints (either bind mounts or symlinks)
  4. For each “Library” in your Plex DB, you add the new names but do not delete the old… YET)
  5. Update the library and observe the ‘2’ appears (showing duplicates)
  6. Now edit the Library again and remove the old location.
  7. Update again and watch the dup flag disappear
  8. Empty trash
  9. Clean Bundles
  10. Optimize DB
  11. Proceed with with the next library section at step 4 above.
13

Hi @ChuckPA

Sorry for my delayed response, I retired for the night. You are making sense, or at least you’re beginning to penetrate. Thanks for your patience!

Before I do anything, I want to be crystal clear on the current setup. I’m running OpenMediaVault, which makes setting up and managing a Debian server (in my case for Plex) much easier than starting from scratch. Which I’ve done in the past; I can’t begin to match what OMV has produced.

There are some compromises though, at least as far as how I want to manage OMV. Namely, I don’t want to make permanent changes at the Debian level which might not propagate up to OMV. Case in point was the change to the UUID for mergerfs suggested by mergerfs support. They were right, I was able to change the UUID after first creating an empty directory with the same path as the old one. This worked at the Debian level: after reboot the pool was available through the single mergerfs mount point. But unfortunately it did not propagate up to OMV, so I wasn’t able to build shares off that mount point within OMV. Instead he still showed the old, defunct mount point I couldn’t do anything with within OMV. I’m sure there are things I could have done at the Debian level to manually coerce OMV to recognize the new mount point, but that’s where I draw the line. It all becomes too fragile for me once I’ve started messing around like that. So I’m starting over with another fresh install of Jessie followed by the new OMV.

Now I’d like to understand how Plex works when resolving metadata. I guess when he sees a bunch of metadata … housed in plexmediaserver etc … he looks at the full path to each video and compares it to the full path in the metadata. If he doesn’t have an exact match, he disregards the existing metadata and builds new metadata for that video. On the other hand, if I can create a way for Plex to think the full path in the metadata still exists, he will use that metadata. Hence the symbolic link or mount point. I know the goal is to get him to apply this metadata to the new path to the video. I guess he sees 2 folders … one a fake-out symbolic link to the other … and thinks he needs to resolve metadata for each path, even though they’re actually pointing to the same video. This results in metadata information for the same video twice. So a dup appears, because he thinks he sees the same movie in 2 different locations. It’s not clear to me how he applies the old metadata on the old path to the new path, but I take you at your word. How’s that?

Okay, so with that out of the way, I need to comment on your excellent summation:

1. You installed the new OS. Correct. I also installed OMV on top of it. Then I installed mergerfs and Plex, all from the OMV GUI. When I installed Plex I pointed him to the existing plexmediaserver directory on the untouched data drive. mergerfs created an entry in the new fstab pooling the same drives as before, but with a new UUID in the mount point.

2. You have the existing Plex ‘Library’ (containing all the information Plex knows ABOUT your media) If what you mean by that is the plexmediaserver directory & subdirectories haven’t changed, and that Plex was pointed to them at install time, yes. But when Plex is started up, he apparently doesn’t know about any Libraries. I have to create them. The question then becomes what do I point to as the base path for the libraries? This is what I think you’re trying to drill into my head.
3. In order to make the transition “after the fact”" we perform the emulation of the old mountpoints (either bind mounts or symlinks).
4. For each “Library” in your Plex DB, you add the new names but do not delete the old… YET)
5. Update the library and observe the ‘2’ appears (showing duplicates)
6. Now edit the Library again and remove the old location.
7. Update again and watch the dup flag disappear

I think the simplest and cleanest way to do this, working off what may be my flawed understanding of your latest A->B suggestion, is to create a symbolic link with the full path of the old metadata. Then when creating the Library, add the new folder … the real path to the videos. Then add another folder using the symbolic link.

For example:
ln -s /media/8880fb3a-466e-4da2-b244-2a36015f041b /media/9b55d2c2-1cc9-40eb-99dd-f9a8032a0f4c
… where /media/88* is the new UUID i.e. the ‘real’ path in fstab for mergerfs and /media/9b* is the old UUID i.e. the old path referenced within the existing metadata in plexmediaserver/*

No messing with mount points or fstab. OMV won’t know about this, but Plex will, and it will only exist on Debian until all the videos have been processed by Plex. Then, after your steps 1-11 have been applied to each Library, I will unlink /media/9b55d2c2-1cc9-40eb-99dd-f9a8032a0f4c

Make sense?

Just one more thing: assuming all this works, everything I’ve altered in the metadata by hand will still exist. For example, tag lines and movie summaries which I’ve locked. Right?

14

I’m in sync with you. I don’t understand why all the layers of OMV and then a ‘mergerfs’ layer on top of that but we’ll go with what you have.

PMS doesn’t care where or how the paths actually resolve. That is its beauty.

Are you up to creating more human-readable names for your TLDs over having something like /media/9b55d2c2-1cc9-40eb-99dd-f9a8032a0f4c in PMS?

15

mergerfs isn’t really a layer over OMV; it’s a plugin you install through OMV. I think of OMV as a layer but I could argue that it’s not.

Definitely not into creating more human readable names. Because that would involve screwing around with fstab which is properly managed by OMV (with input from mergerfs). Besides, IMHO the UUID is useful in the name.

So just to be clear, my procedure of the single symbolic link computes for you? And my guesses how PMS resolves metadata?

PS: I hate swearing, but the forum censor is even stricter than I am! hah-hah!

16

Ok. Thanks for that $@##% clarification :smiley: LOLOLOL

Yes, the procedure to create a single symbolic link per old name makes 100% sense. It is a direct 1:1 relationship of new->old.

the command should be of the form ln -s new-name-1 old-name-1 where you have the new UUID mapped to the old UUID PMS is looking for

After all are done, You add the new UUIDs to PMS but do not yet remove the old. Update all the libraries and watch the dupes show up. This is expected and as it should be.

When you’ve verified all transferred, Again edit each Library’s folder list and remove the old name. When done editing, Update the entire library again. Dupes will disappear.

Now Optimize the database (under the ellipsis)

Lastly, remove the symlinks (the old names) as they are no longer needed.

17

@ChuckPA said:
Ok. Thanks for that $@##% clarification :smiley: LOLOLOL
hah-hah-hah!!!

Yes, the procedure to create a single symbolic link per old name makes 100% sense. It is a direct 1:1 relationship of new->old.

the command should be of the form ln -s new-name-1 old-name-1 where you have the new UUID mapped to the old UUID PMS is looking for

I was thinking of having a single symbolic link for the single base path. Right now, for example, there is a single base path created by the pooling logic of mergerfs in fstab:
/media/8880fb3a-466e-4da2-b244-2a36015f041b

So I’d create a single symbolic link corresponding to it:
ln -s /media/8880fb3a-466e-4da2-b244-2a36015f041b /media/9b55d2c2-1cc9-40eb-99dd-f9a8032a0f4c

Each type of Library hangs off it:

/media/8880fb3a-466e-4da2-b244-2a36015f041b/TV
/media/8880fb3a-466e-4da2-b244-2a36015f041b/Movies
...

When I create (say) the TV Library, I will point Plex to 2 folders:

/media/8880fb3a-466e-4da2-b244-2a36015f041b/TV
/media/9b55d2c2-1cc9-40eb-99dd-f9a8032a0f4c/TV

… where the first is ‘real’, the 2nd is a symbolic link pointing to the first.

I’ll do this as I create each Library.

I think you’re saying I should create a symbolic link for each Library, maybe like this:

ln -s /media/8880fb3a-466e-4da2-b244-2a36015f041b/TV /media/9b55d2c2-1cc9-40eb-99dd-f9a8032a0f4c/TV
ln -s /media/8880fb3a-466e-4da2-b244-2a36015f041b/Movies /media/9b55d2c2-1cc9-40eb-99dd-f9a8032a0f4c/Movies

Doesn’t matter which way, really, right?

18

If you can do it with a single base symlink? GO FOR IT!

19

@ChuckPA said:
If you can do it with a single base symlink? GO FOR IT!

Cool! Yeah, I can because after all that’s the point of the pooling logic, to create a single path across all those drives.

20

@ChuckPA

Just wanted to drop a note to thank your for your top notch help & patience! I’m going to hold off a little … OMV 3 is nearing general release, perhaps they will have an upgrade path rather than a fresh install path that will preserve the Plex metadata. But if that’s not coming soon, I’ll go ahead with the procedure you gave me. I’m confident that it will work out beautifully.

Thanks again!
Mark M