If only it were possible to reek terrible and bloody vengeance upon software. If it were, then I think that would solve about 90% of the stress in the western world.
I'm working on this project thats been going on since January. Its about 6 hours of footage - not special footage - but the problem with 6 hours is that EVERYTHING takes a long time. I swear, on the 2.5ghz G5 the FCP project takes about 10 minutes to load up.
While most of the original bitch work on the project was done by the incomparable Jamie Nimmo, I've had the 'pleasure' of DVDifying it.
Well... what should've taken about 2 days has taken nearly 7. Why?
Well, firstly every time I tried to export the timeline from FCP so I could, y'know, encode the footage and put it on a DVD, FCP would randomly *hang* (not crash) somewhere seemingly at random during the export. I quickly determined that it was something to do with the render... BUT it took three days for me to isolate the problem. When you're dealing with that much footage, the whole process slows to a crawl. You make a small change, start rendering, 10-20 minutes later the render crashes, you force quit FCP, you load FCP, 10 minutes later you make the changes... repeat... and repeat... and repeat as you try to isolate every possible bloody combination of Things Which Are Known to Make FCP Spew. The testing cycle was seriously long. Every time it appeared I made a breakthrough, the render would merely crash later on during the sequence. This is a fundamental flaw of the FCP render method and why, say, After Effects solution is so much more elegant. With AE you can see what is happening on a frame-by-frame basis and even get an error report written to during the whole render thing. With serious apps like Shake, you always render into image sequences cause then you can easily pickup where you crashes. Not with FCP - even the render scratch is a mess.
... and guess what I finally discovered the problem was with? The disk. Even though I ran Diskwarrior on the damn thing - twice - I only finally twigged as I was pouring through console logs. I had taken samples of the FCP process during the hang - which reported no crashed threads - but I had no crash logs cause FCP wasn't crashing, just hanging at about 85% CPU activity. Weird. Finally, I noticed a weird little thing. The system.log (not console.log) reported three Disk IO errors on dev/disk2s3/ in about 5 minutes... and the time of the final disk error was the last modify date of the FCP render files. Ahar! Using the good old df command in the terminal I was able to determine that yes, that device was the drive that housed the project.
Thank bloody god I had all the projects assets (which were over 1000 stills [for some time I think it was because we used TIFFs]) backed up on another drive and I was able to spend some time relink the latest version of the project on another drive... and that worked.
Did it end there? HELL NO.
After spending the requisite 2 days authoring the actual DVD (including encoding), I left on Friday night think 'cool, all I need to do now is build and test'. Oh boy, was I wrong. I load up the DVDSP Project today and one of the assets has disappeared. Well, it hadn't disappeared in the sense that DVDSP couldn't find the asset. It could find it, but there was no actual VIDEO in it. All my motion menus (like 8 of them, including chapter menus) were all like empty. WTF? After some dicking around with the PAR files and trying to relink to the same asset, I just decided to reencode the asset. I went to my Ref file and encoded it. You see, when dealing with 1.5 hour quicktime files I prefer to use ref files rather than render then export the whole thing again. Now, I KNOW I hadn't touched the render files, cause I wanted to have the option of going back to the originals. Well, after encoding all the footage AGAIN, I discovered that - um - the refs to original files had broken. The files where there, but they were unable to be linked back to. So I had to render this 1.5 hour video again then re-encode it.
I opened up the DVDSP project and, guess what, the other video assets had disappeared in exactly the same way [grr]s Dunno about you, but for a project that was due to the replicator LAST WEEK, I wasn't looking forward to re-render and re-encode 4.5 hours of shite. So I dropped in the new m2v file and saved the project and started relinking. After getting a bit worried, I closed DVDSP and re-opened the project. Guess what now? The NEW asset had gone AWOL too. Hmm. Strangely, none of my motion menus (which weren't pre-encoded) had gone offline. Ah, guess the problem is with pre-encoded m2vs then. Easiest workaround (not solution) was to re-render all the remaining assets and import them, un-encoded, to DVDSP and rebuild the DVDs and encode-on-build. Not really looking forward to the time on that one.
So, I began to rack my brain about things which had changed in the system since the last big DVD I did which was about a month ago - possibly less. I upgraded to 10.3.8. That was a big one. I waited long enough to see if there any huge problems before I jumped... Hmm. 10.3.8 could certainly have been it, but I didn't want to downgrade either... so I searched my brain (and package receipts) some more. Then it hit me... After the CEREC project, I decided to change my preferences to place more files inside my DSP project package. That couldn't be it? Surely? So I tried shifting all my PAR files outside of the dvdspproj package... and guess what... it worked! I stressed tested it again and again and it worked. Damnit. Stupid PAR files stored inside the package were causing me the nightmares.
Phew.
Moral of the story? When testing, no matter how much project burnout you have, make sure you pass small amounts of data into testing pipelines. I could've discovered the cause of bug earlier if I wasn't so intent of trying to forget about the project. Controllable, discrete sets of data re good for mild stress testing then you isolate bigger possible solutions and use them with larger data-sets. Hmm.