Comskip Support Forum

I learned at the BTV forum that BTV while recording allocates 4MBytes of space ahead of where video is written in the file. This implies that the last 4MByte of the recorded file at any point in time is junk.
I have currently not implemented a way to stay 4MByte way from the end of the file during livetv so the solutions described above MAY help you but it is not guaranteed.

In case anyone still cares, I tried Comskip with the new version 4.5 of BeyondTV. Unfortunately, it doesn't appear that anything has changed and the "live" function still doesn't work with BTV 4.5. Version 4.2 is the last version that this works with.

I made build 62 that implements a possible solution to this.

Set
live_tv_retries=8
standoff=8000000
in comskip.ini

standoff is the amount of bytes counting from end of file NOT to read untill the recording is finished

Its only implemented for mpeg PS and TS recordings, not for DVR-MS, sorry.

I did a brief test last night on several shows. I think it's working well! I didn't see any retries when it started. This was on a PC with a Hauppauge WinTV- PVR-150 card. When I get a chance, I'll try it out on my main system which also has HDTV tuners.

THANKS ERIK!!!

PS Does BeyondTV even support any tuners that record directly to DVR-MS?

Darn. Looks like there is still a problem. I think Comskip is still getting to the end of the file and reading junk. For my SD recordings, if I start up Comskip early, commercial detection is very poor. If I wait until late in the show, it detects well. I tried starting it half way through one long show where detection was good at the beginning and poor at the end, indicating that Comskip caught up at some point. It's working okay for HDTV recordings, primarily because my CPU isn't fast enough to keep up. What would changing the standoff value do?

If detection is bad during the show and always gets goor at the end the the backof works.
If comskip does never finish before the end of the show is transmitted backof works.
Possibly the simplified live_tv algorithm needs some improvement

Actually, detection is good then gets bad. If I start recording a show and start Comskip immediately, detection is bad throughout. If I start recording a 60 minute show and start Comskip 20-30 minutes into it, detection is good for the first half but bad during the last half, presumably when Comskip has caught up to the end. I've verified this several times.

I never do see the 'auto retries'. My suspicion is that the standoff is not going far enough back to get out of the junk at the end. In other words, lets say that there is a moving 30 seconds of junk, but the standoff only goes back 20 seconds. So if Comskip catches up, it is only seeing junk.

could you try to double standoff size?

Unfortunately, it's not working. I tried 16000000, 32000000, and even added another zero for 320000000. If I start Comskip five minutes after the program starts recording, it will detect the first commercial block at the most, then nothing after that.

Please set verbose=11 and mail me the log file.

Files are on their way. Unfortunately, there are 4 "standoff" entries at the beginning then everything else is "Read only 0 bytes". I forgot that verbose=10 didn't show this. My initial success must have been due to a slower PC that didn't catch up to the end.

Could you retest with
live_tv_retries=16
or even higher?

I'll give it a try in a few hours, but I don't see why that setting would do any good. It's not hitting the max retries now. With the current settings, the retries are 5 or 6. If it hit 8, it would stop prematurely, but it's not.

If is has waited half the amount of set retries it assumes it has to read to the end and wait there till finished
Don't ask why but that is how I implemented it.......
If waiting 4 seconds for to fill 4MByte is too little you need 8 or 16 seconds, meaning retries set to 16 or 32.

However you did it, setting the retries to 16 seemed to work. I'm now seeing all "standoff" entries with the highest being:
Sleep due to standoff, retries = 5
The files for the latest test are on their way in email. It worked very well! Standoff 8000000 and Retries 16. Are there any other permutations you'd like me to check?