Server Version#: 1.23.6.4881
Player Version#: N/A (4.59.2, Web)
I migrated my Plex Installation yesterday, and followed the instructions in Move an Install to Another System. I am running Plex on Ubuntu 20.04.2 LTS.
Everything starts up fine, but after adding the path to where the media now sits Plex scans the paths (as is to be expected) and for some reason comes up with 51 “new” movies. These movies are already in my library but seem to now have a different match (they have different dates, posters, descriptions and other metadata).
Now, the issue is that I have custom posters, collections and other configurations and I’m not a big fan of having redo all work for these 51 titles. Also, naturally they have appeared in Recently Added Movies which is messing things up even more since they are not recently added.
My theory is that these 51 films have somehow received incorrect matchings on my previous install and now they are matched “correctly”. I read this thread about issues matching with TMDB which might be have something to do with it, but I don’t know how I can verify which source (IMDB, TMDB etc.) an object has been matched with.
Does anyone know why this happens and how I can prevent it? I am more than happy to retry my migration if it helps. I can also provide logs if necessary.
If not, is there anyway I can do to “merge” the 51 duplicates back into their original objects without losing customizations and cover art etc.?
Sorry for long post, have been up all night trying to solve this issue.
You probably had some of these movies matched to an older/different metadata agent.
Now, if you change the folder of your library and perform a library scan, all those movies get recoghnized anew and are matched with the current default agent.
The only two possible options known to me are:
on the old server, change the library’s metadata agent to “Plex Movie” and perform “Refresh all metadata” for the whole library. Only after this is finished, transfer the library to the new machine.
Thanks for your quick response @OttoKerner, really appreciate you helping me out!
I was thinking your first suggestion might be an option, and it’s probably the “cleanest” solution too since it will mean that my “incorrect matches” get corrected. It’s really great that you provided me a work-around also. I will have to think about this.
I presume that if I chose the second option, the risk is that I might have to do this again every time I migrate (which is not that often, but still)?
It would be great if there was a way to merge two objects in Plex, but then again, I seem to be the only one to have this issue so there are probably bigger issues to battle.
Hang on, couldn’t I possibly do option B and then go with option A on the new server? That is, hacking the database, and once that’s done I fix the matching? Wouldn’t that resolve my issue, or am have I misunderstood something here?
No, you can pick whichever strategy suits you best on subsequent moves.
Sorry, I dont see what use a direct database edit could have on the old server.
(Unless you are still in the woes of a previous library merge or something.)
No, I meant editing the database on the new server. I edit the paths like you suggested so that I don’t get the faulty new objects, after that’s done I change the library metadata to Plex Movie (still on the new server).
My understanding is that if I only edit the database on the new server and keep it running, then I will have to do this again the next time I migrate. Am I wrong?
Theoretically, it’s not even necessary to do that. (it is of course recommended to do so, since the old agents won’t get any support and updates anymore.)
Theoretically not, because of -see above-
If you however change the agent to Plex Movie now, you will have fewer issues on subsequent server moves.
(“Unmatchable” items excluded, which will pretty much always require a direct database edit if you don’t want to lose manual metadata edits.)
I just want to report that the issue was resolved with the suggested solution (editing the database according to the instructions in the linked post). Big thanks to @OttoKerner, and also kudos to @jelwell!
