I recently transitioned from a PMS install on Windows 10 (acting as my primary server) to a PMS install on a Synology DS1520+ NAS, which is now running current-version PMS for Synology, along with a successful migration of my “Plex Media Server” directory from Windows, methodically following the FAQ instructions to complete the Windows-to-Synology transition.
In the last 48 hours since getting Plex up-and-running on the NAS, I’ve noticed loud and unrelenting read/write access on the drive. Similar Plex support forum posts mention similar concerns, but on my end, I can confirm that stopping the Plex service causes the read/write to audibly cease immediately. Upon restarting the Plex service, the read/write access begins once more and rhythmically continues until the service is stopped.
Though I’m not looking to emulate any sort of HDD hibernation environment, the NAS is situated in an office workspace, and Plex has become the sole cause of this audible read/write noise.
Given the attached logs, I ran a test my leaving PMS running for several minutes (no Plex web or other plex player clients accessing files), then stopped the service, then restarted it.
Could anyone on the Plex team advise if there’s any indication in the logs that Plex’s server settings are off or inherently causing the relentless HDD access? Is there any way to mitigate it, beyond scheduling Plex to be stopped/started at preordained times?
Whenever you install Plex on a machine and setup new library sections, unless you expressly turn off certain features such as thumbnails and chapter images, Plex will go through every piece of media you have indexed and process it.
For video - Chapter markers and thumbnails
For photos - Thumbnails
For music - Loudness analysis
All of this in conjunction with the normal metadata it will download.
What you are experiencing is normal for every initial load up.
Once complete, you might want to consider turning off some of the refreshing options in Scheduled Tasks which refresh certain things every few days.
Thank you so much for the quick action and response on this!
For reference, I’ve attached a pair of screenshots covering my Settings > Library section within PMS. I wanna call attention to the fact that I’ve attempted to mitigate undue, constant “activity” via toggling certain functions on and off as necessary. This came by way of browsing other similar support posts, in which users reported favorable results by disabling functions like " Scan my library automatically."
“What you are experiencing is normal for every initial load up.”
If I understand the above correctly, is your guidance here that the level of HDD read/write activity should considerably fall off after the first several days post-initial setup?
“Once complete, you might want to consider turning off some of the refreshing options in Scheduled Tasks which refresh certain things every few days.”
For reference, I’ve also included a screenshot of my Settings > Scheduled Tasks within PMS. Anything there can be explicitly leading to constant HDD read/write access/activity to the extent I’m focusing on here?
Prior to assuming that Plex was inherently at fault for this issue, I actually made sure to fully disable Indexing in DSM for File Station and all the rest. For reference, screenshots below of those settings in DSM 7.
As a reminder in case I neglected to hone in on it enough in my original post, the audible HDD read/write access is only present when the Plex service is running. The moment it’s forcibly stopped, activity ceases to any appreciable extent.
In regard to hibernation, my goal here isn’t to have DSM send the device into hibernation (as @ChuckPa has provided guidance in other support posts detailing how ill-advised it is to have the drives spool down and then spool back up via hibernation). The goal is simply to replicate the level of read/write activity/access that can be audibly heard when Plex isn’t running. While I fully understand that Plex, as a running service, will need read/write access, it’s the prominence and the degree of that activity that’s alarming at this time.
Not sure if the Logs I attached indicate anything, but in case they do…
