Latest NPVRTSReader4 Resume crashes NPVR

[Lao Pan]

Using all the latest patches (I think) Most of the time trying to resume a recording causes NPVR to lock up with no remote control input - only thing to get out of it is a double mouse click then the NPVR is not responding message and killing the program.

The B version TSReader4 (Now in the latest installer) that you gave me did not have the problem only versions since then.

In the attached log I restarted the recording service and cleared the logs - went straight to the recording and tried to resume.
The file in use message appears to be incorrect - is that the problem? Nothing was using it.

2017-09-04 06:50:31.670 [DEBUG][1] PlaybackPositionHelper.GetPlaybackPosition(E:\Video Recordings\Murdoch Mysteries\Murdoch Mysteries_20170902_20002100.ts)
2017-09-04 06:50:31.684 [DEBUG][1] Playing video file: E:\Video Recordings\Murdoch Mysteries\Murdoch Mysteries_20170902_20002100.ts
2017-09-04 06:50:31.890 [DEBUG][1] MESSAGE:
2017-09-04 06:50:31.890 [DEBUG][1] 1337
2017-09-04 06:50:31.919 [DEBUG][1] Using 'NPVR TS Reader 4'
2017-09-04 06:50:31.931 [DEBUG][1] File in use. Maybe still recording.
2017-09-04 06:50:31.940 [DEBUG][1] Timing.info reports duration 3898609ms

[sub]

Was this a file that was still recording?

[Lao Pan]

Was this a file that was still recording?

No it had finished about 36 hours previously.
Restarted recording service just before this attempt (checked there were no ndigital host processes running)

Just noticed the logs didn't upload - I'll have to do another attempt in about 9 hours time - unfortunately about 25 miles away from the machine now, work got in the way.

[sub]

I've finished up for the day, but will try to take a look at the morning to see if I can reproduce.

[Lao Pan]

No it had finished about 36 hours previously.
Restarted recording service just before this attempt (checked there were no ndigital host processes running)

Just noticed the logs didn't upload - I'll have to do another attempt in about 9 hours time - unfortunately about 25 miles away from the machine now, work got in the way.

Here is another attempt this evening same file same resume point same outcome -logs definately attached this time

[gEd]

Sub

FWIW, I also see the file in use message as well. Here is playback from the F1 grand prix yesterday

The reason I was looking at this as when playing back the recording yesterday, it decided during playback of the the show that it was only 1h7m long and refused to play beyond that point so I had to quit NPVR and use VLC to watch the remainder of the show. I'm poking around to try and find some meaningful evidence to share (in a different post).

2017-09-04 23:05:16.151 [DEBUG][1] Playing video file: R:\Recordings\Formula 1 Motor Racing\Formula 1 Motor Racing_20170903_17452000.ts
2017-09-04 23:05:17.368 [DEBUG][1] Using 'NPVR TS Reader 4'
2017-09-04 23:05:17.386 [DEBUG][1] File in use. Maybe still recording.
2017-09-04 23:05:17.448 [DEBUG][1] Timing.info reports duration 8336366ms
2017-09-04 23:05:17.448 [DEBUG][1] RenderDemux()
2017-09-04 23:05:17.460 [DEBUG][1] Adding system H264 decoder

[Lao Pan]

Sub


The reason I was looking at this as when playing back the recording yesterday, it decided during playback of the the show that it was only 1h7m long and refused to play beyond that point so I had to quit NPVR and use VLC to watch the remainder of the show. I'm poking around to try and find some meaningful evidence to share (in a different post).

Also had this happen today. Recorded Exodus Gods and Kings on Sunday night which should have been about 2hrs 53 mins long, timeline showed 1 hr 36 mins. In the attached NPVR Log 2 at 20:10 Approx - wife tried to skip adverts resulting in end of film and much anger :eek:

I have now removed ads in Videoredo and it will play through to the end 2 hrs 20 mins on timeline. (Rebuilds ts file and also removes timing info)

I also noticed there were a large amount of resync packets removed - about 70 video and 240 audio- unfortunately the logs for the recording time have long rolled over.

[Petrovski]

The latest reader is OK for me except when the recording has glitches then it can give behaviour as you describe. I had a new recording that gave your symptoms that played OK when I switched back to old reader. So IMO new reader is less tolerant of dirty streams.

[Lao Pan]

The latest reader is OK for me except when the recording has glitches then it can give behaviour as you describe. I had a new recording that gave your symptoms that played OK when I switched back to old reader. So IMO new reader is less tolerant of dirty streams.

I agree, the old Microsoft demux filter used to just pause for half a second on a glitch where as the new one sometimes goes back and repeats, then slows down the video to resync with audio - or more annoying the picture freezes, the audio continues until 20 or 30 seconds later NPVR crashes. I'm hoping with our help Sub can improve resilience over time.

Unfortunately the signal here is far from perfect - no aerials allowed (which is stupid as most houses have a sky dish) - so loft aerial pointing through neighbors roof space.

[gEd]

I have a roof aerial and am about 4 miles from the Crystal Place transmitter and have not had any recording glitches for many years.
I ran the formula 1 recording mentioned above through TSdoctor and it reported some warnings which is normal but no specific errors. I don't have Videoredo available to try this instead. hummm...
So I'm feeling skeptical that the problem I experienced was because of the new reader being sensitive to glitches but I need to play around some more to find some specific evidence of a problem.