Replaced items show a 2nd persisting file path as "Unavailable"

Server Version#: 1.43.0.10492 (x64) which updated on 12/02
Player Version#: 4.156.0

Every so often, I replace videos in my libraries for a better version. In the past 2-3 months I have replaced many videos. I suspect this issue has been happening since the last server upgrade, since the duplicate filter is only listing files I have replaced more recently. And this count is increasing with each new batch of files I replace.

When I go to “Get Info” on these effected videos, I see 2 files listed. One being the new file, and a 2nd marked as “Unavailable” for the old deleted file.

I have my library settings with “Empty trash automatically after every scan“ enabled. I’ve also tried manually emptying the trash of this library and rescanning. I have also tried disabling “Empty trash automatically after every scan“, then rescanning and then doing a manual empty trash. I’ve now re-enabled this option as that’s my preferred option.

This issue is similar to the one described here: Removing 'Unavailable' path from Library items without removing the path itself from the library , although for linux. Subsequent server refreshes has not reduced my duplicate count.

  • Are the two versions stored in separate source folders?
    (“source folder” meaning those folders that you have added on the “Add Folders” tab in the properties of your library)
  • Have you ever performed a database repair?

Both versions are stored in the same source folder. They are in the same sub folder in some cases.

I haven’t performed a database repair.

Is anyone able to confirm if they are seeing the same behaviour on this PMS version?

Do you have “automatic library update” enabled, and are additionally starting a scan manually when adding new media files?
You must avoid starting several scans concurrently.

I have the following settings:

  • “Scan my library automatically” is disabled.
  • “Run a partial scan when changes are detected” is disabled.
  • “Scan my library periodically” is disabled.
  • “Empty trash automatically after every scan” is enabled.

After I finishing copying new files and deleting old ones (including emptying trash on the pc), I then run “Scan Library Files” manually for a specific library. I either run a scan on a single library (if I’ve updated it), or “Update Libraries” from the windows system icon tray (if I’ve updated multiple libraries).

Have you done a plex dance?

I have tried the Plex dance. Although, testing this for a single video, I haven’t moved the video back into the library folders. This is what I have done.

  • Set “Empty trash automatically after every scan” to disabled.

  • Move media files out of the library’s designated directory to make them undetectable.

  • Scan the library within Plex to register the missing items.

  • Empty the Plex trash to ensure no deleted items remain in the database.

  • At this point, the duplicate entry for this video now shows both paths as “Unavailable”.

  • Clean bundles to remove cached images and metadata from the server.

  • Repeated library scan and then another manual emptying of trash for this library.

  • Again, both paths for the video show as “Unavailable”.

I should also say, that I have this issue for files I have recently added to my Plex library, where I have then replaced them.

Can someone from the Plex team confirm if this is a known issue, and whether they are seeing the same behaviour on this PMS version?

You should definitely do it.
Stop Plex server using the Plex logo in the Windows task tray.
Then run this .bat file: https://github.com/ChuckPa/DBRepair/tree/master/Windows

If you want to read any error messages which may occur in case of problems, run the bat file within a classic command line window (CMD.exe)

Thanks, I’ll try that in the next couple of days when I can.

Presumably it’s recommended to take a backup of my database? If so, is “com.plexapp.plugins.library.db“ the database file?

Are there any other precautions I should take? And could this impact any playlists, tags or collections I have manually created?

The script is making that automatically.

That’s one of the two.

Unless there is irreparable damage in your database, there should be no such side effect.

Remember, you can always restore the backups.
(although how much sense this makes is debatable, because a DB which fails to be repaired by the script is destined to be unusable sooner or later.)

Ok thanks. I’ll report back after running the db repair.

DBRepair script has completed. After restarting PMS I’ve done another library scan and the same number of duplicates are still found. Double checking a few videos I can see the “Unavailable” path persisting. So it looks like my database is ok, but the issue still remains.

Below is the script output.

Is anyone else experiencing this issue?

C:\DBRepair-Windows>DBRepair-Windows.bat

NOTE: This script is being replaced with the PowerShell script DBRepair-Windows.ps1,
which aims to better emulate DBRepair.sh (more options, interactive mode, etc).
Consider moving over to the new script.

15:24:22.40 –  ====== Session begins. (06/04/2026) ======
15:24:22.76 – Performing DB cleanup tasks
15:24:23.35 –  Exporting Main DB
15:25:29.96 –  Exporting Blobs DB
15:30:31.20 –  Exporting Complete.
15:30:31.20 –  Creating Main DB
15:31:07.45 –  Verifying Main DB
15:31:21.59 –  Main DB verification check is: ok
15:31:21.59 –  Main DB verification successful.
15:31:21.59 –  Creating Blobs DB
15:32:11.27 –  Verifying Blobs DB
15:32:14.99 –  Blobs DB verification check is: ok
15:32:14.99 –  Blobs DB verification successful.
15:32:15.01 –  Import and verification complete.
15:32:15.01 –  Reindexing Main DB
15:32:26.31 –  Reindexing Blobs DB
15:32:32.54 –  Reindexing complete.
15:32:32.54 –  Moving current DBs to DBTMP and making new databases active
1 file(s) moved.
1 file(s) moved.
1 file(s) moved.
1 file(s) moved.
15:32:32.55 –  Database repair/rebuild/reindex completed.
15:32:32.55 –  ====== Session completed. ======

After running the repair did you empty your trash again? Are the new and old files in the same directory? Are you adding each movie folder to your library or are you just adding a “Movies” folder?

Yes, I tried emptying the trash. I am adding movies that are in their own folder and adding them to the parent folder which is the root for the library. I’ve had this library for years and replace files very frequently. But these persisting “Unavailable” paths started close to the date when my current version of PMS was updated on 12/02. My duplicate count has been increasing since then (as I replace more videos).

Maybe this isn’t a feature people use very often, but I’d be keen to know if others are experiencing this same issue. There are 2 tests people can easily replicate:

  1. Temporarily remove a video, scan the library again and empty the trash. Then check if the movie still shows. Check “Get Info” and see if the path still shows as “Unavailable”.
  2. Replace a video file with a renamed file (e.g. same name with “-1” suffix), scan the library again and empty the trash. Check “Get Info” and see there is an “Unavailable” path.

Have you tried just replacing the file with the exact same name? or using [-1] so that Plex ignores it.

This won’t work for me as part of the filename tells me where the video is from (which can change). But I tried it with using a different video and renaming exactly the same - that did work.

Suffixing with “-1” is something I have tried and why I suggested it as a test.

To be clear, the issue is that paths for the same video are showing as “Unavailable” even after rescanning the library and emptying the trash (or rescanning with the “Empty trash automatically after every scan“ option enabled). This shouldn’t be happening and subsequently causes videos to be incorrectly flagged as duplicates.

If you have time to try these 2 test cases I suggest above, please report back with your findings. I’m suspecting this is a bug, but ideally need more people to confirm if they are seeing the same behaviour.

Ok, problem solved. After reading this post..

I checked and realised I had an empty folder listed in the library paths (which I had stopped using around the same time as seeing this issue!). After removing this empty folder and rescanning, the issue disappeared. I now have the correct number of genuine duplicates.

Thanks to everyone that helped.