Comskip troubles in 1.3.11

[ceandra]

I upgraded recently. I beleive my problems started upon upgrade, but not certain.

I am recording in dvr-ms, as I had trouble in prior version with TS. I am recording QAM channels. the particular cases tonight are with channel 13, which is CBS, in std def, as HD had issues with CBS.

When looking at NCIS (recorded 7 to 8) and Mentalist (8 to 9), there were almost no commercial breaks showing. Mentalist had a part of first commercial.

I have GBPVR set to use comskip, and comskip to make info available during show. It has worked great until Monday. On Sunday, superbowl comskip was just fine.

I have no parallelprocessing or postprocessing bat files active.

I am attaching the comskip files from the run during the recording. I then ran comskip manually (twice), and both time it stopped around 85-89% complete (got most commercials). Including those files as well. Finally, including all gbpvr logs from tonight.

I also changed early Sunday (or Saturday night) from Symantec AV to Macaffee. Howevver, taht change was before the superbowl. I doubt that was the issue.

Monday night program also showed no comskip results when we played a show back (also channel 13).

Could be something wrong in config after the changeover, either comskip or gbpvr. I did not change comskip program. Running 80.007, been fine for some time.

Thanks
Chuck

[ceandra]

PS:

After shows recorded, no Comskip was running. After I manually ran Comskip, it hung in the CMD window around 85-89%, stopped progressing at all. After waiting some time, I killed the cmd window.

Chuck

[erik]

Comskip will wait just before the end of a dvr-ms file for a LONG time because you may be processing liveTV and dvr-ms allocates huge buffers and then starts to fill them slowly.
If you don't want that behaviour set
dvrms_live_tv_retries=3

[ceandra]

Erik:

thanks for the reply. That probably explains the issue with stopping at 89% on manual, I did not realize Comskip treated manual and parallel the same (I guess it makes sense).

However, for the parallel processing, the failure was near teh beginning of the file (see the txt file, only start of one break). It also shows a bunch of bad stuff in the log. Not sure what is happening there. Comskip was NOT running after the show completed recording, and yet two of the shows had no commercial breaks, and the one used as example here had only the start of the first commercial break. This was not a case of comskip waiting, as the task manger no longer showed Comskip, and this was two hours after the first show completed.

I suspect it read to teh end of the file before something was written? Lots of "garbage" in the log file for the initial run.

Let me know if some other parameter must be changed.

Chuck

[ceandra]

Erik:

I still get no commercials (or maybe part of first one) on shows that are processed on the fly. Manual comskip later (and probably if it was in postprocessing) works. Could you take a look at the log in the "initial.zip" above and see if anything as obvious as my second problem was?

Thanks
Chuck

[ceandra]

Here is another similar log. Comskip will not work in parallel mode (no parallel processing.bat, but triggered by gbpvr). These are SD digital shows, stored as DVR-MS format.

Comskip starts to process, but then fails to move through the file. Postprocessing or manual processing is successful. I have Comskip making the data available during show enabled. However, two days later the file is not processed, and comskip is not running.

The processing (in log) seems to be progressing, and then I get many amny lines as follows:

p_peek[0]&0x80 != 0x80
undeclared stream[Id 0x0]

Then, at the end, closeout seems OK. BUt, only part of the first commercial is detected, if anything. If I then re-run Comskip after teh fact, all is well. Prior post has the re-run as well as the original on another show. THis post just has the failed COmskip log.

Chuck

[erik]

The processing (in log) seems to be progressing, and then I get many amny lines as follows:

p_peek[0]&0x80 != 0x80
undeclared stream[Id 0x0]

This means Comskip is processing the recording before it is actually written to the dvr-ms file.
You should increase the dvrms timeout and the dvrms standoff.

[ceandra]

Erik:

Thanks for the fast reply. I figured it was something like that. What are the names of these two parameters in the Comskip.ini file?

I see:
dvrmsstandoff=120000

I am not seeing anything immediately that looks like dvrms timeout.

How much should I increase the standoff? What parameter should I add, and what value, if I cannot find a timeout? I am looking in the log posted above, since I am not at my gbpvr screen right now.

Thanks
Chuck

[erik]

There are the defaults you should use when processing during liveTV
dvrms_live_tv_retries=300
dvrmsstandoff=120000
At very low bitrates the value 300 may have to be raised to 400 or even higher

[ceandra]

OK, I'll play with these. Looks like mine are both set to the defaults.

Thanks
Chuck