Video preview thumbnail generation leaves behind temp BIF files

Server Version#: 1.41.4.9399 on Windows 10 22H2 (though given the number of .tmp files, this has been happening for some time)

Going through my log files, I noticed that there were some errors around preview thumbnail generation, and digging a bit deeper confirmed that recently generated preview thumbnail files (index-sd.bif) also have an identical index-sd.bif.tmp file alongside them. Based on my logs, it’s not intermittent - every video file I add that has preview thumbnails generated is leaving behind an identical .tmp file, with the following log message:

ERROR - [BaseIndexFrameFileManager] Couldn't delete the file "P:\Plex\Plex Media Server\Media\localhost\2\18049b1f056f752b061691a39f7898874dd42a7.bundle\Contents\Indexes\index-sd.bif.tmp": The process cannot access the file because it is being used by another process

The temp folder of individual images (Indexes/tmp/img-XXXX.jpg) appears to get cleaned up, it’s just the temp BIF file itself that can’t be removed because something is still holding on to it.

Nothing in particular is sticking out in the logs - it shows the transcoder exiting successfully, and the next message indicates the temp file can’t be deleted:

[154788] DEBUG - [BaseIndexFrameFileManager] Activity: registered new activity 4a24c972-09e3-4c69-ba24-f64a324047f5 - "Generating video preview thumbnails"
[168720] DEBUG - [JobRunner] Jobs: Starting child process with pid 89316
[154788] DEBUG - [BaseIndexFrameFileManager/JobRunner] Job running: set "FFMPEG_EXTERNAL_LIBS=\\\\?\\P\:\\Plex\\Plex\ Media\ Server\\Codecs\\e613bce-97f23d579c1001d8e9cc0d2e-windows-x86_64\\" & set "X_PLEX_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" & "C:\Program Files\Plex\Plex Media Server\Plex Transcoder.exe" -codec:v h264 -skip_frame:v nokey -i "Z:\TestLibraries\TVTest\TestShow (2000)\Season 01\S01E01.mkv" -threads 0 -nostats -q 3 -loglevel quiet -filter_complex "[0:V:0] fps=fps=0.500000:round=up,scale=w=320:h=240:force_original_aspect_ratio=decrease [out]" -map [out] "P:\Plex\Plex Media Server\Media\localhost\2\18049b1f056f752b061691a39f7898874dd42a7.bundle\Contents\Indexes\tmp\img-%06d.jpg" -progressurl http://127.0.0.1:32400/video/:/transcode/session/bif/4a24c972-09e3-4c69-ba24-f64a324047f5/progress
[154788] DEBUG - [BaseIndexFrameFileManager/JobRunner] In directory: "P:\Plex\Plex Media Server\Media\localhost\2\18049b1f056f752b061691a39f7898874dd42a7.bundle\Contents\Indexes"
<snip>
[173084] DEBUG - [Req#364a/Transcode/bif/4a24c972-09e3-4c69-ba24-f64a324047f5] Activity: updated activity 4a24c972-09e3-4c69-ba24-f64a324047f5 - completed 100.0% - Generating video preview thumbnails
[181884] DEBUG - Jobs: 'C:\Program Files\Plex\Plex Media Server\Plex Transcoder.exe' exit code for process 75056 is 0 (success)
[154788] ERROR - [BaseIndexFrameFileManager] Couldn't delete the file "P:\Plex\Plex Media Server\Media\localhost\2\18049b1f056f752b061691a39f7898874dd42a7.bundle\Contents\Indexes\index-sd.bif.tmp": The process cannot access the file because it is being used by another process
[154788] DEBUG - [BaseIndexFrameFileManager] Activity: Ended activity 4a24c972-09e3-4c69-ba24-f64a324047f5.

I don’t know if this is a widespread issue, but there’s at least one other person seeing this: Video Previews Thumbnails : PleX (and it does seem like something that could easily go unnoticed by the vast majority of people).

Full logs can be provided if needed.

I too am experiencing this. I’ve not used Video Preview Thumbnails before this release so am unaware of how recent this bug is.

Can confirm that the console declares an error when attempting to delete the tmp version as it is “being used by another process”.

I’m on the latest (1.41.3.9314) windows version.

I just recently had to regenerate my preview thumbnails and after doing so Plex started generating these index-sd.bif.tmp files for me as well. After generating these thumbnails for a week there are now 36.3GB worth of these .tmp files and there are 7451 of these files in total. This is after 1 week.

Even after deleting all the preview thumbnails (again), these files were not removed. I was checking in how the thumbnail generation was coming along and noticed my ‘Media’ folder where the thumbnails are stored is now 15GB larger than it was before, even though before this I had thumbnails for every media item in my library.

Below are some stats from before I started rebuilding my thumbnails. This shows that there were 1030 index-sd.bif.tmp files in total before my rebuild and the oldest file is from 29th Oct, 2024. I started my rebuild on 21st Mar, 2025 (which is why that’s the ‘maximum’ date).

This suggests that it’s been an issue at least as far back as 29th Oct, 2024. Interestingly enough, I found a Plex update log with that same date:

Oct 29, 2024 04:05:03.117 [5448] INFO - Plex Update Service Launcher v1.41.0.8994-f2c27da23 - Microsoft PC x64-x64 - build: windows-x86_64
Oct 29, 2024 04:05:03.118 [5448] INFO - Windows version: 10.0 (Build 19045), language en-US
Oct 29, 2024 04:05:03.118 [5448] INFO - 12 3693 MHz processor(s): Architecture=9, Level=25, Revision=8448 Processor Identifier=AMD64 Family 25 Model 33 Stepping 0, AuthenticAMD
Oct 29, 2024 04:05:30.199 [22704] ERROR - Bundle Exit Code: 0 - The operation completed successfully.

The update started on Oct 29, 2024 04:05:03 and the oldest index-sd.bif.tmp file was created on Oct 29, 2024 04:18:30 (13 minutes after the update).

This log lists the old/previous version as v1.41.0.8994, which was released on 26th Sep, 2024. Unfortunately these logs don’t list the version it updates to (only the current version) and these “Update Service Launcher” logs are the only logs I have that go as far back as that.

But fret not. With the power of deduction we can figure out that there was only one update in that one-month window that could have caused this: v1.41.1.9057 (link to release notes).

The update was released to the stable channel on Oct 24, 2024 (five days before my update). Keep in mind that I only update PMS manually, so the release dates don’t always match up with when I actually update PMS.

So let’s see what changes were made to thumbnail generation in that version:

  • (Preview Thumbnails) Preview thumb generation can sometimes fail when using keyframes only (PM-1601)
  • (Preview Thumbnails) Preview thumb generation never stops retrying after failing (PM-1601)

Seems like something was indeed changed with preview thumbnail generation in that update. Of course, this is not conclusive evidence, but the details seem to match up too perfectly. Hopefully we can get some feedback from Plex regarding this issue.

I would have never stumbled across this issue if I didn’t go snooping into the thumbnails folder. I suspect this issue is a lot more wide-spread, but people simply aren’t aware that it’s an issue and that their ‘Media’ folder is getting bloated unnecessarily. This is especially killer if you decide to regenerate the thumbnails after that update (as I did).

I would urge anyone that has had their current PMS install from before 24th Oct, 2024 to check what date their oldest index-sd.bif.tmp file is from. It’s also possible you still have the Plex Update Service Launcher.log file from that time (which is where I got the logs from). On Windows, these logs can be found under %LOCALAPPDATA%\Plex Media Server\Logs. Matching up these two data points across multiple users could help us figure out if it was indeed an update that caused this.

On Windows, to check the date of your oldest index-sd.bif.tmp file, the simplest way is to download a utility called Everything by VoidTools, which indexes your whole filesystem in a couple minutes and lets you search, well… everything. Then you just enter the search term "%LOCALAPPDATA%\Plex Media Server\Media\" .bif.tmp and sort by ‘Date Modified’ or ‘Date Created’. It’s actually a great tool overall, if you decide to keep it.

Another option would be to write a small batch script, but I’m not sure whether Plex appreciates random batch commands on their forums, so I’m not going to post that here.

1 Like

Check your AV, odds are its locking the file open while it scans it for a virus, and Plex then tries to delete it and cannot.

I did look into that, but I’ve had my metadata folder excluded for quite some time now (even explicitly trying to scan the file resulted in a “file was not scanned because it’s excluded” popup). I also used procmon to monitor all file activity, and only ‘Plex Media Server.exe’ and ‘Plex Media Scanner.exe’ attempt to access either index-sd.bif or index-sd.bif.tmp. As a sanity test I also briefly removed the AV exclusion and regenerated the file, and saw that it didn’t attempt to access the file until after Plex’s last access.

I agree with @DTR that it’s very unlikely to be an AV issue. Have you confirmed that this issue doesn’t occur on your setup?

Here are the verbose logs for one such example from start to finish, in case it helps move the issue along: Hastebin

Here are the last file operations that PMS performs on the file in question from the logs:

It seems that PMS does close the file before attempting to delete it and supposedly no other process touches the file during the whole operation. The error in question comes from the bottom 3rd CreateFile event (“sharing violation”).

Here are some more details from that event, including the call stack:


I too have this exact issue! I have a large Plex Library, as in about 41,000 movies, 65,000 TV episodes - not sure that is relevant , but to give context.

My Plex media database folder is right at 2 TB in size (i do have the scrub thumbnails enabled) so I went in to investigate or expand its capacity, and i found ~4700 of these index-sd.bif.tmp files (i did sha256 vs the related index-sd.bif and they have the exact same checksum).

I’m running Windows Server 2022, version 21H2, plex is only app that runs on this machine. I also run no antivirus (win def. fully disabled), as this is a local only plex server.

I had chatGPT write me a Powershell script to make a list of all of these .tmp files so that I can see/delete them. it ended up being ~80GB of *.tmp files.

If anyone’s curious here’s the Powershell, it just makes a .txt file list of the matching files I then use notepad++ to add Remove-Item -LiteralPath " in front of each path (and close quote) then copy and paste it into a Powershell terminal.

# === CONFIGURATION ===
# $TargetFolder = "C:\Path\To\Search"     # Change this to your folder path
$TargetFolder = "B:\Plex Media Server\Media\localhost"     # Change this to your folder path
$OutputFile = "B:\PlexDeleteTMP_files_may2025\ScriptOUTPUT\tmp_files_list.txt"  # Where to save the list

# === ACTION ===
# Create or overwrite the output file
Get-ChildItem -Path $TargetFolder -Recurse -File -Filter "*.tmp" | ForEach-Object {
    $_.FullName
} | Set-Content -Path $OutputFile

Write-Host "Done. List saved to $OutputFile"

I had to check my linux PMS setup if there are any tmp files and it’s all clear here, so this is only in Windows.

Just noticed my “media” folder was getting a little too big compared to the usual and found the culprit in these multiple .bif.tmp files.

I am on Windows as well, doing a simple search I found ~6800 files for a total of 65GB, which is just too much wasted space for my liking and my main drive.

Is it possible to delete these manually?
Has there been any aknowledgement from the Plex team on this issue?

Thanks.

I’ve been running this one-liner periodically from a PowerShell prompt, which is similar to jo2jo’s script, but without the need to copy the file list to another file:

Get-ChildItem -Path "$env:localappdata\Plex Media Server\Media\localhost" -Recurse -File -Filter 'index-sd.bif.tmp' | ForEach-Object { Write-Host Removing $_.FullName; Remove-Item -LiteralPath $_.FullName }

If you moved your Plex data directory somewhere else, replace $env:localappdata with the folder that contains your ‘Plex Media Server’ folder.

All the responses I’ve seen point towards anti-virus getting in the way, like this recent reply from @drzoidberg33: Library.db size more than doubled in latest version - #124 by drzoidberg33 (sorry for another ping), but I’ve confirmed that it’s happening for me even with AV exclusions, or AV disabled completely. The fact that is seems to only be affecting index-sd.bif.tmp files (and every instance, not just a few here and there) but not other temp files that Plex creates also seems suspicious.

1 Like

Thanks for the script, I could run it as a scheduled task to keep the system clean.

My question was actually regarding how safe it is to delete these entries. But based on you answer I assume it doesn’t cause any issues with the database or anything like that.

Ah, sorry. Yes, they’re safe to delete. Even deleting the actual thumbnail file (the non-temp index-sd.bif) is technically safe in that it won’t cause any database issues, you just won’t have preview thumbnails until you reanalyze the movie/episode it’s associated with.

I discovered this on my system about a week ago:

This was the issue found for my tmp files: process cannot access the file because it is being used by another process

Plex tmp Delete.txt (1.0 MB)

Avoid running the cleanup script during the server maintenance hours,
as well as while new videos are ingested.
Simply because it is during these times that the tmp files get created and used. And you don’t want to interfere with that activity.

2 Likes

I love my preview thumbnails so I’ll be sure to keep the .bif files safe :grinning_face_with_smiling_eyes: thanks!

Good idea, I’ll be sure to space out the timing of the operations, thanks a lot!

Is there any update on why these get generated? I had 200GB if these bif.tmp files before I deleted all video thumbnails.

I slowly reenabled video thumbnails on one library and had some previews created overnight, and even on the latest version of the Plex server, I had new bif.tmp files generated today. Seems to be some sort of bug.

1 Like

I’m also having a lot of these tmp files in the Plex data folder. Can’t the butler take care of these during maintenance?

2 Likes

I too just observed this behavior after re-enabling Media Index Files. It’s leaving behind a complete copy of the .bif, which results in effectively doubling consumed storage (if left lingering).
Purging during Butler Maintenance seems like a viable workaround.
For now, I am bulk deleting via script shortly after Butler maintenance window ends to free up precious flash.

2 Likes

I suspect some thumbnail generation sub-process interferes with the clean-up logic. Perhaps the thumbnail generation process doesn’t exit properly, so when PMS attempts to clean up the .tmp file, it can’t remove it because it’s stuck open in some other PMS process. Everything seems to point towards it being a bug within PMS.