Deleted track still displays in Plex

Hi All,
( 1.25.2.5319 on Synology NAS). I have a track that is listed in Plex, but the file does no longer exists on the file system.

I’ve rescanned my library and plex still thinks it is there. I’ve tried to click “delete” from the web app. When I click delete I get the error message “There was a problem deleting this file”.

Any ideas how to get this ghost out of my system? LOL

Thanks in advance.

Pull up the Media Info for the track. It will show the location of the file.

Hi FordGuy61. Thanks for the reply. I have done this. Next to the filename is red text that says “unavailable”. This is because the file does not exist. If I click the “Delete Files” link, I get the error that “There is a problem deleting the file”.

Usually, rescanning will clean up things like this, but for some weird reason, this entry won’t go away.

@Rooley
Red text sounds like items in the library trash. Have you tried to empty the trash?
Scan the library again, then click on the three dots and chose “Manage library>empty trash.” Maybe “automatic emptying of the trash after every scan” under “Settings>[Settings]>Library” does not work correctly.

Hope this helps! :slight_smile:

1 Like

Hi Fluamsler. Never noticed that option. Sounded really promising. Just tried. But same result.

I’ve tried a couple of other things…

  • I’ve added a file with the same name and tried to delete it with the Plex ui. Same error.
  • I added the file, edited the tags to match what is in plex. Did a rescan. UI now shows the file is available (no red text). Then renamed the folder and did another rescan. This creates a brand new entry in plex. LOL. This one I can delete. But the old entry remains with plex thinking it is in the original folder (which now also does not exist).

I guess I’m stuck with this weird kink in my otherwise happy plex experience. :wink:

Thanks for your help. If you have any other ideas, fire away.

The solution to empty the trash for that particular library should be the „right way“ to do this.

Are you seeing any immediate error messages in your server logs when you trigger that and it’s no not working properly for you?
I take it that wasn’t the last file left in an otherwise empty top-level folder?

Hi Tom,

Here are the log entries when I performed the original empty trash function… (no errors)
Jan 18, 2022 10:16:19.158 [0x70d2dd48] DEBUG - Request: [10.0.0.21:10903 (Subnet)] OPTIONS /library/sections/1/emptyTrash (5 live) TLS GZIP Signed-in Token ()
Jan 18, 2022 10:16:19.158 [0x71f5ad48] DEBUG - Completed: [10.0.0.21:10903] 200 OPTIONS /library/sections/1/emptyTrash (5 live) TLS GZIP 0ms 376 bytes (pipelined: 14)
Jan 18, 2022 10:16:19.163 [0x70d2dd48] DEBUG - Request: [10.0.0.21:10903 (Subnet)] PUT /library/sections/1/emptyTrash (5 live) TLS GZIP Signed-in Token (removed)
Jan 18, 2022 10:16:19.221 [0x70d2dd48] DEBUG - About to destroy 0 deleted items.
Jan 18, 2022 10:16:19.243 [0x70d2dd48] DEBUG - About to destroy 0 deleted directories.
Jan 18, 2022 10:16:19.244 [0x71f5ad48] DEBUG - Completed: [10.0.0.21:10903] 200 PUT /library/sections/1/emptyTrash (5 live) TLS GZIP 81ms 320 bytes (pipelined: 15)

Here are the log entries for the attempted delete of the file. The server is throwing an exception…
Jan 18, 2022 11:41:17.298 [0x70b68d48] DEBUG - Deleting media item 9876.
Jan 18, 2022 11:41:17.302 [0x70b68d48] DEBUG - Was connected to metadata item 12689, count is now 0.
Jan 18, 2022 11:41:17.304 [0x70b68d48] DEBUG - Destroying metadata item 12689 ()
Jan 18, 2022 11:41:17.339 [0x70b68d48] ERROR - Exception inside transaction (inside=1) (…/Library/MetadataItem.cpp:906): Null value fetched and no indicator defined.
Jan 18, 2022 11:41:17.339 [0x70b68d48] ERROR - Exception inside transaction (inside=1) (…/Library/MediaItem.cpp:813): Null value fetched and no indicator defined.
Jan 18, 2022 11:41:17.347 [0x70b68d48] ERROR - Soci Exception handled: Null value fetched and no indicator defined.
Jan 18, 2022 11:41:17.348 [0x71f5ad48] DEBUG - Completed: [10.0.0.21:13346] 500 DELETE /library/metadata/12689 (6 live) TLS GZIP 119ms 530 bytes (pipelined: 3)

