Recording Skipping Straight to End

So for the recordings today, it seems like how much this timestamp error can occur does vary. One recording this morning only jumped forward and backwards 18min. The other one, 25 hours. In both cases the TOTAL air time wasn't significantly off. So it seems that you couldn't go off of total air time alone for a fix, you would have to look for maybe odd jumps forward followed immediately by jumps backwards. That behavior seems consistent across all of the bad recordings. Pictures attached - this is before running any sort of post recording corrections.

Interestingly, trying to play the recordings today from my phone to check out the behavior on the one that had the minus timeframe checked vs unchecked crashed out my iPhone app and also seems to have crashed the server (I cannot access it remotely on either my phone for the web). Before it would just jump to the end. Seems like this bug can be nastier than previously thought...

Do I need to be physically at the Shield to restart the server? It has been down for several minutes now. I submitted diagnostics from the iPhone app for review.

image

It does sound like it crashed and you'll need to restart the service on your Shield. Once you've done that, if you could go to the Logs tab on the DVR and send us the full output we can see why it crashed.

Ok bummer - I won’t be able to restart it for a few days. Kind of scary that just playing the bad files is crashing the server now. Hopefully you guys can figure out a fix soon!

Yes, that definitely shouldn’t happen. We have a lot of protections in place to prevent that from happening, but there may have been something that slipped through the cracks.

Just got back home. The server was shut down so I had to re-enable it within the DVR server app on the Shield (Shield was otherwise working normally).

I don't see any option to upload logs for the server and you can't attach text files, so I have copied below the timing around the crash event. Sorry in advance for the long text field...

Let me know what else I can do and what errors you find that could have crashed the server. Any update on a fix for the commercial timestamp bug?

