Server Version#: 1.19.4.2902-69560ce1e-x86_64
Player Version#: 1.12.1.1253-c29aa096
Device: DS918+
DSM: 1.19.4.2902-69560ce1e-x86_64
Since one of the recent server updates, I’m assuming as early as firmware version
1.19.3.2831-181d9145d-x86_64, my server has been feeding excessive data to clients when set to “Original” quality. This does not happen to when a video is transcoded and only applies to local play, from what I’ve been able to test.
The issue seems to only affect .mp4 videos. Both a 480p video with an average bitrate of 3 Mbps and a 1080p video with an average of 7 Mbps (of which combing through with VLC only ever showed a peak of around 9 Mbps) results in the media server outputting between 290 and 360 Mbps.
In contrast a much higher quality 1080p .MKV file with an average bitrate of 28 Mbps will peak at the same 360 Mbps very briefly when the video is started and then quickly level out to being between 34 and 44 Mbps.
And, yes, the video codec is H.264 for all mention files (both .MKV and .MP4).
This happen regardless of the client. I’ve tested this on NVidia Shield Pro 2019, Plex for Windows 10, Plex Media Player (Windows 10), and a Samsung Galaxy S7 (all client apps are up to date as of 6/10/20). On Plex for Windows 10, at least on my desktop, this excessive data causes the app to constantly freeze. All other clients seem to play the videos fine, including Plex Media Player on the same desktop.
Still, this significantly eats away at my local network’s bandwidth and could easily bottleneck it if three people decide to watch something at the same time. I’m not sure if this is a side-effect of the watch together feature that was added, some kind of other bug, or an issue isolated to just my server.
This is normal. The traffic initially bursts to fill the client buffer, then settles down for the duration.
Similar thread linked below. The problem, in that thread, is that the movie is poorly encoded and/or multiplexed.
You can try re-muxing the file to see if that helps. If it does not, try re-encoding it. Remuxing is a lot like “save as” in a word processor, etc. It makes a copy of the file, hopefully correcting any errors along the way. It is fast and should take just a few minutes to complete. Re-encoding is creating a new file from the original source (if you have it). It may take hours depending on the source material and the speed of the system where you are transcoding (hence, the suggestion to try remuxing first).
MKVToolNix: Can take MP4 as input. Output is MKV only. Use Multiplexer tab.
XMediaRecode: Can remux (copy) and re-encode. Works will multiple containers, including MP4 & MKV.
Subler: Mac only. MKV/MP4 input. MP4 output. Very good muxing tool. Can also download metadata (cover art, actors, etc) from online sources.
Handbrake: Transcoding/encoding tool. No remux capability.
With any tool and output is MP4 container, be sure and optimize the file. It will show up as Optimize, MP4 FastStart, or similar. This moves some bits around in the MP4 header so the client buffers less information and streaming begins sooner. Google “MP4 Fast Start” for more info.
I was aware that the initial burst of data at the start-up of videos is normal. I just found it somewhat suspect that the burst hit the same exact bitrate that .MP4 videos are capping out at.
I never knew re-muxing could solve such issues. I’ve used MKVToolNix to edit chapters and separate video files, but never assumed it could smooth-out playback.
I downloaded the XMediaRecode tool you suggested, as I wanted to be sure to confirm if the problem persisted with a re-muxed .MP4 file (to ensure that it wasn’t some kind of error with my server handling .MP4 containers). I tested a re-muxed video (same video used in the original example) with “Fast Start” applied to it and that did the trick!
Unfortunately, the problem extends to almost all of my .MP4 content, so I’ll have to re-mux a good chunk of my library. It’s still odd that this issue didn’t occur until after one of the recent server updates
Additionally, on an unrelated note to the original issue, should I not choose the Audio / Video sync option? It seems to cause the audio to be a bit ahead of when it should be.
Anyways, glad to have a fix. Thank you so much @FordGuy61!
Oh, just thought I’d ask, as it was on by default. I wondered if the program had audio-sync issues and that was some sort of beta-feature.
Sadly, I’m not well-versed on scripting. I had hoped there’d be a “select all tracks” option in XMediaRecode, but sadly there is not. It took several hours, thanks to that omission, but I’ve finally remuxed all the .MP4 videos in my library. All are recognized as “Web Optimized” by the Plex client and there’s no more excessive data transmission.
I’m not too concerned with certain metadata being transferred, as Plex can pull that data from most agents. Plex still shows all data formerly displayed, so no issues there. Also, not sure what you mean by optimizing the file. Remuxing through XMediaRecode with Fast Start selected causes it to register as “Web Optimized.”
