4.0.4 Skips Hang Playback

[jrockow]

That work around did not work for me.
I had to go back to 3.9.2 to get rid of the problem.
Shame; I really hated to give up the CCs in H.264.

[ccihon]

I can concur - even using legacy reader/MS demux setting, playback often hangs on skip. I have it occurring randomly with either setting on my two clients. In my case, I am using comskip and auto-skipping, and find the freezes seem to occur on the first "skip forward" of a commercial block. I actually think I saw it happening more often with the legacy setting rather than the new reader. Was not an issue with previous version.

Separately, I am using legacy on a Win 10 client that uses wireless AC as the new reader caused stuttered playback on that machine - that is not an issue on the client attached via gigabit wired - but it is also a more powerful machine. Both machines are experiencing random playback locking on skips.

[pBS]

i still haven't gotten a single lockup w new reader while just watching..and not while skipping if i skip out of lockup quick enough.. an extra skip fixes it every time so far..

[sub]

I've attached a diagnostic tool which will give us some insight into what is happening. It shows things like stream types and clocks in the new reader.

You need to start the tool before starting NextPVR. Initially, I'd probably want to see what output its giving you after starting playback for a few seconds, then a single skip.

[HarryH3]

Hi sub, I shut down NextPVR and installed the tool.
Started the tool.
Started NPVR.
Tried to watch a recording and it hung on the first skip.
Hope this data helps! :-)

(Hangs are happening here regardless of the check box for the new .ts reader since I installed 4.0.4)

SOURCE: F:\GB-PVR Video\NCIS Los Angeles\NCIS.Los.Angeles.S08E24.Unleashed.ts
STARTED: 19:26:29.301
MPEG2: PID 225 (0xe1)
AC3: PID 226 (0xe2)
PCR: 1415877970224
STREAM_TIME: 7629
FILE_POSITION: 150268776
FILE_LENGTH: 9118379760
m_tStart: 481682318125
PES_MPEG2: PTS 4719618228 (sample time 25525.500000ms)
VIDEO_DIFF: 17899.500000ms
SEGMENT_START: 47785.889478 seconds
PES_AC3: PTS 4718995814 (sample time 18609.788889ms)
AUDIO_DIFF: 18115.788889ms
LAST_SEEK_REQUESTED: 89.000000 seconds

[sub]

I'm having trouble as well. But it's a whole mixed bag of problems.

I'll try to break it down:

With new reader and demux:
- ffdshow decoder fails to connect. see FFDSHOWlog.rar
- using Lav or MS DTD, I get no subtitles. See LAV-MS Log.rar
- Trying to watch a recorded show from SyFy Channel (h.264), I get a huge delay, over 30 seconds, in which time the Processor goes up to 50% usage, and the video storage disk stays at 80% read utilization. it will then finally begin to play the show. I can only surmise it's seeking through the whole 2 gigs of video for some reason. but oddly this doesn't happen on any other shows from any other channels. Only Syfy. See HugeSeek Logs.rar

