Plex "Empty Trash" wipes ALL library metadata with new Plex Movie agent

Plex Media Server Metadata & Adding Files
1

Server Version#: 1.20.1.3252

  1. I had a library full of movies in a folder called “Movies” matched with the old metadata agent.
  2. I wanted to move my PMS and libraries to another system, which I did following this guide: https://support.plex.tv/articles/201370363-move-an-install-to-another-system/
  3. In addition to following that article, I also alphabetized my movie files so “Movies/A” “Movies/B” and so on. And so I made some changes to the database and replaced the media_parts and section_locations with “…/Movies/A/A Wonderful Life…”. (I have done this before with great success).
  4. I restarted PMS, did a scan, emptied trash, played some files, and it all worked.

PROBLEMS STARTED AFTER THIS STEP
5) I then chose to update to the new metadata agent. I “Upgrade Matching” on my library, and then I clicked “Refresh Metadata”.
6) Once it was all done, I did another scan. Everything plays.
7) I used the trash filter to confirm there were some movies that needed Emptying. I clicked “Empty Trash” on the library and it started deleting ALL the metadata.
8) I instantly stopped Plex, and saw 50% of my library was gone.
9) I checked the trash filter and saw 0 items.

TrashNoMatch
TrashNoMatch1020×490 40 KB

10) I clicked “Empty Trash” to confirm the problem, and it started deleting all my metadata yet again.

I can post the full verbose logs needed but it’s just a lot of

Sep 07, 2020 02:03:03.890 [0x7fe90a7fc700] DEBUG - Deleting directory [Gintama (2017)] (65259)
Sep 07, 2020 02:03:03.890 [0x7fe90a7fc700] DEBUG - Deleting media item 528084.
Sep 07, 2020 02:03:03.890 [0x7fe90a7fc700] DEBUG - Was connected to metadata item 417377, count is now 0.
Sep 07, 2020 02:03:03.890 [0x7fe90a7fc700] DEBUG - Destroying metadata item 417377 (Girl)
Sep 07, 2020 02:03:03.891 [0x7fe90a7fc700] DEBUG - Deleting media item 820832.
Sep 07, 2020 02:03:03.891 [0x7fe90a7fc700] DEBUG - Was connected to metadata item 576806, count is now 1.
Sep 07, 2020 02:03:03.891 [0x7fe90a7fc700] DEBUG - Updating deletion state for metadata item 576806, is has a dead item count of 0.
Sep 07, 2020 02:03:03.891 [0x7fe90a7fc700] DEBUG - Deleting media item 820833.
Sep 07, 2020 02:03:03.891 [0x7fe90a7fc700] DEBUG - Was connected to metadata item 576806, count is now 0.
Sep 07, 2020 02:03:03.891 [0x7fe90a7fc700] DEBUG - Destroying metadata item 576806 (Girl)
Sep 07, 2020 02:03:03.892 [0x7fe90a7fc700] DEBUG - Deleting media item 820834.
Sep 07, 2020 02:03:03.892 [0x7fe90a7fc700] DEBUG - Was connected to metadata item 576807, count is now 2.
Sep 07, 2020 02:03:03.892 [0x7fe90a7fc700] DEBUG - Updating deletion state for metadata item 576807, is has a dead item count of 0.
Sep 07, 2020 02:03:03.892 [0x7fe90a7fc700] DEBUG - Deleting media item 820835.
Sep 07, 2020 02:03:03.893 [0x7fe90a7fc700] DEBUG - Was connected to metadata item 576807, count is now 1.
Sep 07, 2020 02:03:03.893 [0x7fe90a7fc700] DEBUG - Updating deletion state for metadata item 576807, is has a dead item count of 0.
Sep 07, 2020 02:03:03.893 [0x7fe90a7fc700] DEBUG - Deleting media item 820836.
Sep 07, 2020 02:03:03.893 [0x7fe90a7fc700] DEBUG - Was connected to metadata item 576807, count is now 0.
Sep 07, 2020 02:03:03.893 [0x7fe90a7fc700] DEBUG - Destroying metadata item 576807 (Girl: This Is Amazing)
Sep 07, 2020 02:03:03.894 [0x7fe90a7fc700] VERBOSE - BPQ: onLibrarySectionChanged for library section 16: ItemsDeleted
Sep 07, 2020 02:03:03.894 [0x7fe90a7fc700] VERBOSE - BPQ: onLibraryChanged callback already scheduled at 2020-09-07 02:03:03
Sep 07, 2020 02:03:03.895 [0x7fe90a7fc700] DEBUG - Deleting directory [Girl (1998)] (65260)
Sep 07, 2020 02:03:03.934 [0x7fe90a7fc700] DEBUG - Deleting media item 528088.
Sep 07, 2020 02:03:03.935 [0x7fe90a7fc700] DEBUG - Was connected to metadata item 417379, count is now 0.
Sep 07, 2020 02:03:03.935 [0x7fe90a7fc700] DEBUG - Destroying metadata item 417379 (Girl)
Sep 07, 2020 02:03:03.936 [0x7fe90a7fc700] VERBOSE - BPQ: onLibrarySectionChanged for library section 16: ItemsDeleted
Sep 07, 2020 02:03:03.936 [0x7fe90a7fc700] VERBOSE - BPQ: onLibraryChanged callback already scheduled at 2020-09-07 02:03:03

