Hello,
i have a question. I need to change location of serie’s directory.
How can i conserve intros without having to detect again ?
if i add a location with the same files i suppose plex will add a file for each episode and then if i delete the old location will the intros be kept ?
thanks for reply :d
I will ask this in tomorrow’s server meeting.
If they are using standard handling,
Thanks you i will did it :d
I am also interested in this. I posted some time ago about it:
For backup purposes I want to move my TV Shows from the folder where they are now TV Shows (a root directory) to another directory in the same HDD disk1\TV Shows. Actually just a rename operation with WinSCP. Much faster than copying the files.
The problem is that the intro detection kicks again. I have many shows with many seasons and episodes and would like to avoid the intro detection again. The XML has already the intro markers and the files are the same, something Plex already finds out when scanning the library: Part rename detected.
Any way to avoid the intro detection on files that already have the intro markers?
Curiously enough, I have replaced some of my h264 TV episodes with newer h265 versions , where with the same quality, the files are smaller and then, rescanning the library, refreshing metadata and/or analyzing the TV Show, the intro detection is skipped.
Thanks!
If you changed any facet of the quality, and it didn’t reanalyze the file (It still thinks it’s H.264) then that’s a bug. It’s supposed to minimally scan the header of the file and update the database as to the file contents.
As for ‘move’ / ‘rename’ / ‘copy’.
mv a.ext b.ext is a pure rename within the confines of that directory.
Only the name field changes.
mv a.ext /path/dir is a move.
– In this case, the inode information is “moved” from the current directory to the new target directory retaining all the flags and permissions without alteration. The only thing which does change is the target directory’s DateLastModified…
– If the file is renamed in the process, renaming occurs in the destination location after the inode is relocated
mv /volume1/A/b.ext /volume2/B/
– This is a transparent copy operation. A new inode is generated in the process.
– After the b.ext is copied, if the flags are set to preserve (-p), which is the default, then date/time/owner/permissions are replicated.
– Lastly, the original file is deleted.
Given the potential for inode changes in addition to path changes, knowing PMS is keen on ‘ParentID’ fields in the database,
I will keep everyone informed.
IF someone from the Engineering team (a full time employee) responds, I will remain silent unless needed.
Thanks!
The thing is that changing the quality/encoding, and analyzing the media, the info in Plex is updated and reflects the new quality/encoding. In the Web app and in the ATV app. But in this case, the spinner showing Detecting intros for Season XXX spins very shortly and bails out. Even though the file is obviously not the same. But the intro markers are preserved.
When moving from TV Shows to disk1\TV Shows and rescanning the TV Shows library, I can see in the logs Part rename detected, so Plex knows it’s the same file, whose XML already has the intro markers.
Any way, no biggie 
I know you guys have a lot of thing in your hands.
Thanks again!
I asked in today’s meeting.
At present,
When anything about the media item changes (like a new path), it’s going to rerun the detection. ( It wasn’t written to be smart about that )
The team agrees it should be smart enough to track the item by its ID/Hash code in the DB just as metadata does.
At their suggestion, this has been written up as a Feature Request and accepted.
I don’t know which release cycle the work will be done in but it will be done.
For now, the workaround is to manually edit the DB (carefully).
Slightly off topic, but slightly related…
Hey, uh, interesting tidbit I found out last night, is that it will not re-run intro detection if the file names are edited.
I had to Plex dance the two episodes to fix, which now put the entire show season at the start of my “recently added”.
I need evidence of this please because it goes against what the developing Engineer (the author) told me.
Something realized is not as it’s perceived/spec’d to work.
ok so i did like first answer. I add new location and wait for detect and plex skip detection.
When finished, i delete old location and everything is fine !!!
Thanks you a lot
problem is now solved for me :d
Whad’ya need, I’ll provide it.
Here’s steps I did:
Activity icon showed no more work being performed on the files it scanned)I can reproduce this is you want log files of the event, just let me know. Also, if this should be spun off into its own post, that’s fine.
So to recap.
This behavior isn’t a bug.
I suspect your media was ‘acquired’ and not “DVD / BluRay ripped perfectly” at equal bit rates.
The length of intros (number of bytes required) will be different.
PMS needed the full “Dance” to reset and start over.
To me, that’s a nice clean way of resolving – UNLESS you feel PMS should have detected the rename and re-run intro/credit detection?
(This thread is about conserving but a “Plex Dance” destroys that)
I was hoping that Plex would recognize that the file changed. Due to it being a different file than it was previously, I expected that Plex can no longer trust that the intro markers are correct for each file since the base file itself changed. Usually, Plex will at least do chapter and scan thumbnail work on a changed file, but doesn’t do intro/credit marker checking. If Plex suspects the file changed enough that the scan thumbnail images are incorrect, then the credits ought to be as well.
For this OP’s problem, I would “expect” that Plex detects the exact same file (duration, hash, etc) at a new library source location. Comparing that against an existing “known” source, I’d expect Plex to intuit that perhaps a file move is done, so no extra work needs be done on an identical file. So I’m glad to hear that this is a worked-on feature with no guaranteed ETA (I am patient, as long as it is being worked on).
Yeah, I resolved my issue by a dance, which will destroy all existing metadata/analysis about the file that Plex generates. I was hoping though that an in-place file replacement ought to trigger some analysis data to be thrown out and re-ran since it is a new file.
If Plex can selectively do certain first-run analysis like credit detection without running the entire new-file process, then I’d like that functionality to be exposed to server owners as well. My problem could have easily been solved if there was a “throw away intro markers and scan again” button available to me.
I am again sorry for dragging this off-topic. My issue is completely unrelated to the OP’s issue, but is related to where you asked in the meeting. If we are going to get analysis to be ran on an ID/Hash change, that would work great for me, as well as the OP.
As for this – “Same File → New Location”, YES, I agree that should work.
After talking with the engineer in our meeting, I wrote it up as a feature request improvement to how it currently works.
He agreed it can be done better.
Now we only need give him time to implement.
Right. I re-examined my post after posting and (as I frequently do) found areas where I could soften my word phrasing. There is now an edit where I am glad to hear that my “desire” in my quote is being worked on.
Anyway, I appreciate the work you do here. I’ll keep an eye out in the “new” features in upcoming server notes.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
