I was messing with my library and noticed something that didn’t make sense.
I had a TV show directory that had been fully analyzed – intros detected and chapter thumbnails generated. I then changed the path by adding the date to the directory name: /ShowName → /ShowName (1985)
Upon rescanning, I saw the Plex activity monitor blaze through thumbnail generation. It clearly did not generate new images, as it took seconds for it to finish.
However, the intro detection is starting over and taking just as long as the first time.
So, it looks like the server is smart enough to know the files have not changed, and it can reuse thumbnails… But it doesn’t know that it can reuse the intro detection data. I would expect the same kind of hash check to be used for each.
I’m FURIOUS, what if my KIDS see this FILTHY PROGRESS BAR and – oh, wait, this isn’t a big deal after all, sorry. But maybe it’s an inefficiency that would be easy to fix?
Or, if there is a good reason for this behavior… What is it? I am curious.
I read somewhere there’s supposed to be a “Cloud” thing where that info is stored. There’s even the option to try “online first” that’s enabled by default, I guess a few bugs always emerge with new features.
LOL - I’m furious about the progress bar thing too.
100% sure, I had the same thought and made sure to carefully read the activity monitor. I never saw the word “credits.”
Though if I did, it would be the same question: why did it rescan the files? Credits detection uses a shared hash database (per the article Plex shared) so it should also reprocess identical files very quickly.
I’m fairly certain this is due to the fact that markers (intros and commercials at least) are associated with the actual media file in the media_parts table in the database. When the path to the media changes, a new media_part row is created for the new path and all associated data must be recreated.
These markers are stored in media_parts.extra_data for what it’s worth.
