Skipping issue on PCH

[bgowland]

Thanks, I have it and I'm playing it now. The quality is better than my high bit rate analog recording ever where and the 16:9 flag is set too. I'm jealous.

Yep, UK DVB-T has always been pretty good even in SD and when they do show old programmes they're correctly flagged as 4:3 too. One of the reasons I like the PCH as it handles the aspect ratios correctly - I had to juggle the MVP to get a good aspect ratio and even then it was never quite right with 16:9.

I'm going offline now so I'll check in later.

[mvallevand]

Ok I will try again in the morning, because the timeline was near perfect as was skiping with the Timing.Info you provided earlier tonight. The jump to ~650 which I wanted to see did not go negative.

Code:

011-09-11 01:04:20.943    [DEBUG][3]    Reported PTS now:25180200  time: 559.56
2011-09-11 01:04:21.686    [DEBUG][3]    User pressed: Right
2011-09-11 01:04:21.703    [DEBUG][7]    requestedPositionInSeconds: 649
2011-09-11 01:04:21.716    [DEBUG][3]    Raw PTS received:25255800
2011-09-11 01:04:21.716    [DEBUG][3]    Reported PTS now:25212600  time: 560.28
2011-09-11 01:04:21.756    [DEBUG][3]    OSD needs update. Hash now: Timeline:00:09:20:00:14:55~
2011-09-11 01:04:23.140    [DEBUG][3]    Raw PTS received:25257600
2011-09-11 01:04:23.141    [DEBUG][3]    Reported PTS now:25214400  time: 560.32
2011-09-11 01:04:24.163    [DEBUG][3]    Raw PTS received:29257200
2011-09-11 01:04:24.163    [DEBUG][3]    Reported PTS now:29214000  time: 649.2

Martin

[mvallevand]

I could not duplicate any problems in that file. The only anomaly I could find is that NPVR in your logs did not request the correct seek in Timing.Info

Code:

2011-09-10 23:19:40.646    [DEBUG][7]    requestedPositionInSeconds: 650
2011-09-10 23:19:40.646    [DEBUG][7]    Set position to:144422719
2011-09-10 23:19:40.646    [DEBUG][7]    Received request to seek to pos:144422719
2011-09-10 23:19:40.646    [DEBUG][7]    RollingFile.Seek(144422719)
2011-09-10 23:19:40.646    [DEBUG][7]    RollingFile.Position returning 144422719

when I try here repeatedly I get

Code:

2011-09-11 13:10:45.084    [DEBUG][7]    requestedPositionInSeconds: 650
2011-09-11 13:10:45.084    [DEBUG][7]    Set position to:152259324
2011-09-11 13:10:45.084    [DEBUG][7]    Received request to seek to pos:152259324
2011-09-11 13:10:45.084    [DEBUG][7]    RollingFile.Seek(152259324)
2011-09-11 13:10:45.084    [DEBUG][7]    RollingFile.Position returning 152259324
...
2011-09-11 13:10:46.660    [DEBUG][3]    Raw PTS received:29264400
2011-09-11 13:10:46.660    [DEBUG][3]    Reported PTS now:29253600  time: 650.08

Martin

[bgowland]

Looking at that timestamp (23:19) that was my wife's attempt to try to restart watching the recording after it had dropped back to the Recordings menu. This is all part of the strange behaviour - I find I have to use Unwatch then Play and then sometimes Stop, Play again before it will properly start the recording from the beginning. At that point, I can then enter XX (minutes) and skip back to where I was when it dropped out.

[mvallevand]

I was just showing a bug in NPVR, as I said without the client side (mvpmcx2) I don't have a lot to go on. Do you have your EPG update set for ~11pm by any chance?

Martin

[bgowland]

I was just showing a bug in NPVR

Yes, fair enough.

as I said without the client side (mvpmcx2) I don't have a lot to go on.

Is there anything I can do to provide data from the PCH? Does it maintain a logfile of some sort that I can retrieve next time it happens?

Do you have your EPG update set for ~11pm by any chance?

No, 7am specifically because that's a time when npvr is likely to be idle.

[Sheik Yerbouti]

I've been seeing some skipping problems lately too. I've attached some logs. On the PCH I saw a timeline that starts with a large negative number, something we've had in the past, but I can't reproduce it. On the PC it seems fine. I hope the logs help.

Chris

[mvallevand]

Chris, your logs are different, it looks like NPVR is asking for the NMT to seek before it has finished prebuffering. mvpmcx2 has some safeguards against this but something might have changed in NPVR. I would need the client putty.log to help more.

Martin

[mvallevand]

Is there anything I can do to provide data from the PCH? Does it maintain a logfile of some sort that I can retrieve next time it happens?

Although I prefer logging via telnet, If your mvpmc share is writeable you can change the redirect > /dev/null in nbpvr.cgi to point to a file ie > /etc/mvpmc/name.txt

No, 7am specifically because that's a time when npvr is likely to be idle.

I can see the likely start of the problem and the stop it generated. The best explanation is that resume was not selected from the recordings menu. I thought the db may have been locked.

Martin

[bgowland]

Although I prefer logging via telnet, If your mvpmc share is writeable you can change the redirect > /dev/null in nbpvr.cgi to point to a file ie > /etc/mvpmc/name.txt

Yes, I setup a local user for the share which has full control. Looking at the npvr.cgi I can only see one line with redirects...

Code:

sh -c /etc/mvpmc/startmeup 2>/dev/null >/dev/null &

...assuming that's the correct line, should I change both /dev/null entries to point to a log file?