[RELEASE] iPhoto Plugin Addon for XBMC

I'm not sure why, but on lines 326629, 326665, and 326701 of your XML file it's got the keys "OriginalType" and "ImageType" set to a value of "^@^@^@^@" (four ctrl-@ characters). This is causing the expat parser to choke because they are invalid characters in XML. When I remove these key/value pairs, the file parses fine.

All three instances of the keys are for movies in a folder entitled "iMovieSpeedConversion". Is that perhaps some 3rd-party conversion utility you're using that is putting junk in the metadata of its output files?

I can likely fix this by handling the exception and ignoring it, but I'd like to figure out first how those characters got there.

-j

jingai Wrote:I'm not sure why, but on lines 326629, 326665, and 326701 of your XML file it's got the keys "OriginalType" and "ImageType" set to a value of "^@^@^@^@" (four ctrl-@ characters). This is causing the expat parser to choke because they are invalid characters in XML. When I remove these key/value pairs, the file parses fine.

All three instances of the keys are for movies in a folder entitled "iMovieSpeedConversion". Is that perhaps some 3rd-party conversion utility you're using that is putting junk in the metadata of its output files?

I can likely fix this by handling the exception and ignoring it, but I'd like to figure out first how those characters got there.

-j

Interesting. Not sure why that is in the iPhoto library. This directory does not exist anywhere outside the iPhoto container, therefore I can not ascertain the source of this or why it's metadata is constructed as such.

Following some basic logic on how iPhoto works... When it is directed to scan a pictures folder and import, iPhoto creates its own structure within the container that does not resemble the original location hierarchies. So this directory is/was created by iPhoto.

Secondly, if a user of iPhoto chooses to setup iPhoto with a reference library, one in which the original photos are NOT copied into the iPhoto Container, then the xml file will reference the external directory structure source where the photos actually reside.

So in this case, to see the directory reference contained with the ...\Masters\ folder within the container indicates iPhoto pulled this movies into the library and created the directory structure we see, as well as the metadata. It must not have been able to interpret metadata and reacted as it did.

I would suggest insulating the plugin from this behavior to be safe...

Here is a video spec report of the actual file and its metadata...

***** First Analyzed File Results *****

*** General Parameters ***
- Name: IMG_0915.mov
- Container: MOV - QuickTime
- Creation Date: 2011-07-24 1:09:20 PM
- Size: 24.9 MiB
- Duration: 0:00:06
- Bitrate: 36.4 Mbps
- Encoding Library: Apple QuickTime
- Encoding Application: 4.3.3

*** Video Track Parameters ***
- Format: Apple Intermediate Codec
- Size: 23.8 MiB (96%)
- FourCC: icod
- Track number(s): 0
- Bitrate: Max.: Undefined
Average: 34.9 Mbps
Min.: Undefined
- Frame rate (fps): Max.: 54.545
Average: 29.694
Min.: 10.000
- Bitrate mode: Variable
- Encoding profile: Undefined
- Resolution: Undefined
- Width (Pixel number): 1280
- Height (Pixel number): 720
- Pixel Aspect Ratio: Undefined
- Display aspect ratio: 16:9
- Chroma subsampling format: Undefined
- TV standard: Undefined
- Interlacing: Undefined
- Encoding library: Undefined
- Additional Parameters: Bits/(Pixel*Frame) ratio: 1.275

*** Audio Track(s) Parameters ***
- Format: Uncompressed PCM
- Size: 1.05 MiB (4%)
- FourCC: 0x1
- Number(s) and language(s): 2: English
- Details: 16-bit, little endian, signed linear PCM
- Profile: Undefined
- Bitrate: 1 536 Kbps
- Bitrate mode: Constant
- Resolution: 16 bits
- Rate: 48.0 KHz
- Channel(s): 2 (stereo)
- Position: Undefined
- Encoding Library: Undefined
- Additional Parameters: Not available

*** Miscellaneous ***
- Subtitle(s): No Subtitle
- Metadata: Album: Undefined
Part number: Undefined
Track name: Undefined
Track name number: Undefined
Performer: Undefined
Screenplayer/Writer: Undefined
Genre: Undefined
Encoded date: UTC 2011-10-09 18:33:39
Comment: Undefined
Album artist: Undefined
Grouping: Undefined
Copyright: Undefined

Toxic Man Wrote:Interesting. Not sure why that is in the iPhoto library. This directory does not exist anywhere outside the iPhoto container, therefore I can not ascertain the source of this or why it's metadata is constructed as such.

Following some basic logic on how iPhoto works... When it is directed to scan a pictures folder and import, iPhoto creates its own structure within the container that does not resemble the original location hierarchies. So this directory is/was created by iPhoto.

Secondly, if a user of iPhoto chooses to setup iPhoto with a reference library, one in which the original photos are NOT copied into the iPhoto Container, then the xml file will reference the external directory structure source where the photos actually reside.

So in this case, to see the directory reference contained with the ...\Masters\ folder within the container indicates iPhoto pulled this movies into the library and created the directory structure we see, as well as the metadata. It must not have been able to interpret metadata and reacted as it did.

Yes, I understand how it all works, but I've never seen such a sub-directory created so I am not sure how it came to be, however I don't think iPhoto created it; at least, not directly. It does say *iMovie*SpeedConversion, after all.

