Drive containing media spins up when viewing details page

[nojaha 4]

Hi everyone,

I’m running into an issue where a drive spins up specifically when I access the details page of a movie (and other media for that matter).

I want to browse my library without it triggering drive spin-ups. To try and achieve this, I have configured the following:

• Disabled: "Save artwork into media folders" (for all libraries).
• Disabled: "Keep a cached copy of images in the server's metadata folder" (for all libraries)(Assuming this wasn't needed since I'm not saving images to media folders and everything is on the same machine).
• Enabled: "Download images in advance" (for all libraries).

My media drives only contain the .mkv and the .nfo files.
 

Despite these settings, certain movies trigger a drive spin-up when viewed. When this happens, I see the following in the Emby server log:

2026-03-08 19:26:30.113 Info ProviderManager: Saving image to /config/metadata/people/c/Corey Parker-tmdb-111902/folder.jpg

At the same moment, my unRAID syslog shows the drive being accessed, which is just a standard SMART read on drive spin-up:

Mar 8 19:26:30 skynetstreaming emhttpd: read SMART /dev/sdi

If Emby is saving the "People" image to the internal /config/metadata folder, why is the media drive (where the .mkv lives) being spun up? I would expect the metadata folder activity to stay on my appdata/cache SSD drive.

I've attached my full Emby server log for reference. Any insights into why these specific metadata saves are probing the storage array would be greatly appreciated!

For context, this is what I'm running:

• ASUS NUC 13 Pro (1315U)
• unRAID 7.2.4
• Emby 4.9.3.0
• Samsung 990 Pro 4TB NVME SSD for all Docker appdata, and Emby metadata
• WD Red Plus drives for all the media itself (in a QNAP TL-D800C enclosure)

embyserver.txt

[nojaha 4]

Writing this post actually got me thinking. I realized I also have "NFO" enabled under Metadata Savers.

Could it be that Emby is attempting to update the .nfo file immediately after saving a "People" image to the internal metadata folder? Even if the .nfo already references the image, perhaps the act of downloading a previously missing image triggers a file update (like a timestamp or a metadata status change).

If this is the case, could I solve this by either:

• The "Bulk Sync" approach: If I run a manual library refresh using the "Search for missing metadata" mode, will this effectively find all missing images and update the .nfo files in one go? My hope is to get the "writing" out of the way all at once so that daily browsing remains read-only.
• The "Manual Toggle" approach: Would it be better to keep the NFO Metadata Saver disabled for daily use, and then only enable it once a month (or after adding new media) to run a "Search for missing metadata" scan? This would keep the drives spun down while browsing, while still giving me the .nfo backups I want.

Does anyone else with a "spun-down" array use a similar workflow, or is there a setting I’m missing that prevents these incidental .nfo writes during browsing?

[Luke 42143]

HI, if you can enable debug server logging temporarily and repeat the test, then that might help us isolate this.

Also in nfo plugin settings, if you disable the option to save image paths in nfo files, then that might help reduce some disk access.