« November 2006 | Main | January 2007 »

December 2006 Archives

December 2, 2006

Yellow paint

I’ve had Tivo for about 5 years now, and I love it.

This Christmas, I was investigating upgrading to get a new model, perhaps with a few more features, more space, etc. It turns out that Tivo purchase and payment options are crazy complicated — they’re just as bad (if not worse) as cell phone plans.

On the surface, they’re simple, but there’s a million combinations of factors, only some of which are valid. Indeed, the language on the Tivo web site seems to contradict itself with regards to multi-service discount, for example (I am left to wonder — is anyone eligible for multi-service discount?).

Woof.

While it’s annoying, I can understand why cell phone plans are compilcated. Here’s my theory: all cell phone service is more-or-less the same, so the companies differentiate their products by claiming that their plans are “the best”. But in reality they’re so complicated that it’s difficult — if not impossible — to make a true apples-to-apples comparison). Indeed, the very complexity of the plans makes it easy to highlight specific features and claim that they’re “better” than the compeitition.

But why on earth would Tivo need to do that? Flexibility in purchasing is a good thing. But flexibility to the extremely, where it’s so confusing and detail-specific — and then to have contradictory language on the site explaining all the details — that’s just not helpful. ☹

FWIW, I decided to stick with my current first-generation series 2 Tivo. Since I have a lifetime subscription, I stopped paying for it aeons ago. None of the new features are compelling enough yet for me to want to start paying a monthly fee again.

December 10, 2006

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:

http://www.macintouch.com/readerreports/idvd/topic4162.html

And here’s what I wrote (found on that page as well):

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.

Therefore, decreasing the nice value of iDVD (and sub-processes) really didn’t help either (although I tried this, too).

I’m still waiting many hours for some DVD images to be burned, so I might poke around with this a little more…

About December 2006

This page contains all entries posted to JeffJournal in December 2006. They are listed from oldest to newest.

November 2006 is the previous archive.

January 2007 is the next archive.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.34