Plex loses files sometimes (Not actually PlexCache-D fault but caused by it)

[dougie175]

I've had Plexcahce-D working well for a couple of months now but I've noticed an issue where when the files are cached sometimes (not all the time) Plex will lose sight of those episodes or just some of them, my wife is working through 5 series of a program at the moment and often she has to message me and say episodes are missing

They are obviously there and if I go onto Plex and under TV programs select Scan Library Files without doing anything else, not moving anything or changing anything they will re-appear. It just seems to be because Plex sees them as gone for a few seconds as one is made a chaced file and the other changes location to the cache drive it seems to confused Plex, This isn't on every files most of them work fine it's sporadic.

Has anyone else had this issue and what's the fix?

Thanks

[Brandon-Haney]

Thanks for the detailed write up, your description was pretty much spot on and it was enough to track this down.

It is a PlexCache bug. I have tested it and have a fix.

On Unraid, when a file exists at the same share path on both the cache pool and the array, /mnt/user/... shows the cache copy, and that is what Plex reads. PlexCache was copying media straight to its final filename on the cache drive, so Plex could briefly see an empty or half written file. If it catches one at zero bytes it drops the item from the library, and it stays gone until the next scan, which is why Scan Library Files brings them back for you.

The fix copies to a temporary filename and only renames it into place once the copy is complete, so the real filename never exists half written.

If you want it now, my fork builds to ghcr.io/brandon-haney/plexcache-d:dev. It is a development build so treat it accordingly. Otherwise it will come through here in a PR in due course.

Two other bits worth mentioning. If "Empty trash automatically after every scan" is enabled in your library settings, turning it off will take the sting out of this in the meantime, since it is what turns a brief blip into an item actually disappearing. And if it still happens after the fix, check whether your downloads and your library sit on different filesystems, because Sonarr and Radarr imports can leave Plex looking at a half written file too. Same symptom, different cause.

[dougie175]

Thanks for the detailed write up, your description was pretty much spot on and it was enough to track this down.

It is a PlexCache bug. I have tested it and have a fix.

On Unraid, when a file exists at the same share path on both the cache pool and the array, /mnt/user/... shows the cache copy, and that is what Plex reads. PlexCache was copying media straight to its final filename on the cache drive, so Plex could briefly see an empty or half written file. If it catches one at zero bytes it drops the item from the library, and it stays gone until the next scan, which is why Scan Library Files brings them back for you.

The fix copies to a temporary filename and only renames it into place once the copy is complete, so the real filename never exists half written.

If you want it now, my fork builds to ghcr.io/brandon-haney/plexcache-d:dev. It is a development build so treat it accordingly. Otherwise it will come through here in a PR in due course.

Two other bits worth mentioning. If "Empty trash automatically after every scan" is enabled in your library settings, turning it off will take the sting out of this in the meantime, since it is what turns a brief blip into an item actually disappearing. And if it still happens after the fix, check whether your downloads and your library sit on different filesystems, because Sonarr and Radarr imports can leave Plex looking at a half written file too. Same symptom, different cause.

That's great. Thanks for finding this issue and resolving it so quickly.

I'll wait for the next stable build to fix it as I'm currently away so don't want to mess it up if the dev build isn't 100% or something.

I've never had an issue with Sonarr or Radarr so don't think it'll be an issue. What you've described make perfect sense as a fix

Thank you