| Issue 74: | Atomic Parsley crash - KERN_PROTECTION_FAILURE | |
| 1 person starred this issue and may be notified of changes. | Back to list |
What steps will reproduce the problem? 1. Settings: Quicktime (H.264, 3mbps), No import to itunes, no metadata 2. Download partial recording of show (15 min) 3. Download / encode at same time What is the expected output? What do you see instead? Atomic Parsley crashes and leaves mp4 file unusable What version of the product are you using? On what operating system? Latest 1.7, Leopard Please provide any additional information below. I'm able to download other shows successfully. I stopped this show partially through Tivo because I only wanted the 15 minutes, not sure if this is the issue here. I can get log files if they are needed.
Jan 9, 2009
Project Member
#1
yoav.yer...@gmail.com
Status:
Accepted
Jan 9, 2009
I've attached the Atomic Parsley crash report. I'm rerunning the job and I'll post a link to the mp4 file for download. Also, I'll watch the log in /tmp/iTivo-<username>/ for anything interesting. Thanks!
Jan 9, 2009
yeah only thing I can tell from that log is that it tried to access an invalid memory location (probably dereference a null pointer) :(. Under 'Advanced' you can tell it to 'download first, then encode', which will let you look at the file pieces as they come down. I'm wondering if it's just a bad source file, or if mencoder is creating a bad movie file (which I suppose we could also narrow down by selecting Handbrake AppleTV as the encoder or something). I have a nagging feeling that this is not going to be fixable :(
Jan 9, 2009
This tail of the iTivo.log might help. It looks like it is stops downloading at a point and then restarts, leaving an incomplete mp4 file on the disk. It seems to happen at the same point every time, around 706mb, producing a 227mb mp4 file. This is only a 15 minute HD recording and it is reported as 2gb on disk. I did a download first, then encode and that also failed. It just restarted the download again.
Jan 9, 2009
Sadly no :( The 'restarting' problem is a known behavior. Basically, when you have a truncated show, the tivo claims the show is some size (say 3Gigs) but then terminates the transfer early. iTiVo doesn't know if the termination was due to a problem or correct behavior, so it retries (each time it's a little more forgiving on the retry.. by the 4th retry it accepts any size file). So those retries are to be expected on short files. However, Atomic Parsley is not supposed to crash on those...
Jan 9, 2009
This one failed a bit more gracefully in "download first, then encode" mode and restarted on my laptop. It found the end at 1050, but thought it was supposed to go to 2060. I guess I'll let it keep running in "download first, then encode" mode so it hits the 4th try. Thanks!
Jan 9, 2009
When I get home I'll try doing a partial recording and do a non-staged download to see if it also crashes AtomicParsley for me... Should get to it later tonight..
Jan 9, 2009
I let it run for a really long time using the "download, then encode" and still got the AtomicParsley error. I'm not sure the encode even finished: 2009-01-09 16:41:55 mencoder timeout: 0 download:1 timeRemaining: 9 timeOn:606.3 currentPercent: 67 2009-01-09 16:41:56 mencoder timeout: 0 download:1 timeRemaining: 9 timeOn:606.6 currentPercent: 67 2009-01-09 16:41:56 mencoder timeout: 0 download:1 timeRemaining: 9 timeOn:606.8 currentPercent: 67 2009-01-09 16:41:57 mencoder timeout: 0 download:1 timeRemaining: 9 timeOn:607.1 currentPercent: 67 2009-01-09 16:41:57 mencoder timeout: 0 download:1 timeRemaining: 9 timeOn:607.4 currentPercent: 67 2009-01-09 16:41:58 mencoder timeout: 0 download:1 timeRemaining: 9 timeOn:607.7 currentPercent: 67 2009-01-09 16:41:59 Download completed 2009-01-09 16:42:00 killed : 2009-01-09 16:42:00 perl /Applications/iTiVo.app/Contents/Resources/GetExtraInfo.pl 192.168.2.2 3646149622 1097139 2009-01-09 16:42:06 Moving to subdir 2009-01-09 16:42:06 ERROR: Failing to output correct string 2009-01-09 16:42:06 Result: 2009-01-09 16:42:06 Making Atomic Parsley metadata 2009-01-09 16:42:06 ERROR: Failing to output correct string 2009-01-09 16:46:25 perl /Applications/iTiVo.app/Contents/Resources/ParseXML.pl 192.168.2.2 3646149622 2009-01-09 16:46:29 starting download 2009-01-09 16:46:29 starting queue download... 2009-01-09 17:01:25 perl /Applications/iTiVo.app/Contents/Resources/ParseXML.pl 192.168.2.2 3646149622 2009-01-09 17:01:29 starting download 2009-01-09 17:01:29 starting queue download... 2009-01-09 17:16:25 perl /Applications/iTiVo.app/Contents/Resources/ParseXML.pl 192.168.2.2 3646149622 2009-01-09 17:16:30 starting download 2009-01-09 17:16:30 starting queue download... 2009-01-09 17:31:25 perl /Applications/iTiVo.app/Contents/Resources/ParseXML.pl 192.168.2.2 3646149622 2009-01-09 17:31:30 starting download 2009-01-09 17:31:30 starting queue download... 2009-01-09 17:46:25 perl /Applications/iTiVo.app/Contents/Resources/ParseXML.pl 192.168.2.2 3646149622 2009-01-09 17:46:33 starting download 2009-01-09 17:46:33 starting queue download... 2009-01-09 18:01:25 perl /Applications/iTiVo.app/Contents/Resources/ParseXML.pl 192.168.2.2 3646149622 2009-01-09 18:01:32 starting download 2009-01-09 18:01:32 starting queue download...
Jan 9, 2009
I had success doing a download with Handbrake encoding enabled with the Apple TV profile.
Jan 9, 2009
Yeah I'm at this point willing to hazard a strong guess that mencoder is generating a bad encode from your truncated movie. (and the bad encode is making AtomicParsley crash). If you have the energy, can you check if it's also a bad encode when you make a different h.264 format? (like, select the regular iPhone encoding and see what mencoder does). If it's still breaking, then I think we're down to 'mencoder has problems'. I really can't fix that unfortunately. If you select the 'decrypt' format, you'll have the original file that mencoder is trying to run on, and you can try and get in touch with the mencoder developers (mplayer) and see if they can fix it. Alternatively, if it's just one truncated file that's causing the issue, it might just be easier to wait and see if future mencoder releases fix it...
Jan 10, 2009
The iPhone hi-res encoding worked for me. It did two passes, but completed on the 2nd pass and had no AtomicParsley error. Looks like a mencoder issue with the Quicktime profile like you suspected.
Apr 13, 2009
I think this bug is unfixable to me. so marking won't fix and moving on. Sorry and hope it was a one-off that you're not still seeing. (although with the newer codebase you can turn off atomicparsley if it's still crashing for you). Marking as 'wontfix'
Status:
WontFix
|