essandess / etv-comskip

Commercial Marking and Skipping for EyeTV and iTunes Exports
GNU General Public License v2.0
55 stars 7 forks source link

Export stalls #19

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Record show
2. allow comskip to mark out commercials
3. do an export to MPEG4 or H.264

What is the expected output? What do you see instead?
About 50% of the time or more the export will stall out halfway through.  It 
appears to be still 
exporting but eyetv starts using almost no processor and must be force quit.  

What version of the product are you using? On what operating system?
The latest etv-comskip release with eyetv 3.1.1

Please provide any additional information below.

Original issue reported on code.google.com by smuss...@gmail.com on 16 Apr 2009 at 11:17

GoogleCodeExporter commented 8 years ago
I've never once done an export with EyeTV, so I don't have any experience with 
this.
However, why would you assume that this has anything at all to do with 
etvcomskip?

It seems like it's an EyeTV bug, as all etvcomskip does is add commercial 
markers.
You can do that manually just as well.  Is this somehow something specific to 
shows marked with etvcomskip and not manually?

Original comment by jon.chri...@gmail.com on 17 Apr 2009 at 1:40

GoogleCodeExporter commented 8 years ago
I can confirm this issue and add a bit more detail to it.  I uninstalled PyeTV 
and EyeTV along with this.  
Reinstalled everything and the issue persisted.  Then I removed PyeTV and the 
issue persisted.  Then, when I 
uninstalled comskip the issue was resolved.  smussell is right that it is not 
every recording that will do this 
but it is at least half of them.  I tried reinstalling comskip and the issue 
recurred.

I've had it uninstalled for over a month now and the issue has not once 
recurred. Since neither this nor EyeTV 
has been updated since then I've had no reason to try again.  From what I read 
over at the Elgato forums, this 
issue did start with the latest update to EyeTV, but the app without Comskip 
works as expected with all export 
functions and I'm thinking it has something to do with a small but important 
change to the EyeTV code that is 
now causing problems for this plugin.  I hope this helps.

Original comment by ghead...@gmail.com on 9 May 2009 at 11:42

GoogleCodeExporter commented 8 years ago
It is known that the applescript dictionary is broken in EyeTV 3.1.1; it affects
PyeTV when going into fullscreen mode, and from what I hear, makes PyeTV pretty
unusable with 3.1.1.  Unfortunately, there's nothing I can do about that; I 
just use
EyeTV 3.1.

Does this problem occur with EyeTV 3.1?  I'm still a bit perplexed by why 
etvcomskip
should cause a problem with EyeTV.  Is comskip still running when ETV tries to 
do the
export?  If not, then I really don't see how this can be related.

Original comment by jon.chri...@gmail.com on 10 May 2009 at 6:00

GoogleCodeExporter commented 8 years ago
i've encountered this problem too, with EyeTV 3.1 currently, and with 3.1.1 
before i
reverted back to 3.1 - exports to AppleTV stall more often than not. only 
forcequit
eyeTV & relaunch will allow me to export (same recording again, or other 
recordings).
 if 2 or more recordings are queued for export, the 2nd/3rd/etc recordings simply
remain queued after the 1st stalled.

however lately i've been checking my to-be-exported recording's commercial 
markers
(to remove pre & post roll junk, and to add markers that were missed by 
comskip),
compacting, removing all of the 'zero length' markers that remain, and then
exporting, *somewhat more* successfully but still not entirely successfully.

Original comment by techyd...@gmail.com on 22 May 2009 at 3:39

GoogleCodeExporter commented 8 years ago
Manually compacting the file (which removes the markers) seems to markedly 
improve
the reliability of the Exports.  I once saw a script for auto-compact.  Seems 
like
this could be run BEFORE they are auto-exported and we'd have a reasonable 
solution
to this problem.  

Original comment by spinespe...@gmail.com on 17 Sep 2009 at 12:25