I should probably mention that this problem doesn't cause too many issues with just 5 files in the project, but when there's 500 and it's reconforming a bunch every time, it's a major pain. Sometimes I'll get the spinning wheel for 20 minutes before I can even use PP. I make one click outside of PP and it starts all over.
I've got plenty of ram (24 GB)... It almost is acting as if Premiere frees up the RAM that's allocated to it for use elsewhere when I click outside of the program. And then when I come back it acts as if it is loading all the files back into ram all over again.... Maybe this is a separate issue?
Have you updated to 5.02? This latest version has improved on memory management.
Moving the focus back to PR means that memory, that was released upon leaving PR and giving another program the focus, needs to be filled again with pointers and links to your media files, especially from the media cache. Since that is located on the same drive as your OS, it means double duty for that disk, which slows down the process of regaining the focus.
Thanks for the input. I appreciate it. However, I've been running 5.0.2 for at least 3-4 weeks. What's weird, before 5.0.2 I was having problems with the multi-cam feature in the previous version and 5.0.2 cleared that up great. But in the process, now I have a whole new can of worms (i.e. projects with a lot of files come to a halt) and THIS current problem of files conforming over and over again.
Check out the video and you fast forward to see the conforming status bar pop up ever time I click out of Premiere. Very frustrating! http://www.youtube.com/watch?v=uFrXk4nTpwo
Hope there's a new update ready to go soon. I'm almost tempted to uninstall my current version and go back to 5.0.1 so I can use Premiere again.
Hi, I have the same problem and it is just as frustrating. I have a large project with over 900 HD videofiles
(xdcam mp4, panasonic avchd and gopro mp4).
I have Windows 7, PP 5.02 and a Quadro FX 3800.
When i used 5.00 and had my project on an external Lacie disk then the confirming time was over 40 minutes.
I upgraded to 5.02 and transferred the files to a local disk and the confirming time is shorter.
To make it worse, when i switch back to PP from another application PP doesn't "answer" and the screen goes white for 10-20 seconds.
For the moment i am in a bit of PANIC with my project.
I can't say I'm glad you have that problem, but at least I know it's not just us. I've tried this on a couple other computers just to see if I could isolate the problem to one computer, but no luck.
FWIW I'm running 5.0.2 (75 MC: 218798) and the updater says "your application sare all up-to-date"
Thanks again, Harm.
I stumbled across this earlier and did most everything you said except slightly modified for Windows 7. Still no joy. Thanks for the suggestion! I'll take anythign at this point.
Yes, yes, yes, everything in the list is done.
it is the first thing we do on a new computer.
I'll describe what happens first, as it makes the explanations of the failure cases a little more clear.
PPro generates two potential sidecar files for audio - PEK and CFA files. The PEK file is simply a quick data pass of the audio data that allows the app to draw waveforms (ie it should be pretty quick) - the CFA files are required if the file source is either too slow to decode the audio in realtime (like some MPEG long GOP, for instance), or if there's a mismatch in the sample rate depth. The idea is that the conform files will match your sequence's audio bitrate settings so that the app can play & mix audio in realtime.
How does PPro track these additional files? Every file that is imported is stamped with XMP, which is how we handle metadata on source files. XMP creates a unique ID which the app uses as a lookup value when it wants to find the PEK & CFA files that it generated for a file. So, usually, if you have a project where certain clips constantly reconform, it has something to do with XMP. Why? Usually it's because XMP can't write to the file. So, every time you launch PPro and open the same project, the media file has no XMP data, so it tries to generate a new ID, so any old CFA/PEK files have an ID mismatch and the app thinks it needs to generate new ones.
Typical cases why XMP can't stamp files:
- the media file is read-only.
- the media's hard drive is read-only.
- the file itself is corrupted/malformed, and XMP takes the safe route & decides not to try to write any additional data to the file. (I've personally witnessed this occur with WAV files captured by a Tascam field recorder.)
- someone deleted the XMP files by hand (certain media types have it as a sidecar .XMP file instead of embedded). (Don't laugh - I recently encountered a case where people had instituted a server folder rule to delete all files on a network share that weren't .mpg. )
A workaround you can try:
There's a preference setting to turn off injecting XMP into your media. If that setting is in effect, PPro will not rely on the XMP ID for the CFA/PEK files.
One other note, if your problem is specific to MPEG files: it might be that PPro isn't able to index the file properly. If it can't index, it might be trying to re-index on each launch; audio conforming always triggers after indexing. So watch for it constantly indexing - if that's the case, all the XMP stuff I described above has nothing to do with the problem. It's a side effect of something in the MPEG stream that we're barfing on. If you do see it constantly re-indexing MPEG files, it would be really helpful to send in a sample so that we can examine the stream.
Thank you for that detailed explanation. If you do not have a problem with my doing so, I would like to copy your reply to a Tips & Tricks article in the PrElements forum, as some users have had similar issues in that program too, and this might go a long way to helping them.