Comskip Support Forum

I've been using the "live" setting (live_tv=1) in Comskip very successfully with BeyondTV recordings as they are in progress. All of a sudden, Comskip is terminating/finishing before the program has finished recording. I'm not certain, but I believe that this is directly related to upgrading from BTV 4.2 to 4.3. I noticed it on one of my PCs first, but wasn't sure why it was happening. When I upgraded my second PC with BTV 4.3 and the same behavior started happening, it seemed likely that it was the upgrade that was the common denominator.

I've moved some log files to the FTP server in the BTV4.3 folder. "A.log" is a log file from a currently recording program. "B.log" is when I restarted Comskip on the same program while it was still recording. It looks like Comskip is quitting prematurely after 5-15 mins (not sure exactly). Any ideas?

No usable info in the log file...

Does BTV 4.3 lock the recording file?
When it writes and it locks the file at the same time as Comskip wants to read the file Comskip may conclude after trying twice the recording is finished.
Can you try another bitrate? This may change the rithm in which BTV locks the file.

I've also posted a verbose log file (C-verbose.log) now, but that doesn't appear to help either. I was inaccurate about the timing. Comskip appears to finish as soon as it gets to the end of the file that is recording. So if I start Comskip on a file right after it starts recording, Comskip finishes in less than 1 minute. If I start it 10 mins in, it takes awhile longer to catch up.

I'm not sure how to detect whether BTV locks and unlocks a file. It appears to be locked. The only way I can tell is by trying to rename it, which fails. The file is hidden and read-only.

The problem is only happening with SD MPEG2 captures (Hauppauge PVR-150). I just tested and it did not happen with an HDTV capture (Kworld ATSC-110). Comskip never "catches up" to the end of an HDTV recording. It does "catch up" to the PVR-150.

Did you ask BTV if they changed something?
I did not change anything in this part of the code.

Erik,

I understand that Comskip didn't change. I don't think there is someone to ask at Snapstream about whether or not they changed something to screw up Comskip. Even if there was, they would say that BTV 4.3 works and that they're not responsible for how a 3rd party app responds to their changes.

I would really hate to lose this capability from Comskip. It saves a lot of time to have the commercial detection done shortly after the file is finished recording. How does Comskip determine whether or not the file is done recording?

Kerry

Comskip tries to read a certain amount of bytes from the recording.
If that fails (less or zero bytes) then Comskip waits 1 second and tries again.
If the read then succeeds Comskip continues. If that fails, Comskip assumes it has reached the end of the recording.
This approach is not very fail safe because if the recording utility locks the file while writing Comskip can try to read (after 1 second) at the same time as the recording utility writes. That is why I suggested to record at another bitrate, because this will change the rithm of writing.

I also could add a second retry......

There are a few reasons why I don't think it is a "locked from reading" problem.
1. Comskip runs until it reaches the "current time". If it was being locked out, it would stop before it got to the end, wouldn't it?
2. Because of this new problem, my script that runs VideoRedo is running early and VideoRedo is able to process the currently recording program.

I changed BTV 4.3 from "Best" quality to "Better" quality. It didn't have any effect. Comskip ended before the program was finished recording.

Since this is happening on two completely different PCs, I don't think it's just my problem. Can anyone else confirm this behavior?

I too have Beyond TV 4.3 installed. I have never attempted to run comskip livetv against any other version of Beyond TV, but seeing your post, I tried it against BTV 4.3 with the same results that you experienced. Once comskip caught up with the video record buffer it ended. I examined the log, but it didn't tell me much. The last entrys befor the stats was:

Finished scanning file. Starting to build Commercial List.

Not enough or too much logo's found (0.00), disabling the use of Logo detection
The last ar block wasn't closed. Now closing.

I would have thought I would see a log entry about delaying or retrying but maybe livetv parameter doesn't add anything special to the log?

Nothing is added to the log because its normal the end of the file is detected.
I will have to try another algorithm to detect live processing.
WIll take some days.
Do remind me it nothing happens within a week.

It doesn't help the general case, but Beyond TV, for a recording in progress, has a xml file that exists for as long as the recording is in progress. It is:
Recording-drive:\Recording-path\Recording-name.Recording-filetype.inprogress.xml and in addition, the recording has Hidden attribute while it is incomplete.

I made a small improvement in Comskip 0.79 build 45.
Could you test?

Sure.

Erik,

Bad news. .45 still ends prematurely.

Kerry

Did the recording always have the hidden attribute while recording?

I agree, it ended prematurely for me too. It is already rebuilding, already scanned and cut commercials at 10min into a half hour program. Yes, the recording still has the Hidden attribute.