Just a wild guess based on the directory name alone.. perhaps iMovie adjusted the frame rate? Or maybe you used the Speed effect/tool/thing it has? (Sorry, haven't used iMovie in a while) I could be reading it wrong, but the media info you posted seemed to indicate that the frame rate of the source file was variable.

Do you happen to know what kind of device created the source movie? Is it a file straight out of a camera (no post processing etc) or did you transcode it first? If it was transcoded, what utility did you use?

Toxic Man Wrote:I would suggest insulating the plugin from this behavior to be safe...

It's actually less safe since I'd be ignoring all invalid characters (specifically, I'd be ignoring that exception from the parser), which may cause other unexpected behavior. Honestly, failing as it is currently is The Right Thing to do given that CTRL-@ is definitely not a valid character. I'll obviously work through the issue with you to resolution, but I don't want to jump to straight to kludging the source to work around this.

And just curious: have you tried simply deleting the movies in question from iPhoto and re-adding them?

-j

jingai Wrote:Do you happen to know what kind of device created the source movie? Is it a file straight out of a camera (no post processing etc) or did you transcode it first? If it was transcoded, what utility did you use?



It's actually less safe since I'd be ignoring all invalid characters (specifically, I'd be ignoring that exception from the parser), which may cause other unexpected behavior. Honestly, failing as it is currently is The Right Thing to do given that CTRL-@ is definitely not a valid character. I'll obviously work through the issue with you to resolution, but I don't want to jump to straight to kludging the source to work around this.

And just curious: have you tried simply deleting the movies in question from iPhoto and re-adding them?

-j

I have not tried to remove and re-add the file. The file originated from an iPhone 4 camera and was not transcoded. It was added to my library through a direct import into iPhoto, thus no other interpretations on the offending file. I can not explain the folder structure or how/why it resulted... or why iMovie has anything to do with this at all...

I will move the file out of the container and re-import it and see what happens.

Will do so this evening and post results...

Thanks....

Toxic Man Wrote:I have not tried to remove and re-add the file. The file originated from an iPhone 4 camera and was not transcoded. It was added to my library through a direct import into iPhoto, thus no other interpretations on the offending file. I can not explain the folder structure or how/why it resulted... or why iMovie has anything to do with this at all...

I can only guess that iPhoto calls functions from a library that is part of iMovie to deal with video files.

I confess I've never used iPhoto for videos at all and honestly never understood why Apple added support for videos in a photo editing application either.. but that's neither here nor there.

What surprises me is that you're the first person to report this. I'm fairly positive my father imports his iPhone videos this way too, yet it works on his installation.

I'll take a short video with my phone and try importing it via iPhoto tonight to see if I get the same results.

Toxic Man Wrote:I will move the file out of the container and re-import it and see what happens.

I'm not so sure that will change anything since it sounds like the original file (before iPhoto transcoded it) is lost for good. You can try it, though.

You might also try importing a new video from your phone and see if you get different results. Just check the XML file it generates after import and look for those junk characters on the entries for the new movie.

If iPhoto does this for every iPhone/iPod video imported, I'll definitely add a workaround in the add-on to deal with it, but I'd like to first verify there isn't some setting (either in iPhoto or on the phone) that might be causing it.

-j

I have a lot of imported iPhone video, and this appears to be the only one affected. I don't have the xml file open at the moment, but I think all three errors reference this same file. When I search my iPhoto library for the file name, two instances appear and neither the thumb nail or the video original is contained in the directory referenced in the xml file.

I'm going to delete that directory (don't care if I lose the file anyway) and re-run the plug update and see what happens...

Will post back shortly...

Toxic Man Wrote:I have a lot of imported iPhone video, and this appears to be the only one affected. I don't have the xml file open at the moment, but I think all three errors reference this same file. When I search my iPhoto library for the file name, two instances appear and neither the thumb nail or the video original is contained in the directory referenced in the xml file.

That's likely the problem then -- either the import was cancelled or it just plain failed. iPhoto didn't handle the error condition properly, and filled those keys with garbage values because it couldn't parse the original video. Just a guess

Toxic Man Wrote:I'm going to delete that directory (don't care if I lose the file anyway) and re-run the plug update and see what happens...

It's still not likely to work since those entries exist in the XML. If the affected assets don't appear in the iPhoto GUI so you can delete them, you'll probably need to manually remove the lines from the <dict> to </dict> for each affected asset. Be certain to quit iPhoto before you do this. And be careful which text editor you choose to use so as to not mess up any unicode characters and line endings. VI(m) I know for certain works. Not sure about TextEdit and other Mac editors though. Definitely make a backup of the file if you're not sure.

If you're not comfortable doing it, I can do it for you. You'd need to quit iPhoto, send me the current XML file, and I'll send it back to you, minus the corrupt assets. You shouldn't start iPhoto again until I get the new XML to you, but I'm at the computer tonight probably until around 9PM EST so I'll have it back to you quickly if you want to do this.

-j

jingai Wrote:If you're not comfortable doing it, I can do it for you. You'd need to quit iPhoto, send me the current XML file, and I'll send it back to you, minus the corrupt assets. You shouldn't start iPhoto again until I get the new XML to you, but I'm at the computer tonight probably until around 9PM EST so I'll have it back to you quickly if you want to do this.

-j

You have the latest and current. Please edit and send back, that would be greatly appreciated...

Toxic Man Wrote:You have the latest and current. Please edit and send back, that would be greatly appreciated...

If you're certain, I'll do so.

Just so you know, the affected files are:

IMG_0915.mov
IMG_0927.mov
IMG_0929.mov

I'm going to guess given the filenames that they were probably all in the same import session. I figured I'd list them out for you though in case any of them are important to you.

You'll have a PM shortly with a link to the edited file. I can't really test it, so if it doesn't load in iPhoto, just let me know.

-j

very much appreciated. I know all three of those files...
and all three are in another directory, and appear fine in the GUI. Will of course backup my xml file first!