MVP - negative start time on timeline

[bgowland]

I'm not sure if this is an mvpmc issue or an npvr issue so I just thought I'd post here.

I'm running npvr 1.5.36 and latest dongle.npvr.bin (also tried previous mvpmc dongle). I have a recording (made with npvr) which is causing problems on playback, specifically skipping (unsurprisingly).

I start playing it and if I hit the Blue button on my remote, the timeline correctly shows the start time up until about ~18 seconds into the recording. At this point, the start time on the timeline shows 00:-52:-55 (the end time on the timeline remains correct).

The recording plays perfectly with npvr on my PC and shows the correct timeline and will skip forwards/back without problems and without losing AV sync.

I updated the Unmanged.dll that was posted in this thread ... http://forums.nextpvr.com/showthread.php...d-up-again but no change.

Log extract...

Code:

2010-12-28 02:15:15.410    [DEBUG][3]    MVP request processed
2010-12-28 02:15:15.410    [DEBUG][3]    MVP waiting for data
2010-12-28 02:15:15.723    [DEBUG][3]    MVP data read: 1   (9)
2010-12-28 02:15:15.723    [DEBUG][3]    Raw PTS received:143664480
2010-12-28 02:15:15.723    [DEBUG][3]    Reported PTS now:788400  time: 17.52
2010-12-28 02:15:15.723    [DEBUG][3]    MVP request processed
2010-12-28 02:15:15.723    [DEBUG][3]    MVP waiting for data
2010-12-28 02:15:15.738    [DEBUG][7]    Received: STREAM_GETDATA
2010-12-28 02:15:15.738    [DEBUG][7]    Request 200000 bytes (file size:2761282336   file location: 8200000)
2010-12-28 02:15:15.738    [DEBUG][7]    about to read 200000 from location 8200000  (current length = 2761282336)
2010-12-28 02:15:15.738    [DEBUG][7]    Request completed. 200000 bytes sent
2010-12-28 02:15:16.442    [DEBUG][3]    MVP data read: 1   (9)
2010-12-28 02:15:16.442    [DEBUG][3]    Raw PTS received:0
2010-12-28 02:15:16.442    [DEBUG][3]    Reported PTS now:-142876080  time: -3175.024

Log attached.

[mvallevand]

It looks like a file and/or mvpmc problem. Can you cut about 40 MB from the beginning of that file and put it on megaupload or mediafire and I can check

Martin

[bgowland]

Remind me of a good way of cutting a chunk (been a while since I did it).

I'll PM you a link to it on my own server as I don't use megaupload or mediafire.

[mvallevand]

Here's one link to sub's utility

http://forums.nextpvr.com/showthread.php...post345274

Martin

[bgowland]

Thanks - I had a copy of that some time ago but it got lost in a clean up.

PM sent.

[bgowland]

Thanks for taking a look, timing info for the recording attached.

EDIT: Ooops, typo - it got saved as Timing.Inf instead of Timing.Info

[mvallevand]

I was able to fix your file by remuxing, but the reason it was failing was mvpmc was triggering on the gop.pts and during the commericial they were messed up. I've updated dongle4npvr and I am taking a different approach to getting the pts. Let me know if it helps.

Martin

[bgowland]

I was able to fix your file by remuxing, but the reason it was failing was mvpmc was triggering on the gop.pts and during the commericial they were messed up. I've updated dongle4npvr and I am taking a different approach to getting the pts. Let me know if it helps.

Martin

OK, I managed to give it a quick try but it's past 7am here so that's all it was.

The timeline seems to have gone in a positive direction to the negative one it was previously, i.e., it quickly jumps to approx +53 minutes as a start point rather than -53 minutes.

Code:

2010-12-28 06:39:59.746    [DEBUG][3]    [B]OSD needs update. Hash now: MetaData~Timeline:00:00:00:02:11:57~[/B]
2010-12-28 06:39:59.761    [DEBUG][3]    SendIncrementalFrameDataWithAlpha (loc = 44,40) (rect = {X=0,Y=0,Width=640,Height=500}) 0x08 encoding
2010-12-28 06:39:59.824    [DEBUG][3]    Y/Y2 buffer: 10444 bytes
2010-12-28 06:39:59.855    [DEBUG][3]    Alpha buffer 336 bytes compressed
2010-12-28 06:39:59.871    [DEBUG][3]    incremental frame sent
2010-12-28 06:40:00.027    [DEBUG][3]    MVP data read: 1   (7)
2010-12-28 06:40:00.027    [DEBUG][3]    Got ACK
2010-12-28 06:40:00.027    [DEBUG][3]    MVP request processed
2010-12-28 06:40:00.027    [DEBUG][3]    MVP waiting for data
2010-12-28 06:40:00.027    [DEBUG][3]    MVP data read: 1   (9)
2010-12-28 06:40:00.027    [DEBUG][3]    Raw PTS received:142831351
2010-12-28 06:40:00.027    [DEBUG][3]    Reported PTS now:142826393  time: 3173.91984444444
2010-12-28 06:40:00.027    [DEBUG][3]    MVP request processed
2010-12-28 06:40:00.027    [DEBUG][3]    MVP waiting for data
2010-12-28 06:40:00.043    [DEBUG][7]    Received: STREAM_GETDATA
2010-12-28 06:40:00.043    [DEBUG][7]    Request 200000 bytes (file size:2761282336   file location: 1000000)
2010-12-28 06:40:00.043    [DEBUG][7]    about to read 200000 from location 1000000  (current length = 2761282336)
2010-12-28 06:40:00.043    [DEBUG][7]    Request completed. 200000 bytes sent
2010-12-28 06:40:00.121    [DEBUG][3]    [B]OSD needs update. Hash now: MetaData~Timeline:00:52:53:02:11:57~[/B]

Also, about 20 seconds after the above, I pressed 'Skip' (not FF) and instead of skipping 45 seconds (my config.xml setting) it seems to have jumped ~50 minutes (I press the Blue button after I realise the film has skipped further than I expected)...

Code:

2010-12-28 06:40:36.730    [DEBUG][3]    OSD needs update. Hash now: MetaData~Timeline:01:44:04:02:11:57~

I'll hold off remuxing this recording in case it's of further use - it was actually done purely for test purposes so it isn't one that either myself or my wife want to watch on the MVP any time soon.

[mvallevand]

Could you d/l the dongle and try again, it looks like there are some issues getting the pts as the file starts. This will ignore those < 90k for now to see if it helps.

Also if you find the timeline after resume is off you may need to adjust one of these, I'm not sure what they do or what values work

Code:

<PreResumeDelay>500</PreResumeDelay>
    <ResumeStartupDelay>0</ResumeStartupDelay>

Martin

[bgowland]

Could you d/l the dongle and try again, it looks like there are some issues getting the pts as the file starts. This will ignore those < 90k for now to see if it helps.

Thanks - it's now showing a sensible timeline from the start which has solved the subject of this particular thread.

I'm still seeing some skipping issues but that may well be simply that the pts is broken in the recording elsewhere. I haven't had a chance to look much further but I've saved a log file to look at more closely tomorrow when I have time.

Thanks again.