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 42308]

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.

[nojaha 4]

Hi Luke,

Apologies for the late reply, as I didn't have access to the server.

I've attached the server log with debug logging enabled, and this time the spin up happened at 17:59:16 in unRAID. In the log I would guess you'd need to look at 17:59:16.109 when it starts fetching the movie that I clicked on, but I could be mistaken.

Please let me know if there's anything else I can provide

embyserver_with_debug_logging.txt

[Luke 42308]

It's hard to say. I don't see anything obvious. What are the contents of the movie folder?

[nojaha 4]

Just the .mkv file itself, and the related .nfo file. The weird thing is, is that I went through all the libraries and refreshed the metadata with a "Search for missing metadata" scan. But apparently it still seems to want to get the latest metadata online. Or they may actually be newer metadata out there, since I updated a week or so ago.

If I disable the "Metadata Savers" for NFO then it naturally doesn't happen anymore. Would be great if I didn't have to disable it, but the solution for now seems to be to disable it, and then enable it for the library that I'm adding media to before adding and scanning.

[Luke 42308]

Quote

The weird thing is, is that I went through all the libraries and refreshed the metadata with a "Search for missing metadata" scan. But apparently it still seems to want to get the latest metadata online.

Well that's what refresh metadata does. If you don't want any internet metadata then use the library options to disable it.

[Luke 42308]

Quote

If I disable the "Metadata Savers" for NFO then it naturally doesn't happen anymore.

this is not true. whether you enable nfo saving or not has no bearing on whether refreshing metadata will use the internet.

[nojaha 4]

No, sorry, I meant that when I disable the NFO saving, it stops the drives from spinning up. It of course still refreshes the metadata.

[nojaha 4]

I was just hoping that if the NFO file already had the latest metadata, and that there technically weren't any new metadata online, then it wouldn't try and fetch it again, thereby trying to save the new metadata to the NFO file as well, resulting in the drive spinning up.

I guess I wasn't aware of it always pulling the latest metadata whenever you visit a details page.

[Luke 42308]

Quote

and that there technically weren't any new metadata online, then it wouldn't try and fetch it again

How would it know until it fetches it?

[Luke 42308]

10 minutes ago, nojaha said:

I guess I wasn't aware of it always pulling the latest metadata whenever you visit a details page.

No, this isn't true. Whatever is spinning up the drives is something else.

[nojaha 4]

15 minutes ago, Luke said:

How would it know until it fetches it?

Again, sorry I'm not being very clear. What I specifically meant was, fetches it / checks for newer metadata, but doesn't necessarily save it if the metadata isn't newer.
 

16 minutes ago, Luke said:

No, this isn't true. Whatever is spinning up the drives is something else.

You're probably right, as it doesn't seem to happen consistently with every details page  I just wish I knew what it was. The only thing happening in the log when it does spin up a drive is the saving of the metdata. All I can say is, that if I disable the NFO saving, it doesn't happen anymore.

[Luke 42308]

Quote

All I can say is, that if I disable the NFO saving, it doesn't happen anymore.

I think that is coincidental because in your provided log example, no nfo files were written during that time.

[Luke 42308]

what are the contents of the 40 days and 40 nights folder?

[nojaha 4]

Sorry for the late reply, I hadn't noticed your response

The only contents of the "40 Days and 40 Nights" folder is the .mkv file, and the related .nfo file. Nothing else.

• "40 Days and 40 Nights (2002).mkv"
• "40 Days and 40 Nights (2002).nfo"

As you mentioned, this is likely just coincidental as nothing indicates writing to the NFO file in the logs. I'm happy to mark my workaround as the solution for now, if this is seemingly a dead end?

Edited March 29 by nojaha
Formatting, and a bit extra information.

[Luke 42308]

I think if you can produce another couple examples then it might be easier to identify the common thread. Thanks.

[nojaha 4]

Apologies for the late reply, as I haven't had access to the server for a couple of weeks.

After some more testing I'm back with some more information, and I can now say that disabling the saving to NFO files doesn't fix this. As you correctly suggested. I've attached another server log, with debugging enabled of course, but not really that much new in it, unfortunately. However, I noticed that the spin up seems to happen right around when chapter images are queried. Not that they necessarily are related, just that I noticed this is where it hangs while waiting for the disk to spin up, as you can tell by the time. And for context, the movie that triggered the drive spin up in this log, is "Ice Age - Continental Drift (2012)" around 18:17:28, and it also only has the two files, the .mkv and the .nfo.