I have no idea if the new metadata agent is at fault here, but I’ve done the same restore and move before with no issues. What did I do wrong here?

What is the correct way of changing filepaths en masse so they aren’t deleted with the new agent?

2

Ugh, do you have a database backup handy?

Why in #3 did you modify the database directly instead of letting the scanner find your media? (Not saying you did anything wrong, just curious. I can think of plenty of reasons - Faster to do an update ... than a scan, etc.)

After the scan in #6 I would have been feeling comfortable too.

Why in #7(a) was there anything in the trash? Per your comments you had emptied the trash in #4.

#8 Ugh! I feel for you.

If you have a backup it would be interesting to look at some of the examples that were deleted.

I’d like to understand this for myself in the future, too.

I’ve never hacked at section_locations myself. Assuming your locations were accessible, I don’t see any immediate issues.

I’ve been curious about how media_parts.hash and media_parts.directory_id are calculated and used. I wonder if those are connected to your issue.

I believe that hash includes file size and a partial contents hash; I’m unclear if it includes anything else. Did you change the storage filesystem or network sharing protocol?

I’ve recently experienced what seems like the opposite issue. My issue doesn’t seem to be related to the new agent (it also applies to TV shows) but it did start at the same time. I had media “Emptied” during a scan, although I didn’t say “Empty Trash”.

Change in 'Trash' Behavior - unexpected library item removal - #8 by pshanew

3

Ugh, do you have a database backup handy?

Yep.

Why in #3 did you modify the database directly instead of letting the scanner find your media? (Not saying you did anything wrong, just curious. I can think of plenty of reasons - Faster to do an update ... than a scan, etc.)

Exactly, it’s just faster, and I’ve done it before so I didn’t feel the need to have my media server down for X days while it scanned.

Why in #7(a) was there anything in the trash? Per your comments you had emptied the trash in #4.

Sorry for the confusion, I had since deleted more files from the Movies folder, so there being stuff in the trash was expected behaviour. Deleting ALL of them wasn’t!

If you have a backup it would be interesting to look at some of the examples that were deleted.

Not sure how you mean. Every single thing was deleted except for a handful of files, I saw no clear pattern. There was unmatched media with locked fields where I had meticulously filled in metadata and those were deleted as well. Freshly scanned in content from Step 6 (ie. non-upgraded metadata) was also deleted along with ofc everything else that was “Upgraded”.

Unfortunately, a lot of my content has custom metadata being rare cinema and a LOT of Fix Matches which even the new Scanner is unable to find, so I can’t just start over with a new scan. I have to figure out the issue or give up on ever emptying the trash again.

Did you change the storage filesystem or network sharing protocol?

Like I said, i did change servers, but my storage was on the same NFS (sorted into alphabetical folders was the big change).

And I suspect the issue you linked with the “Trash” behaviour is related to mine, although I’m not sure how.

Here is a completely wild guess which is probably wrong. Since the new scanner is much faster, upon Emptying Trash, it checks for existing files and the NFS is unable to"keep up" thus returning that file does not exist which Plex promptly trashes. I really don’t know.

4

Thank goodness.

Different filesystems can return slightly different details even for identical files. I don’t know how media_parts.hash is calculated and I wondered if Plex saw them as different files. But that doesn’t make sense either - Plex would have seen them as new files during the scan, rather than deleting everything. So, I dunno.