Using Legacy Reader and Demux:
- If I go back to ffdshow decoder, I do indeed get subtitles on h.264! Yay! But of course I have to use legacy reader/demux. I still do not get subtitles with Lav or MSDTD using legacy. (I didn't provide logs of that but i could if needed) I also don't see the huge seek on SYFY shows with legacy reader/demux. I Suspect if ffdshow would work with the new reader/demux, I would have subtitles there also. See Legacyh264withSubtitles log.rar

Hope this helps.

Edit: also after additional testing, I found I can watch a show live with legacy reader/demux, and ffdshow, and see subtitles on h.264 shows. But if I record that same show, and then play back the recording, there's no subtitles in the recording. Even with same reader/demux/decoder setting. So not sure what that means.

All of the included logs were from Live TV, with the exception of the set about a large Seek.

Give this patch a go - it resolves the issue I was seeing with your Syfy recording.

For specific details, it looks like your is related to your capture device delivering a "MPTS" PAT. ie, it's got headers for all the channels, rather than just the channel we've captured the audio/video for. The new reader wasn't correctly dealing with this, and wasn't sure which channel within the recording it should be looking at. This version quickly determines this is the case, and probes for the presence of the audio/video streams for each channel to determine which one is the correct one to play. Playback now starts quick, and skipping is also quick.

Others can try the patch too, but I'm not sure your problem is the same or not. Volfin's sample recording really helped with getting to the bottom of his issue.

[volfin]

Give this patch a go - it resolves the issue I was seeing with your Syfy recording.

Yep, that seems to resolve the large seek I was seeing on SyFY (and later I realized on a few other channels). Nice work, thanks

And Yeah, it's incredibly snappy on the seeks, I love it

[sub]

Yep, that seems to resolve the large seek I was seeing on SyFY (and later I realized on a few other channels). Nice work, thanks

And Yeah, it's incredibly snappy on the seeks, I love it

Great!

[ccihon]

so far the patch solves my issues I think - a little early to tell - I added patched reader and set both of my clients to use the new reader - so far no skip hangs - monitoring, but the stuttery behavior, especially the audio, on the one machine connected wirelessly has seems to clear up with the patch also.

[pBS]

In stats program, i'm noticing the video diff shoot up after skip to double the audio diff when in normal playback the audio diff is usually roughly 1000 and video diff around 300...
after bad skip, video diff jumps to 2000 and slows to let audio catch up...
i did notice 1 discontinuity was found..didn't seem to affect anything.
also sometimes the audio diff will go negative while video diff goes to 2000+ then audio slowly catches up..

all this time while out of sync, audio plays without slowing or discontinuity..video always slows to wait for audio which is playing normally..

not sure if any of that helps so let me know if anything else will help.

SOURCE: T:\tv\The Ryen Russillo Show_20170728_12131500.ts
STARTED: 12:13:39.833
H264: PID 4049 (0xfd1)
AC3: PID 4050 (0xfd2)
PCR: 1363156746094
STREAM_TIME: 300860
FILE_POSITION: 352102944
FILE_LENGTH: 354915236
m_tStart: 4986965031062
PES_AC3: PTS 4543739856 (sample time 301971.088889ms)
AUDIO_DIFF: 1082.088889ms
PES_H264: PTS 4543672040 (sample time 301217.577778ms)
VIDEO_DIFF: 329.577778ms
SEGMENT_START: 389.868922 seconds
LAST_SEEK_REQUESTED: 388.000000 seconds
DISCONTINUITY: Discontinuity noted at 12:16:42.359 (H264)


after out of sync skip:

SOURCE: T:\tv\The Ryen Russillo Show_20170728_12131500.ts
STARTED: 12:13:39.833
H264: PID 4049 (0xfd1)
AC3: PID 4050 (0xfd2)
PCR: 1362885678150
STREAM_TIME: 2729
FILE_POSITION: 346995736
FILE_LENGTH: 406211036
m_tStart: 4990954096065
PES_AC3: PTS 4542746255 (sample time 2826.600000ms)
AUDIO_DIFF: 93.600000ms
PES_H264: PTS 4542763633 (sample time 3019.688889ms)
VIDEO_DIFF: 278.688889ms
SEGMENT_START: 677.973400 seconds
LAST_SEEK_REQUESTED: 677.000000 seconds
DISCONTINUITY: Discontinuity noted at 12:16:42.359 (H264)


after syncing:
SOURCE: T:\tv\The Ryen Russillo Show_20170728_12131500.ts
STARTED: 12:13:39.833
H264: PID 4049 (0xfd1)
AC3: PID 4050 (0xfd2)
PCR: 1364309915480
STREAM_TIME: 55453
FILE_POSITION: 373778968
FILE_LENGTH: 433504876
m_tStart: 4990954096065
PES_AC3: PTS 4547570256 (sample time 56426.611111ms)
AUDIO_DIFF: 1103.611111ms
PES_H264: PTS 4547511376 (sample time 55772.388889ms)
VIDEO_DIFF: 312.388889ms
SEGMENT_START: 677.973400 seconds
LAST_SEEK_REQUESTED: 677.000000 seconds
DISCONTINUITY: Discontinuity noted at 12:16:42.359 (H264)