2026-04-15 18:17:37.755 Debug ImageService-0HNKNOMEABN1D:00000024: http/1.1 Response 200 to host2. Time: 9479ms. GET http://192.168.0.245:8096/emby/Items/12317/Images/Chapter/0?maxWidth=972&tag=cf47c124579c3b18e6bd388dbc9880b1&mediaSourceId=mediasource_12317&quality=90. 
2026-04-15 18:17:37.755 Debug ImageService-0HNKNOMEABN1G:00000023: http/1.1 Response 200 to host2. Time: 9479ms. GET http://192.168.0.245:8096/emby/Items/12317/Images/Chapter/1?maxWidth=972&tag=cf47c124579c3b18e6bd388dbc9880b1&mediaSourceId=mediasource_12317&quality=90. 

This however led me to try and monitor disks for access to get a better understanding of what is happening. So I setup "inotifywait" with watchers for all the disks in the array, and more specifically the "movie" share. And surprisingly it actually seems to always access the folder containing the movie whenever the details page is accessed. Whether that is due to trying to query the chapter images, just verifying that the files still exists, or something else, I'm not sure. Here's an example of the output from the "inotifywait" watchers when accessing a random movie:

18:59:41 /mnt/disk1/movies/The Green Mile (1999) OPEN,ISDIR
18:59:41 /mnt/disk1/movies/The Green Mile (1999)/ OPEN,ISDIR
18:59:41 /mnt/disk1/movies/The Green Mile (1999) ACCESS,ISDIR
18:59:41 /mnt/disk1/movies/The Green Mile (1999)/ ACCESS,ISDIR
18:59:41 /mnt/disk1/movies/The Green Mile (1999) ACCESS,ISDIR
18:59:41 /mnt/disk1/movies/The Green Mile (1999)/ ACCESS,ISDIR
18:59:41 /mnt/disk1/movies/The Green Mile (1999) CLOSE_NOWRITE,CLOSE,ISDIR
18:59:41 /mnt/disk1/movies/The Green Mile (1999)/ CLOSE_NOWRITE,CLOSE,ISDIR
18:59:41 /mnt/disk1/movies/The Green Mile (1999) OPEN,ISDIR
18:59:41 /mnt/disk1/movies/The Green Mile (1999)/ OPEN,ISDIR
18:59:41 /mnt/disk1/movies/The Green Mile (1999) ACCESS,ISDIR
18:59:41 /mnt/disk1/movies/The Green Mile (1999)/ ACCESS,ISDIR
18:59:41 /mnt/disk1/movies/The Green Mile (1999) ACCESS,ISDIR
18:59:41 /mnt/disk1/movies/The Green Mile (1999)/ ACCESS,ISDIR
18:59:41 /mnt/disk1/movies/The Green Mile (1999) CLOSE_NOWRITE,CLOSE,ISDIR
18:59:41 /mnt/disk1/movies/The Green Mile (1999)/ CLOSE_NOWRITE,CLOSE,ISDIR

Any idea as to what might be causing it to access the folder containing the media whenever you view the details page?

The surprising bit here, is that after I had setup the watchers I could no longer reproduce the issue for the movie library. And the answer to why that is, is that "inotifywait" of course needs to traverse all the directories to setup the watchers, and in doing so the directories are added to the RAM cache (VFS). So, it appears that the reason for the spin up is that the directory of the movie, which details page I was accessing, wasn't cached to the RAM. At least that is my theory, since I haven't been able to reproduce it since. I've now manually "forced" the directory structure to be cached by the RAM by simply running a find command, and thereby touching all the directories.

find /mnt/disk*/concerts/ /mnt/disk*/documentaries/ /mnt/disk*/movies/ /mnt/disk*/series/ /mnt/disk*/standup/ /mnt/user/concerts/ /mnt/user/documentaries/ /mnt/user/movies/ /mnt/user/series/ /mnt/user/standup/ -type d

But I'm still wondering why Emby needs to access the directory when all the metadata is supposed to be in the server folder, which is currently on a separate SSD? Any ideas?

embyserver.txt

[nojaha 4]

If it helps I've rotated the log file, still with debugging enabled, and ran the "inotifywait" watchers again, and saved the output, to align the two logs and be able to compare timestamps, and perhaps narrow down what is triggering it

embyserver_inotifywait.txt inotifywait_log.txt