basspig
Veteran
I found something out today that seems to add weight to a hunch I had about CC 2015's playback problems being related to the SATA controller/driver.
Since discovering the Lumetri scopes disabling, I was testing it on my old quadcore and found that I could get almost fluid playback of XAVC 4K on the Core2Quad with 8GB RAM. Another thing I noticed is that opening Task Manager did not cause it to drop frames. In fact, multitasking didn't bother it at all. Moving files around had no effect on it.
But over on the dual Xeon machine today, I was copying some files to a newly installed SSD drive. Premiere was reading source material from H:. The drive I was copying over materials to was M:, on a separate controller channel. It was going to take an hour, so I decided to do some work in Premiere CC 2015. I was rather surprised that the app could not play anything at all while files were being copied. It just acted like it does for the first 3 seconds of normal playback, but indefinitely. None of Premiere's drives were involved in the file copy operation, but the fact that the south bridge was active was enough to stop it from staring playback.
So this points to some sort of crummy SATA driver that cannot support simultaneous operation by two or more threads. I note that when first starting play on CC 2015, there is a heap of disc activity before playback begins, like the player module being loaded into RAM. That disc activity seems to lock out reading the video file until the player module is copied to RAM. Because when I stop and restart playback, there is no big disc activity the second time.
In short, if ANYTHING accesses ANY disc on the system, even for a millisecond, Premiere CC drops frames. Normal system background activity causes disc access every few minutes, which corresponds with the frames dropped every few minutes. The thing to solve is why Premiere CC can't function during disc I/O on the new Intel chipset, whereas it can on the old chipset.
This is a conflict between CC and the SATA driver. CS6 does not exhibit any delayed start of playback on the dual Xeon. Unfortunately, I am running the most recent drivers that Supermicro has on their web site. I've reported the issue to them and maybe they'll look into it.
Since discovering the Lumetri scopes disabling, I was testing it on my old quadcore and found that I could get almost fluid playback of XAVC 4K on the Core2Quad with 8GB RAM. Another thing I noticed is that opening Task Manager did not cause it to drop frames. In fact, multitasking didn't bother it at all. Moving files around had no effect on it.
But over on the dual Xeon machine today, I was copying some files to a newly installed SSD drive. Premiere was reading source material from H:. The drive I was copying over materials to was M:, on a separate controller channel. It was going to take an hour, so I decided to do some work in Premiere CC 2015. I was rather surprised that the app could not play anything at all while files were being copied. It just acted like it does for the first 3 seconds of normal playback, but indefinitely. None of Premiere's drives were involved in the file copy operation, but the fact that the south bridge was active was enough to stop it from staring playback.
So this points to some sort of crummy SATA driver that cannot support simultaneous operation by two or more threads. I note that when first starting play on CC 2015, there is a heap of disc activity before playback begins, like the player module being loaded into RAM. That disc activity seems to lock out reading the video file until the player module is copied to RAM. Because when I stop and restart playback, there is no big disc activity the second time.
In short, if ANYTHING accesses ANY disc on the system, even for a millisecond, Premiere CC drops frames. Normal system background activity causes disc access every few minutes, which corresponds with the frames dropped every few minutes. The thing to solve is why Premiere CC can't function during disc I/O on the new Intel chipset, whereas it can on the old chipset.
This is a conflict between CC and the SATA driver. CS6 does not exhibit any delayed start of playback on the dual Xeon. Unfortunately, I am running the most recent drivers that Supermicro has on their web site. I've reported the issue to them and maybe they'll look into it.