Recording length error

[VCR58]

Sorry, I thought it was the normal one drive. Might use Google drive instead if I can't figure out OneDrive.

I'll be out of town tomorrow.

Thanks

[mvallevand]

No problem I think I landed right on the gap, I should have been 500 blocks back try with "bs=188000 skip=78042 count=1000" if you have a chance.

Martin

[mvallevand]

You mentioned remuxing the file, I am hoping you are cutting the raw file.

Then looking at the file again logically I released there is a second issue with the time stamps

Code:

frame,11130.951378,14478542700
frame,11131.201633,14478838612
frame,95444.417889,14479166296
frame,95444.668133,14479463900

So let's get a bigger cut with

and this would "bs=188000 skip=76500 count=2500"

Martin

[VCR58]

The shared file is generated from the raw file. Try this link for the cut file from your new numbers

https://drive.google.com/file/d/1nEerFp_...p=drivesdk

[mvallevand]

Odd, it has the first issue but not the second, the timestamps were ok. Not sure if that is enough for sub.

frame,11130.951378,96542700,side_data,
frame,11131.201633,96838612,side_data,
frame,95444.417889,97166296,side_data,
frame,95444.668133,97463900,side_data,
...
frame,95639.112389,384074224,side_data,
frame,95639.362633,384531252,side_data,
continues normally.

Martin

[mvallevand]

I did a couple of long 4 hr test on my Tablo and there were no timestamp issues, so I think we can rule out decoder problems. I thought maybe it would role over How is your signal? Since the mpeg2video is being transcoded to h264 it is a possible that a really bad error is upsetting the transcoding.

For problem streams, I will stick with my recommendation to stop the creation of timing files and remux to fast start mp4 which eliminates timestamp and skip problems for most direct play players. It takes a bit more time and disk space initially (the ts file can be removed so it will be lower at the end) but the CPU uses isn't much lower and the whole file still needs to be read. Neither method works well for in-progress.

Martin

[sub]

If you're using any UI Clients, you could see if this helps. If it does, I'll also make the change to NPVRTSReader5.ax (for playback in nextpvr.exe)

[VCR58]

If you're using any UI Clients, you could see if this helps. If it does, I'll also make the change to NPVRTSReader5.ax (for playback in nextpvr.exe)

It seemed to fix the web client but the web uiclient still reports the recording to be 15 min. Haven't tried uidroid yet.

When I played the recording with the web client the recording length at first reported 15 min but then changed to 3:21:00

[mvallevand]

The web client transcodes so it gets rid of bad timestampt but did you try skipping to see if NextPVR is now normalizing the bad timing file?

Edit: I checked with your VCR58''s sample and it seems to do something with it,

2023-11-12 17:50:58.971 [DEBUG][126] Looking for D:\Samples\NFL Football_20231105_15251830.timing
2023-11-12 17:50:58.984 [WARN][126] clock jump of 11051.5681 seconds
2023-11-12 17:50:58.985 [WARN][126] clock jump of 84313.216256 seconds

and it seems to work for the duration me except it is not putting in the ranger header

Code:

2023-11-12 17:46:09.610    [DEBUG][60]    ClientGetActivity() returning:
{
  "level": 3,
  "url": "/stream?client=PC&seek=184&f=D%3A%5CSamples%5CNFL%20Football_20231105_15251830.ts",
  "screen": "player",
  "skip_to": "184",
  "duration": "302",
  "range": "0-"

}

Martin

[sub]

except it is not putting in the ranger header

It shouldn't have changed anything that could affect the range header. It was a very localized change.