question about Timing.Info ADS

[johnsonx42]

Sub,

Can you think of any reason why NPVR would not use the Timing.Info ADS stream on a file even though it's there?

I had a 3 1/2 hour recording tonight (the wife's Emmy Awards show) that acted like it had no Timing.Info. When she first started playing it (after the recording was complete), I noticed right away that the timeline looked a little odd: the end-time of the timeline was increasing and decreasing quite a bit as we started watching, just like it would with a pre-1.5.28 .ts file without the Timing.Info. I checked over the network, and the Timing.Info was definitely there and complete. It settled down as she got several minutes into the show, so no worries I thought.

Then at about 1 hour and 33 minutes into the show, both ends of the timeline reset to 00:00:00, and skipping was no longer possible. Again, this is common pre-1.5.28 behaviour, a minor glitch in the transport stream. I exited and restarted playback, but the timeline reset at the same spot.

Fortunately I had also recorded the second showing of the Emmy show, and that one was far enough along at this point that I was able to just skip to the same spot and let her finish watching the show skipping through all the lame speaches.

After the second recording completed, I started playing around with the Timing.Info. I copied it out to a temp file and then removed it from the problem recording, and found the timeline reset at exactly the same spot, and in general the playback acted just like it did when we played the file earlier.

After fiddling around a little more, I put the same Timing.Info back on the file, and found that it will now play all the way through the file without problems. The timeline is also now perfectly consistent right from the beginning of playback - the end time shown is 3:29:59 from the first moment on to the end of the file, it doesn't hunt around like it did when we first played it.

So it seems clear that NPVR was not using the Timing.Info data at first, even though it was there, but did use it later on during my testing.

At first I wanted to blame comskip, which was still running against the file at the time we had the problems; I was thinking that maybe the way it has the file open somehow prevented NPVR from reading the ADS. However, the second recording is clearly playing with the Timing.Info, yet comskip is still running against that file as I write this (comskip takes about 40 minutes for every hour of HD here).

I know this is a bit convoluted, but any thoughts at all on what could make it ignore or be unable to access the Timing.Info? It doesn't log anything about it when it reads the Timing.Info so it's hard for me to provide you any more detail.

[Reddwarf]

Just a comment about Comskip. I'v been running comskip in PostProcess since the Timing.Info was introduced, I use the same algorithm that worked perfectly with GBPVR. During this period I'v noticed two things:

- Comskip tends to skip a little bit early and resume even earlier than it should.
- Towards the end of long shows this gets worse.

[BrettB]

Just a comment about Comskip. I'v been running comskip in PostProcess since the Timing.Info was introduced, I use the same algorithm that worked perfectly with GBPVR. During this period I'v noticed two things:

- Comskip tends to skip a little bit early and resume even earlier than it should.
- Towards the end of long shows this gets worse.

I've also been using comskip fairly effectively.

I would periodically see the behavior you describe with the early skipping in GBPVR on certain files.

Since the timing.info was introduced, I've noticed a new condition. For several recordings, the skip points get displayed in only the first 1/2 of the timeline by NPVR. At first I thought that it was an NPVR problem. But, after looking into a little bit over the weekend, I discovered that it appears to be a problem with comskip. It looks like the skip points in the .txt file have accurrate frame numbers. However when it converts/calculates the skip points for the .edl file, they are only in the first half of the total recording length. I THINK that all of these occurances have been on show recorded from our local CBS affiliate which (typically) broadcasts in 1080i. So, I wondering if there is some sort of new issue with the conversion to .edl for 1080i broadcasts. (Apparently only under certain conditions, though, becuase this condition doesn't affect all comskip processing of CBS shows.) I'm going to try to diagnose more and followup on the comskip forum.

[Reddwarf]

I've also been using comskip fairly effectively.

I would periodically see the behavior you describe with the early skipping in GBPVR on certain files.

