So I renamed all my media files (movies and shows) and PMS automatically started scanning the libraries (even though I have auto scan disabled). Any idea why?
Also, the “detecting intros” process kicked in again for the shows. Isn’t PMS smart enough to know the intro part of renamed files if it had done this process for the same file in the past?
Anyone?
BUMP!
@wingmanz, any comments?
How did you rename them? If you used something like Radarr/Sonarr, those tools may notify Plex that files were renamed.
Plex may also have performed a periodic scheduled scan, if you have that configured.
I see the same behavior, by the way - Plex will typically notice that a filename has changed, recognize that it’s actually the same file initially, but later perform Intro Detection and/or Video Preview Thumbnail Generation and/or Deep Analysis again.
I simply used the Linux shell to rename all of them, not Radarr/Sonarr. I do have periodic scheduled scan enabled but why doesn’t Plex recognize that it’s the same file? I’m not a Linux expert but I thought Plex keeps track of the file inodes when matching them to metadata?
If you renamed files, you WANT to do a scan so it finds the renamed files.
I don’t know all of the ways Plex detects renamed files. File size and base path? I know that if it finds a candidate renamed file it performs a partial hash check of the file to confirm.
I’m not sure if it considers inodes at all; it definitely works even with a new inode. I believe it works on network filesystems, too. Here I copied the file and then deleted the original. It detected it as the same file.
Plex Media Server.log:Oct 01, 2020 04:22:22.284 [0x80f1e0000] DEBUG - Looking for path match for [/mnt/movies.tst/Cinderella.mkv]
Plex Media Server.log:Oct 01, 2020 04:22:52.306 [0x80f1e0000] WARN - Scanner [Plex Movie]: unable to find cloud match for item file '"/mnt/movies.tst/Cinderella.mkv"'
Plex Media Server.log:Oct 01, 2020 04:22:52.307 [0x80f1e0000] DEBUG - Looking for path match for [/mnt/movies.tst/Cinderella.mkv]
Plex Media Server.log:Oct 01, 2020 04:22:52.318 [0x80f1e0000] DEBUG - We found a hash match for [/mnt/movies.tst/Cinderella.mkv] which was [/mnt/movies.tst/Cinderella (2015) - tt0103064.mkv].
Plex Media Server.log:Oct 01, 2020 04:22:52.322 [0x80f1e0000] INFO - Part rename detected [/mnt/movies.tst/Cinderella (2015) - tt0103064.mkv] was renamed [/mnt/movies.tst/Cinderella.mkv]
Plex Media Server.log:Oct 01, 2020 04:22:52.345 [0x80f1e0000] DEBUG - Updating part with ID=391176 [/mnt/movies.tst/Cinderella (2015) - tt0103064.mkv]
Plex Media Server.log:Oct 01, 2020 04:22:52.346 [0x80f1e0000] DEBUG - Turbo analysis on modified item 379256 [/mnt/movies.tst/Cinderella (2015) - tt0103064.mkv]
I believe that when the path to a file is updated, the database of media elements is modified, the “media changed” date is modified, and so the various “new media” actions, scanning, indexing, analyzing, etc., are triggered.
Right. It’s just that I was expecting a scan to be a fast one especially if they’re just renamed files.
I believe that when the path to a file is updated, the database of media elements is modified, the “media changed” date is modified, and so the various “new media” actions, scanning, indexing, analyzing, etc., are triggered.
So then everytime you rename a file, it detects it as modified and does all those new media actions? That’s not efficient at all. It’s like PMS considers new and modified files as one.
That’s only my working hypothesis, having seen some of the same behavior you’ve seen. 
I’m thrilled it recognizes them as the same files because it means matching stays perfect and library item metadata like “Date Added” stays intact.
I also agree it would be nice to skip the analysis … again.
Fair enough. At least I know it’s not an isolated case I hope some devs can explain if this behavor is by design or is some kind of bug.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