I might have done something like this; maybe you can test a reduced version of it.

  1. Disabled Empty trash automatically ... and any automatic scanning.
  2. Moved things to the new system, but with old paths. Verified they worked.
  3. Moved files to new locations.
  4. Added new folders to the Library (without removing old folders)
  5. Scanned and let Plex find moved files
  6. Verified a few
    5a. Hope to see that the duplicate/hash matching has preserved the file → media and media → metadata linkage.
    5b. Panic if 5a didn’t come true, or if matching was triggered again.
  7. Removed old folders from the library

But that doesn’t really answer your question, and I’m not completely confident it’s still the right process in 1.20+.

5

Verified a few
5a. Hope to see that the duplicate/hash matching has preserved the file → media and media → metadata linkage.

The issue is that even with the metadata refresh/database replace, I am able to see the linked XML, play the file, and it doesn’t show up in trash. So the verification would similarly be useless.

It definitely has something to do with changing the file paths in database instead of letting Plex find it. And another issue, that might be related is that scanning this new alphabetized library takes 20x longer… instead of being faster, as I had hoped (this is after initial scan). I have no idea what’s gone wrong with my database nor do I know how to fix it :frowning:

6
7

Thank you for the confirmation. After this fix, will I have to refresh all metadata, or rescan? And wouldn’t a fix to recompute file hashes cause everyone’s PMS to reprocess all media?

8

No you shouldn’t have to do anything.

Only if the underlying file has changed, we then want it to recompute things like chapter thumbs, index images, etc.

9

Ah ok. So if I’m understanding this somewhat correctly:

  • PMS used to compute hashes based on the file only
  • The metadata from the new scanner/agent expected the whole file path(?) in its hash calculation (which is why it caused all my metadata to get unlinked then deleted, since I moved from “Media/Movie (Year).mkv” to “Media/[A-Z]/Movie (Year).mkv”
  • The new fix will once again use only the underlying file (which hasn’t changed, only the location), thus letting the two stay linked and not cause the database entries to get deleted upon emptying the trash.

Or something along those lines haha.

10

No :slight_smile:

The hash is computed based on the file contents, the filename is irrelevant.

The issue is we are returning blank hashes for the database item when the file doesn’t exist and during a scan of trashed items we’ll discard any duplicates based off the file hash - so you can see the problem if all the trashed files have blank hashes.

The fix is to not to try and hash files when they don’t exist (and ensure we don’t match to other files when passed a blank hash).

1 Like
11

Thanks for the explanations of how it works under the hood, too!

Plus the confirmation that it wasn’t agent-specific.

Programmer's drinking song

12

@drzoidberg33 Did the latest Plex beta include the fix for this?

The following is included in the newest Plex beta but not sure:

  • (Library) “Trashed” items could be removed if an analysis was run on them.
  • (Library) Certain file paths could result in incorrect matches for items in new Plex Movies libraries (#11925)

Are either of these fixes? I have not Emptied Trash ever since this issue wiped my library the first time around.

13

It’s fixed as far as I can tell. Duplicated my previous tests, no similar behavior. Upgraded some media, no “recently added” problems.

14

This is still NOT fixed in the any of the latest releases. Fuuck, I should have waited for confirmation. Deleted half my library yet again… I have not been able to empty trash in nearly a month now.

@drzoidberg33 In the other thread, you said a fix was already submitted and would be in the next release? Can you confirm that fix did not happen or is this a bug or a messed up database

The issue is we are returning blank hashes for the database item when the file doesn’t exist and during a scan of trashed items we’ll discard any duplicates based off the file hash - so you can see the problem if all the trashed files have blank hashes.

The fix is to not to try and hash files when they don’t exist (and ensure we don’t match to other files when passed a blank hash).

So I guess my db has all blank hashes for all my files, and since the fix is a preventative one to not try and hash non-existent files next time, I’m guessing my server is just fked right? I have scanned multiple times since then and I guess my file hashes haven’t repopulated?

15

This fix is in 1.20.2 and it wouldn’t make a difference if the hashes were blank in the database or not.

You could possibly be experiencing a completely different problem, so send me your logs and I’ll take a peek when I have a moment.

16

Do you also need my database? And I should PM you the logs? I tried to kill everything asap so as to not my whole library so not sure how helpful everything will be.

17

You could DM both the logs and the database, that would be helpful :+1:

18

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.