Downloading/Syncing FAQ for dummies

I think it would be really helpful for Plex to release a Dummies Guide to Downloading/Syncing for Plex Premium members. The goal here is to get the content from a Plex server to my ipad/kindle/iphone as fast as possible, nothing fancy, and all using local LAN (not public internet) so that the content can be viewed offline.

After (finally) getting my movies and shows to download, a few things stood out for me:

  1. It’s not clear what determines the “converting” speed seen when media is preparing for download. Obviously this will be driven, at least in part, by the Quality setting selected by the user (720P, etc.) but let’s assume that we’re keeping things simple and sticking with ORIGINAL.

  2. Even with ORIGINAL setting, where I’m trying to basically just download the file as-is, there’s converting going on. This was a surprise since I basically just wanted to do a bit-for-bit download of the file and was hoping that a 1GB file would fly across my LAN like any other data copy (limited CPU horsepower needed). After reading the forums, I now understand why there’s conversion happening so that it can play on my device…but it’s not what I expected.

  3. No clear idea what would speed things up

  4. No idea which tablets are best suited for Plex. Will Plex download content faster to an iPad than Kindle? Does it even matter that the iPad has more processing horsepower than the Kindle? Does client-side processing power matter at all in this calculation?

#3 is the real pain and it causes a lot of frustration. I’d happily down-convert my media to super low settings if I knew that doing so would mean a faster file transfer, but there’s no way of knowing what is going to speed things up. Should I stick with ORIGINAL size and just let it convert/download that big file, or should I suffer the conversion penalty to get the file into a less dense file size (speeding up download speeds with smaller file)?

Mainly by

  • the video encoding and the bandwidth of the original file. A file in H.264 and 3 mbps will convert faster than a file in H.264 and 30 mbps. And if we go to 4K HEVC with 50 mbps, you can expect conversion slowing to a crawl.
    The target bitrate has a relatively small influence on the overall conversion speed. But lower target bitrates encode faster.
  • the processing power of the server

See above. You want a really speedy server CPU with a top ‘single-thread performance’ rating. More cpu cores do help, but if they come at the price of lower single-thread performance, then pick a different cpu.

Hardware transcoding capability is good to have as well. I actually don’t know if it’s currently used for background/sync transcoding. But if it doesn’t, it might in the future.

After the conversion is done, you want to keep your mobile device “awake”, so it doesn’t go into power saving and thus halts the Plex app or steps down the speed of the WiFi and its internal processing. Best to plug it into the charger while syncing. That way the prepared/converted files can transfer fast and efficient.

Avoid creating sync jobs with too many items in it. There are certainly ppl who like to sync their entire music library, but honestly, the Sync feature was not built for this.

For daily use when watching tv serial content, you want to sync this way:

Sync the tv show at its top level (i.e. not by selecting single episodes).
In the Sync dialog, restrict the sync to ‘unplayed’ episodes and their number to e.g. 5.
That way, when you play a synced episode and your device still has a internet connection, it reports the playback of the episode immediately to the server. Which then immediately starts to prepare the next unsyced episode. So when you arrive at a WiFi network, you can start the Sync and the transfer can commence immediately, without you waiting for the conversion.

Tip: for smaller screens (phones) and ‘animation’ content you can go as low as 1.5mbps for target bitrate. If you reduce the “speed” of the background transcoding, you give the transcoder more time to find better strategies to preserve more details/visual fidelity.
Settings - Server - Transcoder - ‘Show Advanced’ - “Background transcoding x264 preset”
On the other hand, you can set here a higher speed to save time. But you must pay the price by having to pick a higher target bitrate to achieve the same visual quality.

Thanks for the detailed reply. I think that this point alone is really valuable for people to understand:

Knowing that the source bitrate is what kills transcode times means that the only way you get around a download taking forever is having a pre-processing step (outside of Plex) to decode the files to lower bitrates. Looks like H.264 and 3Mbps or something <30Mbps is ideal. I’d way rather down-convert my whole library at once (handbrake) and then have everything stored in Plex in that format/birate then have to suffer the penalty of download speed every time I try and download a show/movie to Plex.

…but in the scenario where everyone’s libraries remain dense, it sounds like having a solid single-threaded processor is the key to decreasing times.

…and in the scenario where you just don’t have a fast processor (like my setup, ideal for low power consumption) then there’s really no option to “speed up” downloads without first pre-processing them on a faster computer. Even down-converting the target bitrate to something real low won’t help.

I think it’s safe to assume that most folks will assume that leaving everything at “ORIGINAL” quality would mean that no transcoding needs to happen - that the file just gets copied over and the copy would therefore be faster - so Plex may want to have a quick heads-up that this is not the case.

Original is not the original file.

It is a transcoded approximation of the original quality.

Sync will always transcode.

You will never get a duplicate unmodified file via sync.

The only way to direct download a file through Plex is via Plex web.

And only the admin can, so you cannot download files from someone else’s server.

That’s not what I meant. A single-threaded processor would have only one core. That won’t give you good performance.
What I meant: if you have the choice between some CPU’s with similar overall performance, but with differing core count. Look up how they perform with just one task/thread.
Look them up here https://www.cpubenchmark.net/

Yep, sorry, understood on the processor feedback and thanks for the link.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.