In many cases I want to sync several movies when I go on a trip and my family wants to sync their own files. Plex media server currently just syncs sequentially and with six or more movies the night before we leave it often means a few don't make it. My CPU load during the sequential syncs rarely come close to saturation. It would be nice if Plex could monitor how much CPU is uses and sync as many files as it can in parallel to expedite the process.
It wouldn't speed up the sync. Instead of a few not finishing you would have all of them not finish. Your CPU load is not the limiting factor here, merely transfer speeds. Doing multiple files at once will not increase your transfer speed. In the scenario you stated you are better off doing 1 at a time so you at least get some of them synced.
It wouldn't speed up the sync. Instead of a few not finishing you would have all of them not finish. Your CPU load is not the limiting factor here, merely transfer speeds. Doing multiple files at once will not increase your transfer speed. In the scenario you stated you are better off doing 1 at a time so you at least get some of them synced.
This is not hitting the problem at all.
PMS is applying a strict sequential schedule to the sync-job. A smarter way would be to make it possible to transcode AND sync at the same time. This would dramatically reduce the total time needed.
PMS is applying a strict sequential schedule to the sync-job. A smarter way would be to make it possible to transcode AND sync at the same time. This would dramatically reduce the total time needed.
+1 for this improvement request
While nice if possible, that really doesn't invalidate my point. Doing multiple files at once will not speed up the transfer.
It wouldn't speed up the sync. Instead of a few not finishing you would have all of them not finish. Your CPU load is not the limiting factor here, merely transfer speeds. Doing multiple files at once will not increase your transfer speed. In the scenario you stated you are better off doing 1 at a time so you at least get some of them synced.
In my situation I don't see that as the case. I have synced plenty of 1080p movies of varying sizes. You can watch Plex encode files at varying speeds (1x, 2x, 4x, etc). I have seen several movies sit at 1x while the CPU and hard drive are underutilized. This is still the case even when they are moving along at 4x. Having the files synced in parallel would greatly increase the time of getting multiple files.
Transfer speeds for a optimal N network can approach 30 MB/sec but to be conservative let us say that your connection sucks and you get pegged at 5 MB/sec. Over that two hour period you could transfer if they were already encoded, 16 2GB movies. The other pipe is your hard drive but with my slow SSD I can easily get 80-100 MB/sec.
I'm personally not seeing the transfer ceiling you're seeing.
It should transfer as fast as it possibly can at all times unless you have QoS put in place. Take the 30MBps avereage on N you mentioned. If you sync a single movie it should transfer at 30MBps. If you sync 10 movies all at the same time the combined transfer speed is not going to go over 30MBps. They will transfer the same speed whether done sequentially or done simultaneously.
Transcoding could maybe be sped up with multiple being done at the same time, but they are still going to transfer to the device in the same amount of time regardless of what you do.
I think I may have misunderstood slipstreams before. If he was saying once one file is transcoded and the file has begun to be transferred, the next file should be transcoded while that first file is being transferred, then I could see that helping. I'm not certain if that is what he was trying to say though.
The problem described by kevinkarada addresses mainly a problem with the transcoder speed and not with the transfer speed of the data.
Considering that the transfer speed is in general higher than the output of the transcoder it should not really give problems anyway.
One problem seems to be that the CPU load is very low and the transcoding takes a longer time than needed.
I personally don't experience this problem on my setup. When a sync-job is started the transcoder pushes my CPU regularly up to 85 to 100%.
The transcoding process is actually independent from other processes and I would suspect a bottleneck somewhere else unless the parameters for the process are set in a wrong way by Plex.
For troubleshooting you could proceed as follows:
You can start the transcoder directly with a batch job and test if the transcoder can produce a high CPU load.
An example for a simple batch job on a Windows machine could be this:
It doesn't include all the parameters set by Plex but should give you IMO similar results in terms of CPU load.
I would personally expect the transcoder to be designed to max out the CPU if possible. In this case performing more than 1 transcoding at once would most probably not be the most efficient way to complete the task anyway. If the above batch job maxes out your CPU then I would suspect that the parameters set by Plex might not be ideal in combination with your computer. This would be something for the developers.
A different problem is that the transfer of the data to the sync-device can fail for all or some of the files.
One reason can be that the device is not available at the moment when the data should be transferred (sleeping mode) or that PMS doesn't know that the device is available (the device status has not been updated in time). Since the time to complete the transcoding can be quite long I would not be surprised if one of those might be causing your problem.
Now, with the brand new redesigned iOS App, apparently, we have parallel transfer of sync content.
Especially for remote connections (cellular or not), a sequential transfer is a must. Because of the already mentioned reasons. I’d vote for an option to set if to transfer in parallel (yes/no) for remote or local connections. Maybe also an option if to transcode new objects while transferring the finished transcoded ones until temp space is exhausted or all has finished transcoding.
And while the transfer is running, transcode can definitely run on new objects, as long as physical space is available on the server to store this data.
In my experience, the transfer is always the bottleneck, because transcoding is often running on 30x, 40x and even 60x. I almost exclusively sync TV series which transcode in a few seconds per episode on my server.
Also I don’t understand the difference between “Queued” and “Waiting” while the progress is the same (50 %). And the status “Downloading” suddenly switched to “Queued” in the middle of downloading. On the server and on the iOS device is enough space available (or is there a parameter to configure to limit temp space used for transcoding, I might have missed?).
While writing this post, my sync does not show any progress after the iPad locked itself after some time. After unlocking it, the “Sync” button is still grey and no progress can be seen.
But after closing the App (with swiping it up) and reopening it, progress seem to have happened in the background while the App did not show any update.