2020/01/31 12:00:07.903970 [DVR] Recording for job 1580493600-15 from 1059D86A ch8.6 into "TV/Law & Order/Law & Order S03E11 1993-01-06 Extended Family 2020-01-31-1200.mpg" for 59m52.660471585s
2020/01/31 12:00:07.914042 [IDX] Generating video index for job 1580493600-15
2020/01/31 12:00:08.454021 [DVR] Running commercial detection on file 40 (TV/Law & Order/Law & Order S03E10 1992-12-09 Consultation 2020-01-31-1100.mpg)
2020/01/31 12:13:59.081615 [DVR] Commercial detection for Law & Order S03E10 1992-12-09 Consultation 2020-01-31-1100.mpg finished with 8 markers.
2020/01/31 12:22:33.133751 [ENC] Starting encoder for Law & Order S03E09 1992-11-25 Point of View 2020-01-31-1000.mpg in /storage/5146C2C31CCC7C89/NVIDIA_SHIELD/Channels DVR/Streaming/file39-b01d71c063ae-566887079/encoder-0-991881585 at 0 (0.000000) (encoder=h264_mediacodecndk, resolution=720, deinterlacer=blend, bitrate=3000 segment_size=0.01)
[mpegts @ 0x2f244c4600] Dropped corrupted packet (stream = 0)
[hls @ 0x2f244c5200] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
2020/01/31 12:22:51.610529 [ENC] Segment 5 has unexpected duration: inputs=5 expected=1.001 actual=1061.145367 expected_pts=5.005000-6.006000 actual_pts=5.459156-1066.571156
2020/01/31 12:23:50.125510 [ENC] Stopped encoder for Law & Order S03E09 1992-11-25 Point of View 2020-01-31-1000.mpg in /storage/5146C2C31CCC7C89/NVIDIA_SHIELD/Channels DVR/Streaming/file39-b01d71c063ae-566887079/encoder-0-991881585 after encoding 0 to 5
2020/01/31 12:23:54.921401 [ENC] Starting encoder for Law & Order S03E10 1992-12-09 Consultation 2020-01-31-1100.mpg in /storage/5146C2C31CCC7C89/NVIDIA_SHIELD/Channels DVR/Streaming/file40-b01d71c063ae-276958273/encoder-0-559637019 at 0 (0.000000) (encoder=h264_mediacodecndk, resolution=720, deinterlacer=blend, bitrate=3000 segment_size=0.01)
[mpegts @ 0x21bb0c4600] Dropped corrupted packet (stream = 0)
[hls @ 0x21bb0c4c00] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
2020/01/31 12:24:03.523231 [ENC] Encoder stopped for Law & Order S03E10 1992-12-09 Consultation 2020-01-31-1100.mpg in /storage/5146C2C31CCC7C89/NVIDIA_SHIELD/Channels DVR/Streaming/file40-b01d71c063ae-276958273/encoder-0-559637019 after encoding 0 to 2
2020/01/31 12:24:03.779618 [ENC] Starting encoder for Law & Order S03E10 1992-12-09 Consultation 2020-01-31-1100.mpg in /storage/5146C2C31CCC7C89/NVIDIA_SHIELD/Channels DVR/Streaming/file40-b01d71c063ae-276958273/encoder-3-531311654 at 3 (2.002000) (encoder=h264_mediacodecndk, resolution=720, deinterlacer=blend, bitrate=3000 segment_size=0.01)
[mpegts @ 0x30778c4600] Dropped corrupted packet (stream = 0)
Last message repeated 6 times
[hls @ 0x30778c4c00] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
2020/01/31 12:24:10.721140 [SYS] Starting Channels DVR v2020.01.31.0227 (android-arm64 pid:29791) in /data/data/com.getchannels.dvr/files/channels-dvr/data
2020/01/31 12:24:11.235427 [HDR] Found 1 devices
2020/01/31 12:24:11.770850 [SYS] Started HTTP Server
2020/01/31 12:24:11.955761 [DVR] Recording engine started in /storage/5146C2C31CCC7C89/NVIDIA_SHIELD/Channels DVR
2020/01/31 12:24:11.956978 [SYS] Bonjour service running for dvr-shield.local. [10.0.1.39]
2020/01/31 12:24:11.971584 [DVR] Starting job 1580493600-15 Law & Order on ch=[8.6]
2020/01/31 12:24:11.971664 [DVR] Waiting 4h5m48.028361302s until next job 1580509800-8 Jeopardy!
2020/01/31 12:24:12.021028 [NAT] Successfully mapped port 8089 using natpmp
2020/01/31 12:24:12.239927 [SYS] Created database snapshot: backup-20200131.122412
2020/01/31 12:24:12.487462 [TNR] Opened connection to 1059D86A/0 for ch8.6 WZCK-LD
2020/01/31 12:24:12.621463 [DVR] Recording for job 1580493600-15 from 1059D86A ch8.6 into "TV/Law & Order/Law & Order S03E11 1993-01-06 Extended Family 2020-01-31-1200.mpg" for 35m48.028293438s
2020/01/31 12:24:12.889346 [ENC] Starting encoder for Law & Order S03E10 1992-12-09 Consultation 2020-01-31-1100.mpg in /storage/5146C2C31CCC7C89/NVIDIA_SHIELD/Channels DVR/Streaming/file40-b01d71c063ae-974258959/encoder-16-375412514 at 16 (15.015000) (encoder=h264_mediacodecndk, resolution=720, deinterlacer=blend, bitrate=3000 segment_size=0.01)
[mpegts @ 0x238f4c4600] Dropped corrupted packet (stream = 0)
Last message repeated 6 times
[hls @ 0x238f4c4c00] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
2020/01/31 12:24:15.601853 [ENC] Segment 15 has unexpected duration: inputs=15 expected=1.001 actual=1.935267 expected_pts=15.015000-16.016000 actual_pts=92908.590978-92910.526244
2020/01/31 12:24:16.402931 [ENC] Segment 16 has unexpected duration: inputs=16 expected=1.001 actual=1.968633 expected_pts=16.016000-17.017000 actual_pts=92910.559611-92912.494878
2020/01/31 12:24:16.501649 [ENC] Request for 3 is lower than current start segment of 16
2020/01/31 12:24:16.512602 [ENC] Stopped encoder for Law & Order S03E10 1992-12-09 Consultation 2020-01-31-1100.mpg in /storage/5146C2C31CCC7C89/NVIDIA_SHIELD/Channels DVR/Streaming/file40-b01d71c063ae-974258959/encoder-16-375412514 after starting from 16 without encoding any segments
2020/01/31 12:24:16.519966 [ENC] Starting encoder for Law & Order S03E10 1992-12-09 Consultation 2020-01-31-1100.mpg in /storage/5146C2C31CCC7C89/NVIDIA_SHIELD/Channels DVR/Streaming/file40-b01d71c063ae-974258959/encoder-3-146940441 at 3 (2.002000) (encoder=h264_mediacodecndk, resolution=720, deinterlacer=blend, bitrate=3000 segment_size=0.01)
[mpegts @ 0x22e34c4600] Dropped corrupted packet (stream = 0)
Last message repeated 6 times
[hls @ 0x22e34c4c00] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
2020/01/31 12:24:22.297334 [SYS] Starting Channels DVR v2020.01.31.0227 (android-arm64 pid:29894) in /data/data/com.getchannels.dvr/files/channels-dvr/data
2020/01/31 12:24:22.814615 [HDR] Found 1 devices
2020/01/31 12:24:23.803326 [SYS] Started HTTP Server
2020/01/31 12:24:24.051654 [DVR] Recording engine started in /storage/5146C2C31CCC7C89/NVIDIA_SHIELD/Channels DVR
2020/01/31 12:24:24.053741 [SYS] Bonjour service running for dvr-shield.local. [10.0.1.39]
2020/01/31 12:24:24.061135 [DVR] Starting job 1580493600-15 Law & Order on ch=[8.6]
2020/01/31 12:24:24.061274 [DVR] Waiting 4h5m35.938767401s until next job 1580509800-8 Jeopardy!
2020/01/31 12:24:24.102639 [NAT] Successfully mapped port 8089 using natpmp
2020/01/31 12:24:24.352145 [SYS] Created database snapshot: backup-20200131.122424
2020/01/31 12:24:24.566024 [ENC] Starting encoder for Law & Order S03E10 1992-12-09 Consultation 2020-01-31-1100.mpg in /storage/5146C2C31CCC7C89/NVIDIA_SHIELD/Channels DVR/Streaming/file40-b01d71c063ae-287721925/encoder-10-806873696 at 10 (9.009000) (encoder=h264_mediacodecndk, resolution=720, deinterlacer=blend, bitrate=3000 segment_size=0.01)
2020/01/31 12:24:24.651165 [TNR] Opened connection to 1059D86A/0 for ch8.6 WZCK-LD
2020/01/31 12:24:24.652245 [DVR] Recording for job 1580493600-15 from 1059D86A ch8.6 into "TV/Law & Order/Law & Order S03E11 1993-01-06 Extended Family 2020-01-31-1200.mpg" for 35m35.938632244s
[mpegts @ 0x2f8a4c4600] Dropped corrupted packet (stream = 0)
Last message repeated 6 times
[hls @ 0x2f8a4c4c00] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
2020/01/31 12:24:26.776451 [ENC] Segment 9 has unexpected duration: inputs=9 expected=1.001 actual=1.935267 expected_pts=9.009000-10.010000 actual_pts=92908.590978-92910.526244
2020/01/31 12:24:27.582070 [ENC] Segment 10 has unexpected duration: inputs=10 expected=1.001 actual=1.968633 expected_pts=10.010000-11.011000 actual_pts=92910.559611-92912.494878
2020/01/31 12:24:27.661638 [ENC] Segment 11 has unexpected duration: inputs=11 expected=1.001 actual=1.968633 expected_pts=11.011000-12.012000 actual_pts=92912.528244-92914.463511
2020/01/31 12:24:28.130614 [ENC] Request for 3 is lower than current start segment of 10
2020/01/31 12:24:28.149159 [ENC] Segment 12 has unexpected duration: inputs=12 expected=1.001 actual=1.051044 expected_pts=12.012000-13.013000 actual_pts=92914.496878-92915.531244
2020/01/31 12:24:28.160473 [ENC] Stopped encoder for Law & Order S03E10 1992-12-09 Consultation 2020-01-31-1100.mpg in /storage/5146C2C31CCC7C89/NVIDIA_SHIELD/Channels DVR/Streaming/file40-b01d71c063ae-287721925/encoder-10-806873696 after encoding 10 to 13
2020/01/31 12:24:28.166697 [ENC] Starting encoder for Law & Order S03E10 1992-12-09 Consultation 2020-01-31-1100.mpg in /storage/5146C2C31CCC7C89/NVIDIA_SHIELD/Channels DVR/Streaming/file40-b01d71c063ae-287721925/encoder-3-243976255 at 3 (2.002000) (encoder=h264_mediacodecndk, resolution=720, deinterlacer=blend, bitrate=3000 segment_size=0.01)
[mpegts @ 0x2442cc4600] Dropped corrupted packet (stream = 0)
Last message repeated 6 times
[hls @ 0x2442cc4c00] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
2020/01/31 12:24:33.652362 [SYS] Starting Channels DVR v2020.01.31.0227 (android-arm64 pid:29991) in /data/data/com.getchannels.dvr/files/channels-dvr/data
2020/01/31 12:24:34.164769 [HDR] Found 1 devices
2020/01/31 12:24:34.674980 [SYS] Started HTTP Server
2020/01/31 12:24:34.858864 [DVR] Recording engine started in /storage/5146C2C31CCC7C89/NVIDIA_SHIELD/Channels DVR
2020/01/31 12:24:34.860920 [SYS] Bonjour service running for dvr-shield.local. [10.0.1.39]
2020/01/31 12:24:34.873876 [DVR] Starting job 1580493600-15 Law & Order on ch=[8.6]
2020/01/31 12:24:34.874070 [DVR] Waiting 4h5m25.125952665s until next job 1580509800-8 Jeopardy!
2020/01/31 12:24:34.908283 [NAT] Successfully mapped port 8089 using natpmp
2020/01/31 12:24:35.098536 [SYS] Created database snapshot: backup-20200131.122434
2020/01/31 12:24:35.367063 [TNR] Opened connection to 1059D86A/0 for ch8.6 WZCK-LD
2020/01/31 12:24:35.422949 [DVR] Recording for job 1580493600-15 from 1059D86A ch8.6 into "TV/Law & Order/Law & Order S03E11 1993-01-06 Extended Family 2020-01-31-1200.mpg" for 35m25.12585579s
2020/01/31 12:24:35.518483 [ENC] Next segment to pre-encode of 14 is 2.002s from the last request of 12
2020/01/31 12:24:35.537773 [ENC] Starting encoder for Law & Order S03E10 1992-12-09 Consultation 2020-01-31-1100.mpg in /storage/5146C2C31CCC7C89/NVIDIA_SHIELD/Channels DVR/Streaming/file40-b01d71c063ae-172420680/encoder-14-284663047 at 14 (13.013000) (encoder=h264_mediacodecndk, resolution=720, deinterlacer=blend, bitrate=3000 segment_size=0.01)
2020/01/31 12:24:35.718613 [ENC] Request for 4 is lower than current start segment of 14
2020/01/31 12:24:35.723200 [ENC] Stopped encoder for Law & Order S03E10 1992-12-09 Consultation 2020-01-31-1100.mpg in /storage/5146C2C31CCC7C89/NVIDIA_SHIELD/Channels DVR/Streaming/file40-b01d71c063ae-172420680/encoder-14-284663047 after starting from 14 without encoding any segments
2020/01/31 12:24:35.730906 [ENC] Starting encoder for Law & Order S03E10 1992-12-09 Consultation 2020-01-31-1100.mpg in /storage/5146C2C31CCC7C89/NVIDIA_SHIELD/Channels DVR/Streaming/file40-b01d71c063ae-172420680/encoder-4-433217722 at 4 (3.003000) (encoder=h264_mediacodecndk, resolution=720, deinterlacer=blend, bitrate=3000 segment_size=0.01)
[mpegts @ 0x27398c4600] Dropped corrupted packet (stream = 0)
Last message repeated 6 times
[hls @ 0x27398c4c00] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
2020/02/02 16:36:14.010924 [SYS] Starting Channels DVR v2020.01.31.0227 (android-arm64 pid:28716) in /data/data/com.getchannels.dvr/files/channels-dvr/data
2020/02/02 16:36:14.530948 [HDR] Found 1 devices
2020/02/02 16:36:15.106682 [SYS] Started HTTP Server
2020/02/02 16:36:15.286617 [DVR] Recording engine started in /storage/5146C2C31CCC7C89/NVIDIA_SHIELD/Channels DVR
2020/02/02 16:36:15.288819 [SYS] Bonjour service running for dvr-shield.local. [10.0.1.39]
2020/02/02 16:36:15.324881 [DVR] Marking expired job 1580493600-15 Law & Order
2020/02/02 16:36:15.328579 [DVR] Marking expired job 1580509800-8 Jeopardy!
2020/02/02 16:36:15.330738 [DVR] Marking expired job 1580513400-1 NBC Nightly News With Lester Holt
2020/02/02 16:36:15.336193 [DVR] Marking expired job 1580517000-9 Wheel of Fortune
2020/02/02 16:36:15.338417 [DVR] Marking expired job 1580529600-6 15 News at 10
2020/02/02 16:36:15.341062 [DVR] Marking expired job 1580599800-1 NBC Nightly News With Lester Holt
2020/02/02 16:36:15.343356 [DVR] Marking expired job 1580603400-4 Discover Wisconsin
2020/02/02 16:36:15.345418 [DVR] Marking expired job 1580612400-3 Saturday Night Live
2020/02/02 16:36:15.347383 [DVR] Marking expired job 1580616000-2 NBC 15 News at 10
2020/02/02 16:36:15.349241 [DVR] Marking expired job 1580617740-3 Saturday Night Live
2020/02/02 16:36:15.351284 [DVR] Marking expired job 1580657400-5 Face the Nation
2020/02/02 16:36:15.353159 [DVR] Waiting 53m44.646859637s until next job 1580686200-1 NBC Nightly News With Lester Holt
2020/02/02 16:36:21.415918 [NAT] Successfully mapped port 8089 using natpmp
2020/02/02 16:36:21.523082 [SYS] Created database snapshot: backup-20200202.163621
2020/02/02 16:36:25.417765 [IDX] Pruned 2482 expired airings from USA-OTA53575 in 113.245156ms.

