timing.info too short, timeline inaccurate

[sub]

Now a 1 hour test recording has completed, the timeline shows 59:48. It seems the generated timing.info is consistently 6 seconds short per 30 minutes of show.

Ah, you must have meant 29:59 above not 29:29

[mvallevand]

Do you really see 29:29? or do you mean 29:59?

I can imagine it possibly being 5 seconds out in the duration, although I'd expect the difference to be a lot smaller than that. I definitely would not expect to see a difference like 29:29 vs 29:54, ie 25 seconds.

He wrote 29:29 with writeTime so I am confused.

Martin

[sub]

I'm at a bit of a loss for how to explain this. NextPVR is not using any timing from stream for generating the timing.info.

When the first packet arrives, NextPVR askes Windows for the current time in milliseconds, and stores it as the time the first packet arrived. Every subsequent packet that arrives, NextPVR again askes windows for the current time in milliseconds, and subtracts the original value to get the position in milliseconds - if it was more than 800ms since it last wrote to timing.info, then it writes another.

For the duration to be out by any significant amount, it'd seem that Windows would have to be returning a current time in milliseconds that is drifting from reality.

[sub]

Unless its something weird related to the way they're broadcast 30fps material at 29.97 or vice versa.

ie, playing it out a bit faster or a bit slower than the material is timestamped for.

[mvallevand]

I think there is something in the logic about the 900ms that assumes that some traffic flows through it. I have seen files where the first real write is at 15 or 20 seconds with a small number of bytes, Even johnsonx42's first sample showed that there weren't write at 900 1800 2700.. etc.

Martin

[sub]

I think there is something in the logic about the 900ms that assumes that some traffic flows through it. I have seen files where the first real write is at 15 or 20 seconds with a small number of bytes, Even johnsonx42's first sample showed that there weren't write at 900 1800 2700.. etc.

That's why I said I can expect duration to be out up to a few seconds - primarily related to the how consistently the device delivers data right at the beginning of the stream. Some devices are great, and just start delivering a consistent stream of data from the very first second. Some do a bit of a hiccup as they start, delivering a little bit of data, followed by short delay, before data starts flowing properly.

This can mean that on some devices the data might be out a couple of seconds, but this only a condition that occurs right at the beginning, and doesn't account for any drift over time like is being reported here.

FYI, what you describe doesn't matter too much to the app. It doesn't matter if there is no entry in the first second or two. The use of this timing info has always been designed to deal with situations like a couple of seconds missing at the start, or in the middle of the file if there was signal loss etc.

[johnsonx42]

Do you really see 29:29? or do you mean 29:59?

Yes, sorry, that was a typo. 29:54 with the original timing.info, 29:59 with the writeTime-generated timing.info.

[johnsonx42]

I guess at this point I'm considering going back to 3.0.1 to see if the problem goes away.

[sub]

I guess at this point I'm considering going back to 3.0.1 to see if the problem goes away.

Yeah, it'd be interesting to see if older builds behave any differently. Given nothing really changed on that front, I'd expect it to give the same results.

[johnsonx42]

If it still does it with 3.0.1 then I'll have to blame my hardware. I'm not sure how it can be the hardware, it would seem that any time drift would affect everything equally, but that was the other change between when it was working in late July and when it started doing this in early August.