[Gary Olsen]

Are all of the machines identical? Like in a lab? Do they have identical operating systems? The problem may be that there is a conflicting program that is causing the component to fail. It’s inhibiting the computer’s processor as it tries to compress the video or media file. The conflict may be a lack of compatibility between Windows (I’m assuming you’re operating a Windows platform) and Adobe’s media processor.

[Gary Olsen]

So the question remains, what have you done to correct the error? I know how to correct it in most cases. It is one of those software codes that is used to render digital video that no one but the programmer who created it knows precisely what it does I think. Nonetheless, I found that if my computer has been running on idle for awhile, and the available memory it needs to process video has been consumed or is busy doing something else, the error appears while rendering videos in Premiere CS4 and Adobe Media Encoder. I find that if I restart my machine, reboot the program, the problem disappears. One colleague mentioned that the problem appears when processing a project with an XMP file. First of all, an XMP file is a data file or a media file that contains integral data or information about an associate file. Did you try restarting the machine and did the problem disappear or is it still a problem?

[Gary Olsen]

Thanks for your input. In the ensuing months I’ve learned a lot about this error, and you are likely correct in what causes it, however, I have had contiguous files on one drive on a particular project, and I still got the error. And I have a computer so powerful, I have to wear a lead jock just to operate it. So it isn’t necessarily a matter of operating off spec. I got speed, RAM and storage for days. What I discovered, however, is that if you’ve been working for a long period of time on the same project, and you go to make a movie through the Adobe Media Encoder program, the error is likely to appear. If I reboot the system, and try my project again, no error! I’ve become so good at anticipating the error, I can almost predict it will happen. My guess is that this important DLL or whatever it is may lose contact with the project when available scratch memory is in short supply, or it just loses its connection with the project being encoded. And, if a particular clip being rendered is on another disk, as you described, and the disk may have spun down or its connection was interrupted to the CPU (and therefor the project), then the headless error will appear. I’ve even stopped the encoding when the error appeared, waited a little while and and then resumed or restarted the encoding without quitting the application, and the encoding continued on its merry way without a reboot! Hmmmmmmm. Wild! This recovery doesn’t happen all the time, but it has a few times. It’s one of those errors that has become manageable.

[Gary Olsen]

I don’t get the problem much anymnore, and I think I know what causes it. The connection this application (proheadless) has with the program becomes disconnected somehow, perhaps a system conflict with Windows (that’s what I’m using). I find the problem disappears if I just reboot the system and try again. Sometimes if I’ve been editing for a long stretch, and then I go right to export, the error resurfaces. A simple reboot of the entire system should reconnect all of the necessary utilities that got lost or disconnected in software, and you should be back in business. Every system benefits from a reboot from time to time.

Anyway, it worked for me.

[Gary Olsen]

If you read back on my posts, you’ll see the difficulties I had with this problem. It is likely you have a bad video file, but there is a workaround. If your video file plays from a tape, camera, or disc device attached to the camera, try recapturing it from your source footage.

To determine where the problem is, you will notice during rendering and just prior the error, there’s a clip that can be identified as responsible for the error depending on where the rendering stopped and the message appeared. Recapture that footage and create a new file. Import the new clip into your project and delete the old one. Then try rendering your project again.

I shoot direct to disc, so I usually transfer the files directly from my camera’s hard drive or flash memory card to Premiere. If like me you do it this way, try something different in capturing your footage… say through the HDMI connection, Firewore (iLink) or through your component video cable.

This has worked for me. Adobe has not come forth with a problem analysis or a fix for me. This is something I worked out with fellow users of the product making suggestions via posts to Creative Cow.

[Gary Olsen]

A (final?) followup on the problem of the PProHeadless.exe error. It has, for all intents and purposes, disappeared! Everything is working normally. But how can I rest without wondering if it will return to vex me? One who respondend to this thread suggested I had corrupt video clips. That may have been the cause. You see, I use hard drives and flash memory on which I record my video. No tape, no capture… just straight file transfer. You would think that such files would be pristine, and for the most part, they are. But if you don’t occasionally reformat your drives, you may impart a corrupt tag onto files that will not affect the video… which will play, and you can import it, put it on the timeline, slice it, dice it, and fry it in the pan, but when you attempt to output the finished project, you get the dreaded PProHeadless.exe error. I examined the file importation data log when I was importing clips, and I noticed there was trouble. The data log reported “problems” with certain clips. In Premere CS4, it’s a little window in the lower right hand corner of the time line. Subsequently, more care and frequent re-formatting steps on my camera’s hard drive and flash memory is my routine. Takes no time at all, and the result is clean files, and the problem disappears. Okay, I know what you’re thinking. How doI fix the corrupted files? Well, on my cameras I have tape backup, so I keep that source file and injest(capture) it the old fashioned way, and the result is a clean file. Hope this helps someone out there who encounters this problem. Ironically, this may not be the cause or the solution. But it worked for me, so if it’s a coincidence, a fix is a fix.

[Gary Olsen]

Good information. However, this is a totally clean and brand new platform, so no legacy software was ever on it! I wonder if it has something to do with the fact that all of my video content (AVI comes from a hard drive (Sony) that is integrated with my camera, the HV1U. Maybe there’s something imbibed in the format of those videos that are causing the inconsistencies? I’ve got to do more testing of other files and imported footage. The list of possibilities is still quite long, and I am no closer to narrowing the field or figuring out any single cause. IS THERE AN ENGINEER OR CONTACT AT ADOBE I CAN CONTACT WITH MY LOG FILES SO WE CAN HAVE AN EDUCATED ANALYSIS? Can anyone help me with a contact person, and email, a wonklist or a phone number (that would be great)?

[Gary Olsen]

Okay, what does it means when you get a “File Importer detected an inconsistency in the file structure . Reading and writing this file’s metadata (XMP) has been disabled” in the Events Report window in Premiere? Could this be the cause? How can I fix this?

[Gary Olsen]

I think I may be closer to a solution. I’m breaking the movie timeline up now and saving them as AVI rescue files to be reassembled on another machine. Hopefully this will work. The AVIs are rendering pretty well. This was in reaction to someone suggesting their may be corrupt files. So while I’m doing this, I look in the lower right hand corner of the screen and see a triangle warning sign. It reports that the files I’m using have “inconsistencies” in their file structure. What does that mean, and how can I fix it? This may be at the heart of my problem. Further investigation ensues.

[Gary Olsen]

I’m trying that right now. However, the file stops rendering in different places… sometimes in the middle of the show and sometimes at near the end. It is stopping on a different clip source each time. But let’s see what this experiment yields. I’ll back at ya.