question about Timing.Info ADS

[johnsonx42]

I suppose in absence of a fix for this, I guess it might help if I run comskip in parallelprocessing rather than postprocessing. that way comskip should be done with the file not too long after the recording finishes.

edit: which I have now done; I just renamed PostProcessing.bat to ParallelProcessing.bat. I used to run comskip in parallel with GB-PVR (using the in-built support for comksip), and that always worked fine so I guess it ought to do the same in NPVR ParallelProcessing.bat.

[johnsonx42]

It turns out running comskip in parallel isn't such a great idea after all. Running against an in-progress recording, comskip processes frames until it catches up to the end of the file, then waits for a second or two for more data to hit the file, then processes frames again. On my particular hardware, this is just enough to make the processor speed up to 2.4ghz, slow down to 1ghz, and then speed up again to 2.4ghz over and over every couple of seconds. If we're watching a recording while this is happening, it's enough to produce a slight but noticable hitch in playback as it adjusts to the changing CPU speed.

Aside from that, it worked great; comskip would finish with a file just a minute or two after the recording finished, so NPVR would read the Timing.Info right away; having the commercials marked right away was a nice bonus as well.

I'm not real happy with any of my options here. It seems easiest to go back to running comskip in postprocessing, and just hope timeline issues don't crop up too often.

Sub, any chance you have a change in the works to allow NPVR to read the timing.info even while comskip has the file open?