The Life and Times of Jeff Squyres

iDVD suckage

It turns out that there is a well-know bug in iDVD (or perhaps something that affects iDVD? It’s not clear) that causes hours of delay when burning a DVD on OS X. It’s not entirely clear if the problem is in iDVD itself or whether it was introduced in an OS X update (e.g., 10.4.8). Here’s a bunch of people talking about it:

Many thanks to those who posted above — this was exactly the problem I was running into as well (spinning beachball of death during audio encoding). It was good to see that being patient would fix the problem.

I have one piece of information to add to the mix: it may not actually be the overall audio encoding that causes the long delays (!).

Let me explain.

I, too, saw many hours of no apparent activity from iDVD while encoding my 1 hour movie. I just happend to check back once when I noticed that it started to actually encode the audio. That is, it was in the “Encoding audio” stage, and the progress bar had just started moving! And once the progress bar started moving, it completed within a minute or two. Then it progressed on to the burn stage.

So something is happening during all those hours of spinning-beachball-of-death, but I don’t think it’s the actual audio encoding itself. Indeed, audio encoding is a relatively “solved” problem these days — itunes and imovie have shown that apple knows how to do this well. But the fact that the progress bar shows nothing and Force Quit shows that iDVD is “unresponsive” indicates to me that this delay may actually be a real bug — something that is supposed to be more-or-less instantaneous (i.e., perhaps step 1 in the audio encoding process, preprocessing the data, or setting up internal data structures, or …?). But instead, some bug in the coding makes the “supposed-to-be-instantaneous” process take many hours.

Shrug. Who knows?

I just wanted to let everyone know that when the audio encoding seems to actually start, it’s pretty snappy (as one would expect). Indeed, the wording of Apple’s help article (URL cited several times above) is pretty cagey: “Even though iDVD may appear to have stopped working, iDVD is probably still encoding audio” (I added the emphasis). That’s quite a statement. ☺

So I’m guessing the real problem is actually something else.

After I wrote that section, I was burning a few DVDs and decided to run the OS X profiling application Shark on iDVD. I don’t know much about Shark, so I could be totally mis-interpreting the results, but it looks like iDVD is spinning in a [wait4()] system call. I’m not sure exactly:

What it’s waiting for

Why it takes so long, or

Why it’s so CPU-intensive

But there you go. I’ll poke around some more and see if I can figure it out (e.g., I don’t know how to interpret the Shark results to see if I can extract the PID that iDVD is waiting for).

FWIW, to see if it was a CPU starvation issue (e.g., iDVD spinning hard and not letting whatever it was actually waiting for make any progress), I did some experimentation with nice values, but to no effect. Increasing the nice value of iDVD (to potentially let sub-processes make progress) didn’t help. Indeed, top shows that even with a high nice value, iDVD is just about the only process (or an otherwise dormant system) that is consuming sizeable CPU time.