Server Version#: Version 1.86.1.4076-a3ab948d
Player Version#: N/A
Plex Pass: Yes
I’ve recently moved my Plex setup from running in docker on a Linux host to docker running on my Unraid server that holds all my media. In my current setup, I have 4 media drives (spinning HDD) and 2 appdata drives (SSD). This works great, as I no longer need Plex to reach across the network to a NAS to watch things, and the experience overall has been very good.
I’m trying to pay more attention to my drives spinning up and down now that I have this information more easily available in Unraid. Basically, if the media drives are not accessed by anything for ~8 hours, I’d like them to spin down and rest. Then, when needed, they can spin up to serve files again. I’m hoping this extends the life of the drives, as there are periods where we won’t watch anything for a few days, and they don’t need to be active in that time. Ideally, this means the drives would only be active and spinning when:
New media is added and during its initial processing
Something is being served to a client
For 8 hours AFTER the last access happens (before it spins down again)
When Plex needs to access them for scheduled tasks
When someone is accessing something else on the NAS (not Plex media)
As I try to minimize the unnecessary spin-ups, I’ve noticed that Unraid catches certain files being opened every day very close to the same time. They are media files from Plex that were added to the library a long while ago, and presumably should have had their scheduled tasks completed a long time ago. It’s spread across three libraries (Movies, TV Shows, and Kids TV Shows). Here’s some more info:
One episode from the TV shows library (intro/credits detection on, video thumbnails off)
Ten episodes from the Kids Shows library (intro/credits detection off, video thumbnails off)
Four movies from the Movies library (credits detection off, video thumbnails on)
Overall I’m trying to find out where I should be looking in the logs (or a third party tool/plugin?) to identify what Plex is trying and failing to do against these files. It’s not a big deal if Plex needs to spin up the drives for scheduled tasks, but it feels bad that it’s the same files over and over again, since that doesn’t seem like things are working as they should.
Usually caused by analysis jobs during the server maintenance.
For video files, it is usually a failure generating video preview thumbnails (or chapter thumbnails). Typcally occurs with obsurer video formats or ancient file formats like AVI.
What may help with this is to instruct Plex to decode the whole video stream and not to try and use only the key frames. Set the hidden server preference GenerateBIFKeyframesOnly to 0
For audio files, it is typically either the loudness or the sonic analysis. I’m afraid there is usually nothing you can do except to rip again and use a known good encoder.
(Although for mp3 files there is MP3 Diags download | SourceForge.net which I have used with good success for cleaning up and repairing my rag tag collection of old mp3’s.)
It’s weird, because the files it’s checking in the TV library explicitly have the video thumbnails turned off, I deleted them all again to make sure they were gone from the Plex UI for the library, and they do have chapters already indexed (even in the right spots!). So more than anything, I’m wondering what else I can check to see what Plex thinks these files might be missing that it’s trying to do?
I just checked, and the file I’m using as the guinea pig also has intro and credits detected already.
Media info:
Media
Duration 21:17
Bitrate 11493 kbps
Width 1280
Height 720
Aspect Ratio 1.78
Video Resolution 720p
Container MKV
Video Frame Rate 24p
Video Profile high
Part
Duration 21:17
File - Filename redacted -
Size 1.71 GB
Container MKV
Video Profile high
Codec H264
Bitrate 10852 kbps
Language English
Language Tag en
Bit Depth 8
Chroma Location left
Chroma Subsampling 4:2:0
Coded Height 720
Coded Width 1280
Frame Rate 23.976 fps
Height 720
Level 4.1
Profile high
Ref Frames 9
Scan Type progressive
Width 1280
Display Title 720p (H.264)
Extended Display Title 720p (H.264)
Codec AC3
Channels 6
Bitrate 640 kbps
Language English
Language Tag en
Audio Channel Layout 5.1(side)
Sampling Rate 48000 Hz
Display Title English (AC3 5.1)
Extended Display Title English (AC3 5.1)
Codec SRT
Language English
Language Tag en
Display Title English (SRT)
Extended Display Title English (SRT)
So it has Dolby audio.
And the intro detection will be renewed upon the file chaning or the detection code getting updated.
I’d verify that the general /tmp folder of your server has been mounted without the noexec flag. Otherwise, the attempt to decode the audio (for detecting the intro or for transcoding) will always fail.
OK, the /tmp folder is ephemeral and contained (and owned) by the container processes and not the host running the containers. So there should be no issues with permissions or anything like that. If your theory is correct, what could/might I see in the logs to support it? Finding the root cause in the logs is what I’m looking for here.
I did check the XML data for the problematic file against a file from the same season and release group, and it looks like (minus the data differences), the same fields are filled out with similar data. So that’s another question mark as to what might be wrong, because I don’t see anything missing at a glance.