Do you see anything in the logs that says panic?

I do not - and a search for the word "panic" comes up empty. I think I was watching the show on my phone when the server crashed so I can send those logs along as well.

It's weird, the server logs just stop with this entry being the last one until I restarted it this afternoon. It does say the error was repeated six times and there is mention of bad time stamps and a code fix being needed (it was recording the show we have been having issues with).

Also, kind of off topic but I wonder why the encoder is being used if I have the transcoded off?

"2020/01/31 12:24:35.730906 [ENC] Starting encoder for Law & Order S03E10 1992-12-09 Consultation 2020-01-31-1100.mpg in /storage/5146C2C31CCC7C89/NVIDIA_SHIELD/Channels DVR/Streaming/file40-b01d71c063ae-172420680/encoder-4-433217722 at 4 (3.003000) (encoder=h264_mediacodecndk, resolution=720, deinterlacer=blend, bitrate=3000 segment_size=0.01)
[mpegts @ 0x27398c4600] Dropped corrupted packet (stream = 0)
Last message repeated 6 times
[hls @ 0x27398c4c00] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly"

Are there any other logs I can look at or send you? I just clicked "log" next to my account on the server website interface.

So it does look like recordings with the large positive then negative timestamp sections are continuing to come in reported at 1hr 1min total duration, and once the fix timestamps + commercial detection is ran they report at 60 minutes so maybe your idea of rerunning those automatically if the duration is off vs the guides airtime could work. It also looks like there is always a big forward jump (of varying duration as noted above) followed by a jump backwards, so maybe you could key off of that as well - look for a negative time segment (which wouldn’t make sense) and rerun if detected.

