A long pause usually means transcoding is commencing.
Sometimes, it can also mean that the source file is stored on a hard drive which first needs to be woken up because it has been spun down. Leading to a long waiting time upon first access.
Check the Dashboard in Plex web, opened in a second web browser window or tab.
Expand the details, so you can see whether the server is attempting to transcode the video or not.
Do also look for the location of the client. If it says “remote” or “indirect”, when it should be “local”, you have to check your router/network.
Next step would be to verify the codec information of the played file. Whether it even can be played directly by the used Plex client.
Chances of Direct Play are lower with high-bandwidth and/or DoVi content.
Drive isn’t sleeping (internal drive on Windows Server 2016 - fully updated btw) and I double checked by starting the movie and playing in middle; stopped movie; then restarted movie from beginning. The restart still took about 20-30 seconds to play. The drive would definitely had been awake for the restart.
Movie is not transcoding and I’m also on “Local” network and it is playing at 17 Mbps.:
Are you using virtualization?
Is there an anti virus software in play?
Did you manipulate any of the advanced Plex server preferences, like e.g. TranscoderDefaultDuration?
How much free space is on drive C: ?
How much free space is on the drive which houses the TranscoderTempDirectory (which is by default on C: as well, but can be moved)?
Are your movies stored each in its own subfolder, or do you still have all of them stored inside a common, large folder?
Is that movie inside a mp4 container?
Anti-Virus software is Microsoft’s Defender and is active. I just now tried to disable it and no change to the stream load time.
I had changed the Transcoder Default Duration to 180. I just now changed it back to 60. No change to stream load time
270 GB free on C: drive which is a 1TB SSD.
TranscoderTempDirectory is on C: drive I believe since the field is blank and Plex is installed on C:.
Each movie is stored in its own subfolder.
This movie is in a .MP4 file container.
FYI, Tuesday was Microsoft’s Patch day and the patches just became available to me, so I just now went ahead and installed the latest patches and restarted the Windows server. No change to the stream load.
I will say that this is NOT every movie. My “Pacific Rim” fired up in about 2 seconds. It is also Direct Play and is on the same HDD as “Tron Legacy”, however, “Pacific Rim” is an MKV file.
180 is a reasonable value. I don’t see any reason why you shouldn’t keep it.
This comes up relatively often. mp4 files are sometimes produced by certain people/apps/scripts which are not conform with good practices for streaming media.
There are 2 things to consider here (which ultimately belong to the same topic):
“optimized for streaming” This signifies that the file header with metadata about the file has been placed at the start of the file, instead of at the end. Plex can show you whether this is the case for an mp4 file in the plex media info.
mp4 files must be muxed using “interleaving”. This means that the data for video, audio and subtitles are always stored in chunks together for the next few seconds of play time. Some mp4 files are simply storing the video stream first, then the audios stream(s), then the subtitles. Unfortunately, Plex cannot show you this fact (and so far I haven’t found any freely available tools which could do this, either.)
As you can imagine, this requires the Plex server or the Plex client (depending on whether it is direct played or direct streamed or transcoded) to always jump back and forth within the source file. With files sizes of several GB, this can easily take quite a while to gather all the data to even start streaming. The problem can get even worse, if the RAM of the server is so small, that it cannot contain the whole source file at once, in the disk file cache.
Remuxing it into a new mp4 container changed the internal file structure, so that it now uses proper interleaving. So the issue vanished.
I can only recommend to investigate how the faulty file was produced, and adjust the workflow accordingly to avoid the app responsible for the improper muxing.
Very interesting. I was just noticing that option in Avidemux; “optimized for streaming.”
I can’t be certain, but I believe I created the Tron Legacy file from my blu-ray disc using Handbrake. But, maybe I’m wrong.
I will however, keep a closer eye on things when using Handbrake and remuxing. If I also come across any other slow loading files, I’ll give remuxing a go.
Note that “optimized for streaming” can get lost as soon as you edit the file’s metadata. So you might have to repeat the optimization at the very end of the preparation workflow, before you place the video onto your server.
Hint: mp3tag can also optimize mp4’s. Several at once, if you tell it so. (Although I am unsure whether that also includes interleaving. It might just be the position of the file header.)