Can't Skip After v2.5.9->3.1.1 Upgrade

[Braklet]

Well folks, I uninstalled NPVR, deleted Program Files\NPVR, and reinstalled. This might have affected things but the problem still occurs occasionally, especially during Chase Play. Reproduced multiple times and every time I got similar events in npvr.log, so the attachment above that shows "Timing.info duration 0ms" and "skip to -2 position" still applies.

I also ran the problematic recording that sparked this thread through VideoReDo remux, which "fixed" the problem for that file only. So there may well be some goofy issue with my TS mux platform or something similar.

Might have to wait until sub comes back to provide an expert opinion, but what are the differences between v3.1.1 and v2.5.9 in regard to timing calculations? I'm hoping someone can explain how Timing.info does its thing.

I really don't want to switch front ends but I might give XBMC a try just to see if it acts differently.

Thanks again!

[Zeb]

After updating from 2.5.9 to 3.1.1, did you perhaps reintroduce the older version of npvr.db3?

[johnsonx42]

timing.info is an ADS stored with your .ts file. So if your recording is filename.ts, then the timing data is filename.ts:timing.info. From a command prompt, "dir /r" will show you the filenames with their ADS names. Unfortunately afaik the del command won't accept an ADS. You can use notepad though (notepad "filename.ts:timing.info") and just erase all the data (ctrl-a, del); the ADS will still be there, but it will be empty.

Martin's writeTime utility will write new timing.info data in a separate file (filename.ts.timing.info) which will be used by NextPVR if the ADS timing.info is not present (or empty).

VideoRedo worked on your problem files most likely simply because it lost the timing.info ADS in the process.

[johnsonx42]

..but what are the differences between v3.1.1 and v2.5.9 in regard to timing calculations? I'm hoping someone can explain how Timing.info does its thing.

Timing.info isn't new, it was introduced in the very early days of NPVR (maybe 1.5.28?). What is new is that 3.1.1 now uses it when playing in-progress recordings (what you are calling "chase play"), whereas before it was used only when playing completed recordings. It may also be used for live tv now, I'm not sure. All it does is add a list of realtime bytecounts to the file... at 5 seconds the byte count is 10000, at 10 seconds the byte count is 20000, and so on (the times are in milliseconds though). This data lets NPVR determine position and skip accurately in a transport stream file that has a variable bit-rate and various glitches, with commercials inserted by the local broadcaster that may disrupt other timing information in the stream.

As I suggested before, one workaround for your problem would be a patch to reject obviously ridiculous timing.info data during playback and revert to calculating position like it used to without timing.info. But the root problem remains, why are you getting bad timing.info in the first place?

[mvallevand]

What is new is that 3.1.1 now uses it when playing in-progress recordings (what you are calling "chase play"), whereas before it was used only when playing completed recordings.

I didn't know that one, I thought I still saw the messages in the logs on locked files that say Timing.Info ignored.

Martin

[Braklet]

Oh joy, more fun with alternative data streams. Gotta refamiliarize myself with Sysinternals Streams, I guess.

I checked an analog recording made last night and found the following via "notepad <file>:Timing.info" :

Code:

0,0
875,427700
1844,723800
2765,1151500
3656,1776600
4562,2270100
5453,2829400
6422,3520300
7406,4079600
8297,4737600
9203,5296900

I have no idea if this is valid timing data but it is at least non-zero.

Just for fun I recorded a couple minutes of digital HD (ATSC broadcast) to see what that TimingInfo looked like:

Code:

0,0
0,83848
0,167696
0,251544
0,335392
0,419240
0,503088
0,586936
0,670784
0,754632
0,838480
0,922328

Well well, look at that first column, all zeros! I'm using whatever TS mux either delivered with XP or came with v2.5.9 NPVR, since previously we used DVR-MS. I'd like to fix that if at all possible. Does anybody know how that Timing.info gets generated or updated?

What about that registry tweak that I saw referenced in the R1 updates rollup? Would that tweak help here by forcing NPVR to use the "old" technique?

In the meantime, at least now I understand what you and Martin are talking about.

[Braklet]

After updating from 2.5.9 to 3.1.1, did you perhaps reintroduce the older version of npvr.db3?

Doubtful, as I occasionally edit the database directly in order to rename files, and noticed that the upgrade process added new columns to the tables I look at. Thanks for the idea, in any case.

[Braklet]

From a command prompt, "dir /r" will show you the filenames with their ADS names.

That reminds me: "dir /r" is not available on my HTPC (WinXP SP3). I don't think it showed up until Vista, maybe later.

I was able to find evidence of Timing.info using Russinovich's streams.exe, packaged nicely with a bunch of other great tools here.

[johnsonx42]

I didn't know that one, I thought I still saw the messages in the logs on locked files that say Timing.Info ignored.

Well that's what sub said he did. I was bugging him for changes to skipping on in-progress recordings, and the first changes he did made it really bad; then he did it a different way, and it seemed to work much better. Just before or right after 3.1.1's release, someone (reddwarf I think) asked exactly what the change was, and he said it now uses Timing.Info for in-progress too.

[johnsonx42]

I checked an analog recording made last night and found the following via "notepad <file>:Timing.info" :

Code:

0,0
875,427700
1844,723800
2765,1151500
3656,1776600
4562,2270100
5453,2829400
6422,3520300
7406,4079600
8297,4737600
9203,5296900

I have no idea if this is valid timing data but it is at least non-zero.

Looks pretty reasonable. Byte count growing with the milliseconds; the entries are around 900ms apart, as they should be.

Just for fun I recorded a couple minutes of digital HD (ATSC broadcast) to see what that TimingInfo looked like:

Code:

0,0
0,83848
0,167696
0,251544
0,335392
0,419240
0,503088
0,586936
0,670784
0,754632
0,838480
0,922328

Well well, look at that first column, all zeros!

Yeah, that's bad... time has stopped! Sub wouldn't have thought that could ever happen, so he didn't build in any check for that.

I'm using whatever TS mux either delivered with XP or came with v2.5.9 NPVR, since previously we used DVR-MS. I'd like to fix that if at all possible. Does anybody know how that Timing.info gets generated or updated?

NPVR uses it's own filters to write transport stream files. NPVRTSWriter.ax and NPVRTSMon.ax are involved; both were updated in NPVR 3.1.1 and further in the R1 rollup.

What about that registry tweak that I saw referenced in the R1 updates rollup? Would that tweak help here by forcing NPVR to use the "old" technique?

That tweak which sub wrote just for me and my apparently screwball mainboard and it's slightly slow clock is only useful in a very special scenario which I hacked my way into. You could try setting the registry value and see if it changes anything though... it will change the clock source it uses to generate the timing.info data.