When you have the next recording that has issues could you go to View Details and see what the Duration is listed as there?

Here is the view details vs summary noted in the commercial editor for the two that recorded today (both have issues as you can see by the timestamps):

image

image

image

image

The plot thickens...today when running the fix timestamps command on the recordings, it seems to have completely broken them - to the point that almost of all the content was erased from the recording...? That used to make the recordings watchable but both recordings from today are now more or less wiped clean.

Do they play? Is the issue just with the commercial detection or did it mess up the recording entirely?

They do not play any longer than the few seconds shown. Running the fix timestamps again didn’t help either - seems like the recordings got messed up entirely.

Can you check the logs from when they were recorded and send what they said? We report statistics and other info about the recording.

Which logs do you need? Comskip logs?

The DVR logs. Also the DVR logs from when you ran the rewrite timestamps.

I don't see anything out of the ordinary with the recording:

2020/02/10 11:00:00.014090 [DVR] Starting job 1581354000-15 Law & Order on ch=[8.6]
2020/02/10 11:00:00.014215 [DVR] Waiting 59m59.985791403s until next job 1581357600-15 Law & Order
2020/02/10 11:00:00.417056 [TNR] Opened connection to 1059D86A/1 for ch8.6 WZCK-LD
2020/02/10 11:00:00.419176 [DVR] Recording for job 1581354000-15 from 1059D86A ch8.6 into "TV/Law & Order/Law & Order S04E03 1993-10-06 Discord 2020-02-10-1100.mpg" for 59m59.985741871s
2020/02/10 11:00:00.426821 [IDX] Generating video index for job 1581354000-15
2020/02/10 11:00:00.459424 [TNR] Closed connection to 1059D86A/0 for ch57.4 BOUNCE
2020/02/10 11:00:00.470565 [SNR] Statistics for "TV/Law & Order/Law & Order S04E02 1993-09-29 Volunteers 2020-02-10-1000.mpg": ss=97%-99% snq=100% seq=100% bps=1358112,770048-3140352 pps=136,91-298
2020/02/10 11:00:00.507865 [DVR] Finished job 1581350400-15 Law & Order
2020/02/10 11:00:00.544277 [DVR] Waiting 59m59.455733122s until next job 1581357600-15 Law & Order
2020/02/10 11:00:00.574776 [DVR] Processing file-90: TV/Law & Order/Law & Order S04E02 1993-09-29 Volunteers 2020-02-10-1000.mpg
2020/02/10 11:00:01.557113 [DVR] Running commercial detection on file 90 (TV/Law & Order/Law & Order S04E02 1993-09-29 Volunteers 2020-02-10-1000.mpg)
2020/02/10 11:03:58.933111 [DVR] Commercial detection finished with 10 markers.

