Recording lengths wrong on PCH

[BrettB]

I'm still sometimes getting recordings with 2.0.3 that are showing an incorrect recording length on the OSD when I play them on the PCH. I had two occurrances tonight. One was with a recording of "CSI" and the other was with a recording of "America's Next Great Restaurant".

For CSI the lengths show up as:
PCH: 01:04:10
PC: 01:02:59

For America's Next Great Restaurant:
PCH: 00:45:33
PC: 01:00:59

The attached .zip file has logs from playing each on the PC (where the time appears correctly) and the PCH (where the length is wrong). It also includes a putty.log from the PCH and the timing.info files from each of these recordings.

[BrettB]

BUMP.

Sub,

Any ideas about how we can get these files to play properly on the PCH?

[sub]

As long as its a completed recording, not an in-progress one, then the PCH should report the same time as when you play the same file on the PC.

Are these recordings on a local NTFS drive, or some network or FAT32 drive?

[BrettB]

As long as its a completed recording, not an in-progress one, then the PCH should report the same time as when you play the same file on the PC.

Are these recordings on a local NTFS drive, or some network or FAT32 drive?

These are all completed recordings. And they are on a local NTFS drive.

[sub]

It looks like it's got the timing.info for this file, so it should have an accurate duration. What is the last few lines you see when you do:

notepad "E:\NPVR Recordings\Americas Next Great Restaurant\Americas Next Great Restaurant_20110403_19002000.ts:timing.ingo"

[BrettB]

It looks like it's got the timing.info for this file, so it should have an accurate duration. What is the last few lines you see when you do:

notepad "E:\NPVR Recordings\Americas Next Great Restaurant\Americas Next Great Restaurant_20110403_19002000.ts:timing.ingo"

The entire timing.info files for both of these are in the .zip file which I posted. Is there something else that you are looking for? I think that the "timing.ingo" in your command above is just a typo for "timing.info".

[mvallevand]

I think the MVP/NMT logic for duration still is based on reading the file

Code:

2011-04-03 22:15:25.092    [DEBUG][7]    about to read 84600 from location 5669884856  (current length = 5669969456)
2011-04-03 22:15:25.092    [DEBUG][7]    Estimated Video Duration: 2733.28862478205

This "estimated" value from the buffer at (EOF - 84600) is always sent to the NMT and it is usually different then the Timing.Info value.

Martin

[sub]

It should use the duration from the timing.info. I cant test it myself at the moment, but you could see if this helps.

[mvallevand]

I made a bogus entry in Timing.Info to take a small file 1hr and that is what shows on the PC, however it is still reporting a 14s duration from the file on the PCH, likely based on this.

Code:

2011-04-06 00:07:56.444    [DEBUG][7]    CheckPCRDuration@1.3
2011-04-06 00:07:56.444    [DEBUG][7]    first pcr: 1499   (at offset 564)
2011-04-06 00:07:56.444    [DEBUG][7]    last pcr: 1350703   (at offset 9589128)
2011-04-06 00:07:56.444    [DEBUG][7]    Video Duration: 14.9911555555556

Martin

[sub]

Regardless of what it says in the log, if you press the blue key during playback, does it report the correct duration?

You shouldnt see "CheckPCRDuration@1" in the logs with that patch if it managed to get the duration from timing.info. (which well, you might see it once, but these messages should be missing once playback has started, instead showing "Using duration from timing.info")