I just “purchased” 13 free TV episodes from iTunes on my Mac. I don’t want to watch them on the Mac, but I find it easier to browse on the big screen and click with the mouse than to use iOS or that sharp aluminum remote. I just wanted to get them into my “queue” for easy viewing later.
But iTunes insists on downloading them, multiple resolutions for each episode, and I can’t figure out how to make it stop. I’ve tried pausing the downloads and deleting them. I’ve unchecked “Always check for available downloads” in the preferences. I’ve deleted the temporary files in the Finder and restarted iTunes. No matter what I do, iTunes keeps restarting the downloads.
As far as I can remember, iTunes has always worked this way. The only “solution” seems to be to let it finish downloading and then delete the videos. I’d rather not fill up my SSD, waste bandwidth, and use up my Comcast quota.
Iljitsch van Beijnum:
The reason that the 1080p versions of the iTunes Store videos can be a good deal better without doubling the file size—or worse—can be found in the tech specs of the new AppleTV and the new iPad. The AppleTV now supports H.264 compression for 1920x1080 resolution video at 30 frames per second using High or Main Profile up to level 4.0, the iPad and the iPhone 4S the same up to level 4.1. The profile indicates what kind of decompression algorithms the H.264 decoder has on board—the "High" profile obviously has some tricks up its sleeve that the "Main" or "Baseline" profiles known to previous devices don’t support. The level value indicates how many blocks or bits per second a device can handle.
In my experience, the old iTunes “HD” videos were heavily compressed and looked only slightly better than DVD-quality. The new 1080p videos are a welcome improvement, but it seems that they don’t compare favorably with cable/satellite, much less Blu-ray.
I’m still not really sold on Apple TV. On the one hand, the selection is getting better. Apple no longer requires you to store and back up your own purchases. With three versions of each video, at increasingly higher resolutions, that was not very practical. Now you can just re-download from iCloud as needed.
On the other hand, TV shows are no longer rentable. If I’m going to buy, why lock myself into lower quality and DRM. It would make sense if I wanted to watch on iOS devices, but I don’t. And iTunes is still not very nice for browsing or searching; it has the wonderful column browser but actively tries to prevent you from using it.
It would be interesting if it could be an alternative to cable, but forces outside Apple’s control block that. Basic cable is almost free for me, in the sense that Comcast would raise my Internet rate by a corresponding amount if I were to unsubscribe from video. I pretty much only get a higher cable package to see NBA games. Apple TV now offers NBA league pass, but during the trial period I found that it was unreliable, the video quality was awful, and blackouts meant that nearly all the games I wanted to see were unavailable.
In short, Apple TV keeps getting better, but I don’t think it’s broken out of hobby status.
Update (2012-03-14): A follow-up article:
I was surprised to see how close the iTunes 1080p download comes to Blu-ray, considering that it’s only a fraction of the file size. And let’s be honest: there are lots of Blu-ray titles that look much worse than this iTunes download. But despite an impressive effort by Apple, Blu-ray still reigns king when it comes to image quality. And unlike iTunes titles, BRDs can have uncompressed multi-channel audio, multiple audio language options, and special features. Am I being greedy in wanting both good-looking downloads for convenience, as well as buy-once-play-anywhere Blu-ray discs of my all-time favorite movies?
The test screen was only 23 inches, and of course the photos don’t capture what movement looks like.
Update (2012-03-20): John Siracusa reviews the Apple TV 3. He doesn’t like the remote, either.
Apple TV iTunes iTunes Store
Jonathan Bennett (via Casey Johnston):
Yesterday Apple launched iPhoto, its photo management app, for the iPad and iPhone… and we’re rather pleased to find they’re the latest to switch to OpenStreetMap.
[…]
The OSM data that Apple is using is rather old (start of April 2010) so don’t expect to see your latest and greatest updates on there. It’s also missing the necessary credit to OpenStreetMap’s contributors; we look forward to working with Apple to get that on there.
Not surprising that Apple is moving away from Google Maps, but I didn’t expect them to go with OpenStreetMap. I love the idea of the project, and the maps sometimes have interesting markings that Google is missing, but they just don’t look very good.
Hamish Sanderson (via
Clark Goble):
Apple declared the Carbon Apple Event Manager a legacy API in Mac OS X 10.6, advising it not be used for new development.
As of Mac OS X 10.7, the low-level Cocoa API (NSAppleEventDescriptor) still lacks essential functionality (e.g. the ability to send Apple events) while the high-level Cocoa API (Scripting Bridge) is too flawed and limited to be a viable foundation for an appscript-style wrapper.
Update (2012-03-09): Jonathan Rentzsch notes the Apple events APIs are not actually deprecated. This is true, however, the documentation for them is no longer searchable on Apple’s main site. It’s now in the legacy section of the developer library, which says:
The Mac OS X Developer Library — Legacy contains documents that are not applicable for current product development. Some of these documents describe older programming techniques that are no longer recommended. Other documents describe older features, interfaces, and programming techniques that are no longer supported. This information is available to help you maintain and update older code bases.
Whenever you view the documentation, you get a yellow pop-up that says:
Important: The information in this document is obsolete and should not be used for new development.
Update 2: AppleScript engineer Christopher Nebel (via Kevin Walzer):
Practical upshot: use the Objective-C APIs if you can; they’re a lot simpler to use if you’re already working in Objective-C. If they don’t do what you need (or if you’re using straight C for some reason), feel free to use the old-school AEM and OSA directly; there are no plans to remove them.
Kirk McElhearn:
As you may know, when you sync an iPod, you can have iTunes automatically convert your music files to a lower bit rate, so you can save space on a portable device. Previously, the only choice you had was 128 kbps. But iTunes 10.6 offers three choices: 128, 192 and 256 kbps.
The auto-conversion feature was originally restricted to iPod shuffles. Now, I use it to fit almost my entire music library onto an iPhone.
DreamHost:
The “Enhanced Security” option is our best solution for this. Although not a proper “jail” it will lock out all users from accessing your user’s home directory. If you do not share data between your users, this should be enabled for all of your FTP/SSH users.
I wasn’t aware of this option, having created my users long ago. There seems to be little reason not to enable it. It’s easy to accidentally end up with folders in your home directory that are world writable.
Mark Dalrymple:
Timing how long a block of code takes is a useful tool. Maybe you’re choosing between two different calls that do similar things and you’re wondering which one is faster. If one is faster, is it faster-enough to make any difference? The usual techniques involve using a profiler like Instruments, or calling a time function like gettimeofday() before and after your code and calculating the delta. Those of us on mach-based systems like iOS and OS X can use mach_absolute_time(), which is the finest-grained timepiece available on the system.
Instruments has its place, but I often prefer to the low-tech approach of adding logging and timing code directly to my app or unit tests. You can leave logging on while using the app normally, measure things on other people’s Macs, and keep a record of everything in version control.
