Latest DVR v2019.04.27.0504 H264 recording remux gets stuck playing in web browser


#1

Play starts normally and runs until 11 minutes, 33 seconds, then shows buffering circle and is displaying Remux Paused: 11m35.190211s @ 1.55x

Looking at http://x.x.x.x:8089/hls, it thinks the view position is at 8 minutes, 44 seconds, but it's actually at 11 minutes, 33 seconds.

OutPosition "11m35.190211s"
ViewPosition "8m55s" ACTUALLY 11m33s
Speed "1.55x"
Finished false
StartedAt "2019-04-27T12:43:13.514642449-07:00"
LastActive "2019-04-27T12:54:52.571677257-07:00"
Started true
Stopped false
Paused true
FileProgressDuration 0


#2

More info, this is happening using Safari on iOS v12.1.4 and now iOS v12.2 (iPod and iPadPro) and Mozilla Firefox v66.03 (Windows PC) on multiple (3 so far) H.264 recordings streamed locally (in home). The transcoder pauses and the player tries to play past the pause point and freezes. Something must be wrong with the elapsed time math as the play time on the player doesn't match the hls streaming info from the DVR at http://x.x.x.x:8089/hls

So far all 3 recordings (1hr H.264 720p) I've tried exhibit this at different times during playback.

H.264 LiveTV and Mpeg2 recordings/LiveTV work fine.

Update: a fourth H.264 recording does not exhibit the freeze, but the "ViewPosition " in the hls Streaming web page is way off (too far ahead of reality).

Let me know if you want me to upload a recording that exhibits the problem.


#3

Another one tonight after updating to the latest pre-release 2019.04.28.2113

Started remux playback of H.264 720p recording in browser at 19:22:30
No skipping forward or backward or commercial skipping, just letting it play.
Playback was normal until 19:34:07 at which time the playback froze at a playback time of 11:37

hls streaming info is wrong, showing view position at 09:00

OutPosition "11m38.643667s"
ViewPosition "9m0s"
Speed "1.54x"
Finished false
StartedAt "2019-04-28T19:22:30.126638332-07:00"
LastActive "2019-04-28T19:34:34.322904554-07:00"
Started true
Stopped false
Paused true
FileProgressDuration 0

logfile shows inaccuracy in view time

2019/04/28 19:22:30 [HLS] Starting transcoder for file1265-ip192.168.1.2 at 0s from 192.168.1.2 (encoder=remux, resolution=1080, deinterlacer=hardware, bitrate=10000)
[mpegts @ 0x23e6100] start time for stream 3 is not set in estimate_timings_from_pts
[mpegts @ 0x23e6100] start time for stream 4 is not set in estimate_timings_from_pts
[mpegts @ 0x23e6100] start time for stream 5 is not set in estimate_timings_from_pts
[mpegts @ 0x23e6100] Dropped corrupted packet (stream = 1)
[mpegts @ 0x23e6100] Dropped corrupted packet (stream = 2)
2019/04/28 19:22:59 [HLS] Pausing transcoder (out: 6m14.169511s, view: 1m10s)... 00:29 ACTUAL VIEWTIME
2019/04/28 19:26:17 [HLS] Resuming transcoder (out: 6m14.169511s, view: 3m45s)... 03:47 ACTUAL VIEWTIME
2019/04/28 19:26:29 [HLS] Pausing transcoder (out: 8m57.015533s, view: 3m53s)... 03:59 ACTUAL VIEWTIME
2019/04/28 19:29:51 [HLS] Resuming transcoder (out: 8m57.015533s, view: 6m28s)... 07:21 ACTUAL VIEWTIME
2019/04/28 19:30:04 [HLS] Pausing transcoder (out: 11m38.643667s, view: 6m37s)... 07:34 ACTUAL VIEWTIME

At this point the only way to get the player working again is to pause, stop and choose to resume watching.

And then it fails again in the same way after playing an additional 11 minutes from where it froze the first time, so resuming from 11:37 and freezing again at 22:43.


#4

This is related to Unpredictable skipping/fast forward during remote playback of recordings