Since the timing.info was introduced, I've noticed a new condition. For several recordings, the skip points get displayed in only the first 1/2 of the timeline by NPVR. At first I thought that it was an NPVR problem. But, after looking into a little bit over the weekend, I discovered that it appears to be a problem with comskip. It looks like the skip points in the .txt file have accurrate frame numbers. However when it converts/calculates the skip points for the .edl file, they are only in the first half of the total recording length. I THINK that all of these occurances have been on show recorded from our local CBS affiliate which (typically) broadcasts in 1080i. So, I wondering if there is some sort of new issue with the conversion to .edl for 1080i broadcasts. (Apparently only under certain conditions, though, becuase this condition doesn't affect all comskip processing of CBS shows.) I'm going to try to diagnose more and followup on the comskip forum.

Do you have the donator version? The free one does not work for HD.

[BrettB]

Do you have the donator version? The free one does not work for HD.

Yes, I have the donator version. I updated to the latest version, too. Same results for the same files.

[sub]

I know this is a bit convoluted, but any thoughts at all on what could make it ignore or be unable to access the Timing.Info?

The only reason I can think of is that it wont use the Timing.Info on a recording that is still in-progress.

It doesn't log anything about it when it reads the Timing.Info so it's hard for me to provide you any more detail.

You can tell when it is beinmg used by checking for "Using timing.info, jumping to time ..." messages in npvr.log each time you skip.

[johnsonx42]

yeah, you're right (of course you're right, it's your code!), it does log those. Just didn't see them. I also missed this when playback was started:

Code:

2010-08-29 21:09:13.462    [DEBUG][1]    File in use. Maybe still recording.

This was after the recording was complete, so comskip having the file open is the only explanation.

Evidence also says I was wrong in my belief that the second recording was using the Timing.Info even while comskip was running; the log says it never did. The second recording just had a better internal timeline I guess, which made me believe it was using the Timing.Info.

So we're down to something much more simple. Comskip running against the file makes NPVR think the file may still be recording, and thus prevents use of the Timing.Info.

Is it possible you could check to see if the recording is still in progress in a different way, and allow the Timing.Info to be used while comskip has the file open? It'd be nice to be able to use the Timing.Info on a recording in progress, if nothing else to prevent nasty timeline problems due to a little transport stream glitch, but I assume you had good reason to prevent it.

[Reddwarf]

My comskip runs at 04:30 in the morning as a batch, so I'v never tried to skip in a file open by comskip.

[pBS]

i've been gettingthat also on old pvrx2...it's comskip..
it hangs occasionally on certain shows, i think from the occasional signal dropout, which it normally handles, but sometimes it just just hangs there not doing anything...
during that time, the recording is 'in use' even tho recording service isn't the culprit...it's comskip..
kill comskip nd the file is no longer busy and skip points are there..
i think we need to turn off the timeline 'fix' in comskip so it won't try to adjust anything at the end..
it seems to hang after commercial scanning is done, in the final evaluation afterwards, just before writing the final touches to the skip files..
[cuz i see skip points already appear]

i think this needs to be set to 0....
max_repair_size=200 ; Will repair maximum 200 missing MPEG frames in the timeline, set to 0 to disable repairing for players that don't use PTS.

and yes the non-donate version does do hd, just not fast as the donate ver....i'm using decenly new one, but nowhere near latest..

[Reddwarf]

i've been gettingthat also on old pvrx2...it's comskip..
it hangs occasionally on certain shows, i think from the occasional signal dropout, which it normally handles, but sometimes it just just hangs there not doing anything...
during that time, the recording is 'in use' even tho recording service isn't the culprit...it's comskip..
kill comskip nd the file is no longer busy and skip points are there..
i think we need to turn off the timeline 'fix' in comskip so it won't try to adjust anything at the end..
it seems to hang after commercial scanning is done, in the final evaluation afterwards, just before writing the final touches to the skip files..
[cuz i see skip points already appear]

i think this needs to be set to 0....
max_repair_size=200 ; Will repair maximum 200 missing MPEG frames in the timeline, set to 0 to disable repairing for players that don't use PTS.

and yes the non-donate version does do hd, just not fast as the donate ver....i'm using decenly new one, but nowhere near latest..

Thanks, I'll try that.