ElGato Turbo.264 iPhone fails with commercial skip option

[GoogleCodeExporter]

What Version of iTiVo?
1.7.6

What Version of MacOS X?
10.4.11

What download format did you select?
ElGato Turbo.264 iPhone

What steps will reproduce the problem?
1. Select commercial skip option (did not select subtitles).
2. Select one show, then "Add Show to Queue".
3. Click "Download Now".

Please provide any additional information below.
Show is downloaded to the /tmp/iTiVo-<user>/ directory, then comskip does
its thing.  Next ElGato Turbo.264 application is launched, however encoding
does not occur.  Within a few seconds the process repeats by iTiVo
downloading the show again, followed by comskip (up to the number of
retries specified under advanced preferences).  It appears that Turbo.264
may not able to locate the input file for encoding.  Note that without the
commercial skip option selected, Turbo.264 works without a hitch.

Thanks for the great program!  I travel quite a bit and was considering a
SlingBox until I found iTiVo.  Now I don't have to worry about the (very
likely) possibility of hotel network congestion/problems resulting in a
waste of money on the SlingBox.

Original issue reported on code.google.com by ckoc...@gmail.com on 31 May 2009 at 4:50

[GoogleCodeExporter]

I'll see if I can figure out what's going on (I don't have the elgato device so
pretty dependent on other people helping me debug/fix it).   

  Does this happen for ALL downloads or just certain files?

  Can I get you to attach the contents of <user>/Library/Logs/iTiVo.log after a failure?

Original comment by yoav.yer...@gmail.com on 31 May 2009 at 4:34

• Changed state: Accepted

[GoogleCodeExporter]

I do understand that you don't have the ElGato device, and that you are not 
getting
paid for this work (though you really should set something up to permit
contributions, as others have pointed out).  I'm sure you're aware that your 
efforts
are very much appreciated by a large number of people!

As I do have the ElGato device, I am happy to try and assist you with debugging 
this
problem.

I tried a different show this morning in order to test whether it was just the 
one
show, and to provide you with a clean log.  The same problem occurred, so it 
would
seem that it isn't related to certain files.

After posting this defect last night, I did a bit more experimentation and 
managed to
capture a download that had made it through comskip and mencoder before it was
deleted.  I took that iTiVoDLPipe file and manually fed it to Turbo.264, which 
worked
fine.  So it doesn't seem to be a problem with the input file itself.  I also 
noted a
-208 error related to Turbo.264 in the iTiVo.log, did a Google search to see 
what I
might learn about it, and came across a thread in the TiVo Community Forum 
where you
were discussing a somewhat similar problem with another iTiVo user.  Seemed 
like the
answer in that case was related to timing, and making sure that Turbo.264 was 
already
running would resolve the problem.  I tried that, to no avail.

I should note that after checking out the encoded result of my manual feeding 
of the
comskip/mencoder file to Turbo.264, there was enough of an audio sync problem 
(even
though I did not select subtitles) that I would not enjoy viewing such shows.  
So
even if you get this resolved, I probably won't use the feature (unless I 
discover
that I am doing something incorrectly).  Nevertheless, I am happy to provide any
assistance that you desire.

Per your request, I'm attaching a zip archive of my iTiVo.log.  I did obscure 
the MAK
by replacing it with all zeros.

Oh, one more thing: I'm using an older Mac (G4 867MHz 1.5GB RAM), and wonder if 
that
might be a contributor if this turns out to be timing/performance related.  
With this
slower Mac the Turbo.264 USB dongle is an absolute necessity!

Original comment by ckoc...@gmail.com on 31 May 2009 at 6:48

Attachments:

• log.zip

[GoogleCodeExporter]

first, thanks for helping debug this.

  I'll answer the easy part first:  The audio/video sync issues is a common problem
that happens when the video is 'cut' first, then encoded (all the external 
encoders
have to do this.. only mencoder can cut AND re-encode in one pass, and even that
sometimes has issues).  So I think there will be no useful workaround for this
(unless mencoder internally adds support for elgato, or elgato allows using an 
edit
list as part of their re-encode).

  As to the main problem.  I'm gonna have to sit through the code and see if I can
figure out a reason why this would happen.  Nothing jumps to mind yet but 
hopefully
I'll get it.  I may ask you to test some stuff out for me if/when I do...

Original comment by yoav.yer...@gmail.com on 31 May 2009 at 7:42