Not sure what to make of the timestamps statistics. You can see the commercial detection marker changed from 10 on the original recording to 2 after running the command. It also references some errors and discontinuities

2020/02/10 13:38:00.601498 [MTS] Rewriting MPEG-TS timestamps for file-91: Law & Order S04E03 1993-10-06 Discord 2020-02-10-1100.mpg
2020/02/10 13:43:41.864298 [MTS] Statistics for "Law & Order S04E03 1993-10-06 Discord 2020-02-10-1100.mpg": skipped=187 unhandled_packets=110203 discontinuity_detected=220413 transport_errors=27 invalid_pts=0 invalid_dts=0 saw_pcr=true saw_pmt=true highest_pts=56.804244
2020/02/10 13:43:42.583125 [MTS] Finished video index generation for file-91 in 341s
2020/02/10 13:43:43.289401 [IDX] Generating video index for file-91: Law & Order S04E03 1993-10-06 Discord 2020-02-10-1100.mpg
2020/02/10 13:44:15.393199 [IDX] Finished video index generation for file-91 in 32s
2020/02/10 13:44:15.408489 [DVR] Running commercial detection on file 91 (TV/Law & Order/Law & Order S04E03 1993-10-06 Discord 2020-02-10-1100.mpg)
2020/02/10 13:56:08.523131 [DVR] Commercial detection finished with 2 markers.

