I would really like to be able to Plex for viewing Photos Albums, but I have recently been struggling with getting Plex to cooperate with my organization strategies.
I have about 160,000 photos—trying to organize them in Plex is not an option; I use a proper photo manager that can efficiently handle that volume. I have a folder for photos that I’d like to have in Plex with subfolders by collection that are populated with links to the photos’ permanent location elsewhere.
This works perfectly except for one thing. My collections are not mutually exclusive—the same picture may be included in multiple folders. The simplest example being that I might have a collection of trip photos and then a “Best of” collection of those trip photos that is a subset of the full collection. The “Best of”'s were not appearing in Plex, although I could see the scanner adding the files and then immediately deleting them. Looking into the logs, it’s pretty clear that Plex is checking for duplicate images and removing them:
Oct 19, 2017 16:41:22.279 [0x7fdd84ff8700] DEBUG - * Scanning JKA_C_3193
Oct 19, 2017 16:41:22.279 [0x7fdd84ff8700] DEBUG - Looking for path match for [/path/to/JKA_C_3193.JPG]
Oct 19, 2017 16:41:22.280 [0x7fdd84ff8700] DEBUG - Checking by hash to see if we can find a match with 358b5323dbb3c243370af4d8af00e015b763ba45 (display offset: 0, not part -1)
Oct 19, 2017 16:41:22.280 [0x7fdd84ff8700] DEBUG - We found a hash match for [/path/to/JKA_C_3193.JPG]
Oct 19, 2017 16:41:22.281 [0x7fdd84ff8700] INFO - Part rename detected [path/to/JKA_C_3193.JPG] which was [/other/path/to/JKA_C3193.JPG]
Oct 19, 2017 16:41:22.303 [0x7fdd84ff8700] DEBUG - Added new metadata item (JKA_C_3193) with ID 942858
Oct 19, 2017 16:41:22.311 [0x7fdd84ff8700] DEBUG - Doing expensive tags write for 'JKA_C_3193' because something changed.
Oct 19, 2017 16:41:22.316 [0x7fdd84ff8700] DEBUG - Doing expensive tags write for 'JKA_C_3193' because something changed.
Oct 19, 2017 16:41:22.320 [0x7fdd84ff8700] DEBUG - Doing expensive tags write for 'JKA_C_3193' because something changed.
Oct 19, 2017 16:41:22.325 [0x7fdd84ff8700] DEBUG - Doing expensive tags write for 'JKA_C_3193' because something changed.
Oct 19, 2017 16:41:22.330 [0x7fdd84ff8700] DEBUG - Doing expensive tags write for 'JKA_C_3193' because something changed.
Oct 19, 2017 16:41:22.335 [0x7fdd84ff8700] DEBUG - Doing expensive tags write for 'JKA_C_3193' because something changed.
Oct 19, 2017 16:41:22.340 [0x7fdd84ff8700] DEBUG - Deleting media item 1028987.
Oct 19, 2017 16:41:22.340 [0x7fdd84ff8700] DEBUG - Was connected to metadata item 942631, count is now 0.
Oct 19, 2017 16:41:22.341 [0x7fdd84ff8700] DEBUG - Destroying metadata item 942631 (JKA_C_3193)
Oct 19, 2017 16:41:22.346 [0x7fdd84ff8700] DEBUG - Updating deletion state for metadata item 525227, is has a dead item count of 0.
I understand the intention here: to detect name changes and file moves gracefully and not lose any database metadata associated with the renamed/moved file. However, the detection algorithm is missing the step of checking if the original file(s) still exist. I would consider this a bug. Even if the intention was to capture duplicate files, which I don’t think it is, the behaviour is problematic because every time the Library is scanned, it recreates the duplicate items and then re-deletes them. It fundamentally assumes there will be no duplicates in the Library and Plex should be accounting for the possibility that they are there intentional or not.
