Skip Problem

[Lao Pan]

Oh dear didn't want to be the bringer of bad tidings.
Just been running these latest patches for the last ten minutes and the time-lines are all messed up - 55 minute show now has 17.24 on the right side of the line and of course it resumes to the wrong place - probably aprox pro-rata with the time line anomaly.
This is with Freeview HD recordings that have been trimmed with videoredo, so no timing info data.
Mine was working well up till now (Stand alone - no client.)

Sorry

[imilne]

I can confirm client/server stuff all seems ok again now. Cheers sub.

I had a quick look at some video-redoed files I had (from SD recordings) but their timelines all look ok and they resume at the correct point too. They were originally dvr-ms files converted to mpeg after trimming. That was on the server though.

Iain

[sub]

Oh dear didn't want to be the bringer of bad tidings.
Just been running these latest patches for the last ten minutes and the time-lines are all messed up - 55 minute show now has 17.24 on the right side of the line and of course it resumes to the wrong place - probably aprox pro-rata with the time line anomaly.
This is with Freeview HD recordings that have been trimmed with videoredo, so no timing info data.

You're always going to get the best durations and skipping with the original .ts files with timing.info. Thankfully this is what most people are using.

When it tries to determine the duration of a recording that doesnt have timing.info, it tries to calculate duration two different ways (based on file size divided by sampled bitrate, and first/last timestamp). These generally work pretty well, but can still be screwed by the broadcaster timestamps in some situations.

I cant download a huge recording, but if you want to use cutchunk to cut a 200MB or so sample from the beginning of the recording, and this chunk exhibits the problem, then let me know where I can download it from and I'll take look.

[Lao Pan]

This has only happened in the last day or two - I will try to do some tests to find out more info.
47 min shows are showing 17-18 mins on the right side of the time line 2 hour film showing over 4 hours -they were ok a few days ago - maybe not exact but close enough that I didn't notice.

Would it be possible for someone to write a standalone timing info generator that could be used after trimming files? (Unfortunately not me-:confused - could be very useful. I have about 500 programs saved over the last 5 years on GBPVR / NPVR as ts files that have been trimmed with videoredo

[sub]

If you're able to supply a short sample recording that exhibits the problem, I'm happy to take a look.

[mvallevand]

Would it be possible for someone to write a standalone timing info generator that could be used after trimming files? (Unfortunately not me-:confused - could be very useful.

I do have something I was working on a while back that I put on hold because NextPVR didn't support the external Timing.Info file to the NMT, that I put on hold. Now that the external file is working I will get back to it. It tries to calculate lapsed time based on the audio and video streams and ts stream times, but it won't support HE-AAC audio times.

Martin

[Lao Pan]

I have narrowed it down - the original ts reader gets the lengths very close, but skipping completely wrong - NPVRtsreader2gets the lengths completely wrong, but gets skipping completely right

I will try to get a sample cut that shows the same problem and upload it.

Martin - sounds like a possibility but would it work on just the video and ts time - UK Freeview HD is AAC / LC

[Lao Pan]

Her is a 198 mb chunk of one of the problem files:-

http://www.mediafire.com/?un44fn4du4nsvsb

NPVRtsreader2 thinks it is 1 min 39 sec long - It is actually 4 mins 5 sec long - 6148 frames (25fps)

MediaInfo:-

General
ID : 1 (0x1)
Complete name : Z:\VIDEO 2\Call_the_Midwife_Chunk.TS
Format : MPEG-TS
File size : 198 MiB
Duration : 4mn 5s
Overall bit rate mode : Variable
Overall bit rate : 6 772 Kbps

Video
ID : 6601 (0x19C9)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : 27
Duration : 4mn 5s
Width : 1 440 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

Audio #1
ID : 6602 (0x19CA)
Menu ID : 1 (0x1)
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Muxing mode : LATM
Codec ID : 17
Duration : 4mn 5s
Bit rate mode : Variable
Minimum bit rate : 109 Kbps
Maximum bit rate : 176 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : -40ms
Language : English

Audio #2
ID : 6606 (0x19CE)
Menu ID : 1 (0x1)
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : HE-AAC / LC
Muxing mode : LATM
Codec ID : 17
Duration : 4mn 5s
Bit rate mode : Variable
Minimum bit rate : 109 Kbps
Maximum bit rate : 173 Kbps
Channel(s) : 1 channel
Channel positions : Front: C
Sampling rate : 48.0 KHz / 24.0 KHz
Compression mode : Lossy
Delay relative to video : -40ms
Language : English

Text
ID : 6605 (0x19CD)
Menu ID : 1 (0x1)
Format : DVB Subtitle
Codec ID : 6
Duration : 3mn 57s
Delay relative to video : 5s 198ms
Language : English

[sub]

The app is using two different methods for determining the duration. Looking at your file I can see one method is getting the correct duration, but unfortunately it's decided the other method is more likely to be accurate. I'm looking into it.

[sub]

Can you see if this helps?