This is saying that there were a lot of corrupted packets in the recording. It is surprising that the signal quality has high for the entire recording of the other one:

If you could include the SNR statistics for the S04E03 or the MTS statistics for the S04E02 we could match them up to confirm that it had good signal quality and lots of issues with the file.

The only other issue I can think of is if there are problems with the drive you’re recording into. Do you have the drive attached to its own power source?

Interesting. When tuning to the channel this AM the quality seems just fine, however, a few days ago the signal was just gone on that channel and the show didn't record at all so not sure what exactly that is all about. Maybe that channel comes in a little more flaky than others? Here is the info you requested - I don't have the MTS for episode 2 because I recorded that on a different channel (a non-HD .X one that is broadcasting the same feed) for comparison and it didn't require redoing timestamps but do have it for episode 4 along with the SNR for that one. Apparently the non-HD channel quality is a lot better at least signal quality wise. Could the questionable signal quality explain the huge timestamp jump errors?

2020/02/10 12:00:00.405308 [SNR] Statistics for "TV/Law & Order/Law & Order S04E03 1993-10-06 Discord 2020-02-10-1100.mpg": ss=53%,20%-54% snq=67%,57%-69% seq=100% bps=4427776,4132992-5291072 pps=421,394-503

2020/02/10 14:07:55.300419 [MTS] Statistics for "Law & Order S04E04 1993-10-13 Profile 2020-02-10-1200.mpg": skipped=935 unhandled_packets=112862 discontinuity_detected=225416 transport_errors=66 invalid_pts=0 invalid_dts=0 saw_pcr=true saw_pmt=true highest_pts=90478.025067

