Timestamps are off for commercials

[dwalton22]

I submitted a bug for this but I'm curious if anyone else has run into this issue...

I'm seeing a problem with an episode of SouthPark (recorded with a PVR-150) where the timestamps of the commercial breaks are not being honored. SouthPark is a 30 minute show but I have sage set to record 2 minutes extra because sometimes the show starts a little late. For some reason this particular mpg file is 33 minutes and 14 seconds long. My guess is that the clock on my sage box was off at the beginning of the recording but did a NTP update before the show ended which corrected the clock and resulted in the recording being longer than the scheduled 32 minutes.

The weird thing is that if I play this mpg with WMP, winamp, etc they all see that there is 33 minutes and 14 seconds of video but when I play it with sage it appears to squeeze all of the video into the scheduled 32 minutes. The end result is that the commercial breaks as identified by ShowAnalyzer are not honored correctly. ShowAnalyzer says that the commercials breaks should be:

00:00 -> 03:40
13:19 -> 16:50
23:01 -> 25:17

These are the correct timestamps for the commercials when viewing the mpg with WMP, winamp, etc. If I watch the show via sagetv I see that sage reads the edl file from ShowAnalyzer and flags the corresponding parts of the show as commercials but the commercials are actually shown at the following timestamps:

00:00 -> 03:32
12:49 -> 16:13
22:09 -> 24:20

and the file stops playing by 31:59.

[ToxMox]

AFAIK Sage will determine the play length based on when the recording supposedly happened. It thinks the recording is 32 minutes long because that is how long it was scheduled for.
I don't know if Sage will help you with this issue since comskip is an unsupported 3rd party customization. If your clock is indeed getting that far off perhaps get a utility that synchronizes your clock every half hour to reduce the drag that can happen in a period of 24 hours and hopefully the difference will be so small that the comskips will seem accurate.

If it only happened with this one recording and your clock is usually accurate then I would just ignore it and move on IMO.

[dwalton22]

I've seen this before where the recording is either shorter or longer than what was scheduled but this case was dramatic so that's why I started digging into it. I'll have to double check when I get home but I'm fairly sure I have NTP setup to sync once every hour. I don't know for sure that this was caused by a clock sync issue though, that's just the only logical thing I could come up with.

What is odd to me is that sage appears to take the scheduled recording length and divide that by the number of frames to determine the framerate. In my case I had 59748 frames over 32 minutes so sage plays at 31.73 fps. How does this work for a digital recording where the framerate isn't constant? Some of our local stations air 480i commercials in the middle of a 720p show. Maybe this explains why I also see the commercial breaks have problems on some HD recordings.

[Humanzee]

clues clues clues. My commercial time stamps have been off in all sorts of weird ways. It will jump before or after the mark on the scrolling time line. Then sometimes after a jump it will play for a while and jump backwards to where the end of the last commercial was and start playing the last few seconds of content over again. As if it passed some commercial end mark and then tried to catch up or correct.

I haven't checked the length of the recording in any other app. Maybe its time to do so. hmmm. I thought that it was bad recordings but I would get bad jumps even after quickstream Fixing them.

Do you think going back to TXT vs EDL would fix this? Isn't txt by frame number and EDL by time?

[JREkiwi]

Originally Posted by Humanzee

Do you think going back to TXT vs EDL would fix this? Isn't txt by frame number and EDL by time?

That won't help as the frame numbers in the TXT file are just converted to a time. EDL files don't do the conversion so don't suffer from rounding errors.

John

[Humanzee]

so does your comskip stvi use time either way instead of frame number for txt?

txt may be less accurate than edl as far as show analyzer is concerned but if the stvi plugin uses frame number sage should jump when it gets to the correct frame number during playback, instead of the indicated time, which is apparently wrong. , no?

[dwalton22]

I use SageMC with edl files but I've never tried with just txt files. I'll give that a try tonight on my SouthPark episode and see if it makes a difference.

Thinking outloud...if ShowAnalyzer knew how long the recording was supposed to be then it should be possible to build a much more accurate edl file for cases like this. For instance if you take the txt file for my southpark episode and use a framerate of 31.73 fps (instead of 29.97fps) then the edl file would have the correct timestamps for sage.

[JREkiwi]

Originally Posted by Humanzee

so does your comskip stvi use time either way instead of frame number for txt?

txt may be less accurate than edl as far as show analyzer is concerned but if the stvi plugin uses frame number sage should jump when it gets to the correct frame number during playback, instead of the indicated time, which is apparently wrong. , no?

All the comskip playback implementations only use time. That's the only method of performing any SageTV media player actions. That's why when you are using txt you need to specify the framerate (NTSC/PAL) so they can do a conversion.

The reason edl files are more accurate is that there is at least 1 conversion from frame to time involved in the process. (with the resulting rounding errors). There may also be another one involved in creation of the file. (I don't know how the various programs create the files).

Additionally you will run into problems if a SageTV recording mpeg/avi date/time stamp is modified from the time that SageTV set it to at the end of recording or after doing an inbuilt conversion.

John

[Humanzee]

ok, I thought that you were saying that show analyzer made the conversion to and from frame numbers from what it detected.

What you were actually saying is that the frame numbers in a txt file, where ever they come from, get converted to time values by the stv. As the time line displays time progress not frame progress. and that time line progress triggers the commercial jump. correct?

re: date/time stamp modification:
So could quickstream fix actually make this problem worse?

[dwalton22]

If your commercial flagger creates an edl file then the stv will just use that instead of the txt file. If it has to use the txt file then it will convert that to seconds. For my southpark recording the txt file is:

0 6588
23966 30277
41404 45467
55570 59756

and the edl file is basically the seconds from the txt file divided by the framerate 29.97:

0 219.82 0
799.666 1010.24 0
1381.51 1517.08 0
1854.19 1993.86 0

[Tundra-]

Originally Posted by dwalton22

I use SageMC with edl files but I've never tried with just txt files. I'll give that a try tonight on my SouthPark episode and see if it makes a difference.

Thinking outloud...if ShowAnalyzer knew how long the recording was supposed to be then it should be possible to build a much more accurate edl file for cases like this. For instance if you take the txt file for my southpark episode and use a framerate of 31.73 fps (instead of 29.97fps) then the edl file would have the correct timestamps for sage.

Hey dwalton22,
I just noticed this post and another from you in the SA forums
(http://www.dragonglobal.biz/forums/s...reaks-off.html).
I've had the same -commercial breaks are off by a little and it gets worse as the show progresses- problem for some time and came to the same exact conclusion about adjusting the edl numbers. I'm not sure if you're still having this issue, but if so, I was able to come up with a workaround (albeit a bit kludgey)...
I started a thread at http://forums.sagetv.com/forums/showthread.php?t=34251

Tundra-

[dwalton22]

Thanks Tundra. I still see this problem sometimes but it doesn't seem to be as often as it used to be. I'll give your Skipfix script a try though, it can't hurt