Retrying the emptytrash… (no errors)
Jan 18, 2022 11:54:54.548 [0x70636d48] DEBUG - Request: [10.0.0.21:13592 (Subnet)] PUT /library/sections/1/emptyTrash (6 live) TLS GZIP Signed-in Token (removed)
Jan 18, 2022 11:54:54.575 [0x70636d48] DEBUG - About to destroy 0 deleted items.
Jan 18, 2022 11:54:54.605 [0x70636d48] DEBUG - About to destroy 0 deleted directories.
Jan 18, 2022 11:54:54.608 [0x71f5ad48] DEBUG - Completed: [10.0.0.21:13592] 200 PUT /library/sections/1/emptyTrash (6 live) TLS GZIP 60ms 320 bytes (pipelined: 5)

This was the only file in the subfolder. The folder is empty. It was originally mislabeled as unknown artist/unknown album due to a bad rip. I manually deleted it after correcting the IDTags. The new version of the file is also in my system, but in a different folder.

Thanks for your help.

Those log snippets aren’t telling much of a story.
Can you temporarily remove the corrected file as well and do a full Plex Dance (following all the steps of the procedure)?

I did the plex dance. The Clean Bundles step (never done that before) took a bit of time, but after viewing the logs, the only error was during the scan. It is essentially the same error as the one I got when I tried to delete the entry. So it looks like the scan is trying to delete a file that doesn’t exist.

Jan 18, 2022 13:06:04.136 [0x704e2d48] Debug — Activity: updated activity 4202a8a6-50a0-40b2-83ee-b40db4ae33b5 - completed 99.0% - Scanning Music
Jan 18, 2022 13:06:04.137 [0x704e2d48] Debug — Activity: updated activity 4202a8a6-50a0-40b2-83ee-b40db4ae33b5 - completed 99.0% - Scanning Music
Jan 18, 2022 13:06:04.137 [0x704e2d48] Debug — Scanner [Plex Music]: Idle and left with 5066 media items.
Jan 18, 2022 13:06:04.142 [0x704e2d48] Debug — Removing 1 media items that were left.
Jan 18, 2022 13:06:04.142 [0x704e2d48] Debug — Deleting media item 9876.
Jan 18, 2022 13:06:04.155 [0x704e2d48] Debug — Was connected to metadata item 12689, count is now 0.
Jan 18, 2022 13:06:04.156 [0x704e2d48] Debug — Destroying metadata item 12689 ()
Jan 18, 2022 13:06:04.157 [0x704e2d48] Error — Exception inside transaction (inside=1) (…/Library/MetadataItem.cpp:906): Null value fetched and no indicator defined.

Jan 18, 2022 13:06:04.157 [0x704e2d48] Error — Exception inside transaction (inside=1) (…/Library/MediaItem.cpp:813): Null value fetched and no indicator defined.