2020/02/10 13:00:00.013844 [SNR] Statistics for "TV/Law & Order/Law & Order S04E04 1993-10-13 Profile 2020-02-10-1200.mpg": ss=53%,20%-54% snq=67%,55%-69% seq=100%,85%-100% bps=4427776,3764512-5291072 pps=421,357-503
2020/02/10 13:00:00.052866 [DVR] Finished job 1581357600-15 Law & Order

I wouldn't think the drive would have problems since it is more or less brand new. It is a portable drive (so only powered via the USB on the NVIDIA Shield) but I do leave the Shield on all the time without letting it sleep. Other recordings haven't had any issues with timestamps or missing content, though some programs do seem to do worse than others as it relates to commercial detection. Wheel of fortune for example (toddler favorite lol) frequently incorrectly indexes commercial breaks.

Definitely. Anything with an a seq= less than 100% (if a range is shown after the first number, that indicates the minimum and maximum values that were found) will indicate a problem with the stream and a snq= less than 80% will likely mean there were some issues with the recording.

This can become an issue — when the Shield starts using more CPU power it can reduce the amount that can go to the drive and can cause the drive to have issues. Does your drive have a way to be powered separately?

We know there are issues with our commercial detection — we don’t expect it to be 100% accurate at the moment and do know it does better with some shows than others. It’s an area that we would like to improve, but don’t have anything to report in that direction at this time.