Over the holiday break I ripped and encoded our DVD collection such that we could easily play our movies on various devices ranging from UPnP clients such as a Samsung BD-C5500 Blu-Ray palyer and PS3 to a set of Apple devices. Getting the videos loaded into our iTunes library was key to sharing the videos with the Apple devices. Although I was able to easily add most of the videos to the iTunes library, some files that were encoded via the exact same process wouldn’t load. The .mp4 files played fine via QuickTime. Initially, as a workaround, I ripped and encoded the problem videos over again and was able to add them to the library. But I hadn’t figured out the root cause of the issue.
Recently, while working on another home project, I ran into the issue again and finally tackled the problem.
More recently, while setting up an EyeTV One dongle and the associated EyeTV app on our iMac, I ran into the same problem.
In this case, the EyeTV software records .mpg files from over the air (OTA) digital broadcasts. Whenever a recording finishes, a custom AppleScript calls the HandBrakeCLI app to transcode the .mpg file to .mp4 with H.264 encoding. The script then attempts to add the .mp4 file to the iTunes library. Lo and behold, the add step would fail with the same symptoms as when I was attempting to add some of the problem movie .mp4 files to iTunes.
Since it was important to me to automate the post recording steps, I dug into the issue with more earnest. Since I really wanted to automate this process, I couldn’t revert to the manual workaround I used earlier. Googling a bit, I found that many people sought help for this issue on various forums, but the responses were mostly along the lines of “install such and such an app to reprocess your files”. I didn’t want to add yet more bulky tools to the mix. So let the problem sit for a day and revisited it the next evening.
While looking at the problem files in a Terminal window, I noticed that none of the files had the “@” character at the end of their file permissions:
drwxr-xr-x 2 ckamps familys 4096 Jan 22 12:44 .
drwxrwxrwx 6 ckamps familys 4096 Jan 16 11:15 ..
-rw-r--r-- 1 ckamps familys 21508 Jan 22 10:13 .DS_Store
-rw-r--r-- 1 ckamps familys 1821609775 Jan 20 07:54 Frontline - Are We Safer?.mp4
-rw-r--r-- 1 ckamps familys 837107996 Jan 19 21:18 Railroad Empire.mp4
-rw-r--r-- 1 ckamps familys 1661233237 Jan 22 10:05 Rick Steves' Europe - Germany's Romantic Rhine and Rothenburg.mp4
-rw-r--r-- 1 ckamps familys 1203380817 Jan 22 10:05 Storm Stories.mp4
-rw-r--r-- 1 ckamps admin 1484539608 Jan 21 20:36 The Mentalist - Bloodhounds.mp4
-rw-r--r-- 1 ckamps familys 944261811 Jan 19 21:17 The Simpsons - The Debarted.mp4
-rw-r--r-- 1 ckamps familys 2224240290 Jan 19 21:17 Theodore Roosevelt_ A Cowboy's Ride to the White House.mp4
While the movies from DVDs has the “@” symbol:
-rw-r--r--@ 1 ckamps familys 1677303189 Jan 16 19:45 The Manchurian Candidate - Remake.mp4
-rw-r--r--@ 1 ckamps familys 1879367371 Jan 16 19:55 The Manchurian Candidate.mp4
-rw-r--r--@ 1 ckamps familys 1709551613 Jan 16 20:04 The Matrix Reloaded.mp4
-rw-r--r--@ 1 ckamps familys 1646588914 Jan 16 20:11 The Motorcyle Diaries.mp4
-rw-r--r--@ 1 ckamps familys 1262475482 Jan 16 20:18 The Polar Express.mp4
-rw-r--r--@ 1 ckamps familys 1203713603 Jan 16 20:24 The Spiderwick Chronicles.mp4
-rw-r--r--@ 1 ckamps familys 1507177828 Jan 16 20:34 The Terminator.mp4
Digging further, I found that the “@” represents the presence of extended attributes. Using the xattr(1) command, one can display and manipulate this list of attributes:
imac:movies ckamps$ xattr -l Warren*com.apple.FinderInfo:
00000000 4D 34 56 20 68 6F 6F 6B 00 00 00 00 00 00 00 00 |M4V hook........|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
Aha! Could the absence of the “MV4 ” attribute cause iTunes to not recognize the file type when performing an add operation? Yes, this seemed to be the case. I manually set the attribute and was able to manually add the problem files into the iTunes library.
$ ls -al
-rw-r--r--@ 1 ckamps familys 1821609775 Jan 20 07:54 Frontline - Are We Safer?.mp4
-rw-r--r--@ 1 ckamps familys 837107996 Jan 19 21:18 Railroad Empire.mp4
-rw-r--r--@ 1 ckamps familys 1661233237 Jan 22 10:05 Rick Steves' Europe - Germany's Romantic Rhine and Rothenburg.mp4
-rw-r--r--@ 1 ckamps familys 1203380817 Jan 22 10:05 Storm Stories.mp4
-rw-r--r--@ 1 ckamps admin 1484539608 Jan 21 20:36 The Mentalist - Bloodhounds.mp4
-rw-r--r--@ 1 ckamps familys 944261811 Jan 19 21:17 The Simpsons - The Debarted.mp4
-rw-r--r--@ 1 ckamps familys 2224240290 Jan 19 21:17 Theodore Roosevelt_ A Cowboy's Ride to the White House.mp4
Since in my case I wanted to force the setting of this attribute in an AppleScript, I found that the following command does the trick:
OK, well enough, but how come the extended attribute wasn’t present on the problem files? My theory is that in the case of my manual ripping and encoding of DVDs, the use of the MetaX tool to add meta-data to the files (e.g. chapters, descriptions, etc) resulted in the addition of the appropriate extended attribute. The few problem files I encountered in the manual ripping and encoding scenario was probably due to something else I did with these files apart from ripping and using MetaX.
In the case of my AppleScript triggered by EyeTV, only the HandBrakeCLI transcoding tool was used. Since MetaX is not used in that case, I gather that’s why I wasn’t seeing the extended attribute at all as a result of that process.
Anyway, this problem was one of the key hurdles in crafting an AppleScript to automate the addition of newly recorded shows to our iTunes library. I’m pretty pleased that it has been addressed and that I can post this entry to help out other people that encounter the same situation.