Jan 18, 2022 13:06:04.157 [0x704e2d48] Warning — Caught exception while scanning Music: Null value fetched and no indicator defined.
Jan 18, 2022 13:06:04.157 [0x704e2d48] Debug — Activity: updated activity 4202a8a6-50a0-40b2-83ee-b40db4ae33b5 - completed 100.0% - Scanning Music
Jan 18, 2022 13:06:04.159 [0x704e2d48] Debug — Refreshing section 1 of type: 8
Jan 18, 2022 13:06:04.741 [0x70289d48] Debug — Refreshing 0 IDs.
Jan 18, 2022 13:06:04.794 [0x704e2d48] Debug — Activity: registered new activity f6619e98-9b38-4f52-8e41-0a78f94bd423 - “Processing subscriptions”
Jan 18, 2022 13:06:04.797 [0x70b68d48] Debug — Grabber: Cleaning up orphaned grabs.
Jan 18, 2022 13:06:04.798 [0x704e2d48] Debug — Activity: Ended activity 4202a8a6-50a0-40b2-83ee-b40db4ae33b5.
Jan 18, 2022 13:06:04.799 [0x70b68d48] Error — Couldn’t check for the existence of file “/volume1/video/Home Video/.grab”: boost::filesystem::status: Permission denied: “/volume1/video/Home Video/.grab”
Jan 18, 2022 13:21:29.537 [0x71f37d48] Debug — Completed: [10.0.0.21:14188] 200 GET /player/proxy/poll?deviceClass=pc&protocolVersion=3&protocolCapabilities=timeline%2Cplayback%2Cnavigation%2Cmirror%2Cplayqueues&timeout=1 (6 live) TLS GZIP 20001ms 5 bytes (pipelined: 152)
Jan 18, 2022 13:21:29.547 [0x70505d48] Debug — Request: [10.0.0.21:14188 (Subnet)] GET /player/proxy/poll?deviceClass=pc&protocolVersion=3&protocolCapabilities=timeline%2Cplayback%2Cnavigation%2Cmirror%2Cplayqueues&timeout=1 (6 live) TLS GZIP Signed-in Token (removed)
Jan 18, 2022 13:21:29.548 [0x70505d48] Debug — Content-Length is -1 (of total: -1).
Jan 18, 2022 13:21:32.462 [0x71f37d48] Debug — Completed: [10.0.0.21:14619] 200 GET /player/proxy/poll?deviceClass=pc&protocolVersion=3&protocolCapabilities=timeline%2Cplayback%2Cnavigation%2Cmirror%2Cplayqueues&timeout=1 (6 live) TLS GZIP 20001ms 5 bytes (pipelined: 111)
Jan 18, 2022 13:21:32.491 [0x70505d48] Debug — Request: [10.0.0.21:14619 (Subnet)] GET /player/proxy/poll?deviceClass=pc&protocolVersion=3&protocolCapabilities=timeline%2Cplayback%2Cnavigation%2Cmirror%2Cplayqueues&timeout=1 (6 live) TLS GZIP Signed-in Token (removed)
Jan 18, 2022 13:21:32.491 [0x70505d48] Debug — Content-Length is -1 (of total: -1).

Do you know if you can open the database and see the contents of the rows?

If the folder still exists and is empty, try deleting it.

Also, maybe a permissions issue? Set the permissions in File Station, even if it shows that user Plex (DSM 6) or PlexMediaServer (DSM7) has permission.

  1. In File Station, right click on the folder you added to the library. Choose Properties. Click on the Permissions. Verify Plex/PlexMediaServer has the correct permissions.
  2. Check the box for “Apply to this folder…”
  3. Click Save. DSM will then set permissions for everything in that folder.

When DSM is finished, re-scan the library in Plex Media Server.

Yep. I deleted the folder and did a rescan and plex thinks that file is still there in a folder that doesn’t exist. LOL.

I think the problem is in the database, and not in the filesystem.

Here’s why I think this…

Test 1
Since the file was not there, I created it. I then used the plex ui to delete it. I got the same error.
Looking in File Station, I can see that the file is indeed deleted. But, in plex it thinks the file is still there. So deleting the row from the database is likely the problem and that appears to be happening after the file is removed from the file system.

Test 2
I put a 2nd file in that same folder and rescanned so that Plex found it. I went into plex and deleted it. No errors. The file is removed and no trace of it in Plex. This is the happy path, IMO. Both the entry and the file are removed in an autonomous action.

Test 3
I put a 3rd file in that same folder and rescanned so that Plex found it. I went to File Station and deleted it. Without rescanning, in Plex, I clicked delete. The entry in plex disappeared without complaint. So in this case, Plex forgave me for not having the actual file. It just deleted the metadata. So the only difference between this and Test 1 is the actual row in the database did not get deleted. This one was successful but the first one failed.

I think I have a corrupt row in my database. I would love to open it up and manually remove the entry. I think I read somewhere that it is a mysql database.

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