Do we know why it's rewriting timestamps

Channels DVR Server Troubleshooting
#1

[MTS] Rewriting video timestamps for file-7452: Quantum Leap S02E08 Nomads 2023-12-13-1959.mpg

No interruptions, good signal and network stats.

Log 
2023/12/13 19:59:30.001190 [DVR] Starting job 1702526370-688 Quantum Leap on ch=[703]
2023/12/13 19:59:30.507960 [TNR] Opened connection to 1323AADB/0 for ch703 KCRADT
2023/12/13 19:59:30.534352 [DVR] Recording for job 1702526370-688 from 1323AADB ch703 into "TV/Quantum Leap/Quantum Leap S02E08 Nomads 2023-12-13-1959.mpg" for 1h2m29.998649577s
2023/12/13 19:59:30.828260 [IDX] Generating video index for job 1702526370-688
2023/12/13 21:02:00.001782 [TNR] Closed connection to 1323AADB/0 for ch703 KCRADT
2023/12/13 21:02:00.157974 [SNR] Signal statistics for "TV/Quantum Leap/Quantum Leap S02E08 Nomads 2023-12-13-1959.mpg": ss=97%-98% snq=100% seq=100% bps=6733454,2863616-6928928 pps=576,245-594
2023/12/13 21:02:00.353068 [SNR] Buffer statistics for "TV/Quantum Leap/Quantum Leap S02E08 Nomads 2023-12-13-1959.mpg": buf=0% drop=0%
2023/12/13 21:02:00.398905 [DVR] Finished job 1702526370-688 Quantum Leap
2023/12/13 21:02:00.518984 [DVR] Processing file-7452: TV/Quantum Leap/Quantum Leap S02E08 Nomads 2023-12-13-1959.mpg
2023/12/13 21:02:03.182540 [MTS] Rewriting video timestamps for file-7452: Quantum Leap S02E08 Nomads 2023-12-13-1959.mpg
2023/12/13 21:02:35.558409 [MTS] Statistics for #7452 "Quantum Leap S02E08 Nomads 2023-12-13-1959.mpg": discontinuity_detected=1 transport_errors=0 saw_pcr=true saw_pmt=true highest_pts=3753.321178
2023/12/13 21:02:37.104996 [MTS] Finished rewriting video timestamps for file-7452 in 33s
2023/12/13 21:02:38.320215 [IDX] Generating video index for file-7452: TV/Quantum Leap/Quantum Leap S02E08 Nomads 2023-12-13-1959.mpg
2023/12/13 21:02:38.501939 [DVR] Running commercial detection on file 7452 (TV/Quantum Leap/Quantum Leap S02E08 Nomads 2023-12-13-1959.mpg)
2023/12/13 21:03:10.990323 [IDX] Finished video index generation for file-7452 in 32s
2023/12/13 21:17:52.793137 [DVR] Commercial detection for Quantum Leap S02E08 Nomads 2023-12-13-1959.mpg finished with 14 markers in 15m14.43229247s.
Stats 
"SignalStats": {
  "SS": {
    "Initial": 97,
    "Last": 97,
    "Min": 97,
    "Max": 98,
    "Sum": 182624,
    "GoodCount": 1871,
    "BadCount": 0
  },
  "SNQ": {
    "Initial": 100,
    "Last": 100,
    "Min": 100,
    "Max": 100,
    "Sum": 187100,
    "GoodCount": 1871,
    "BadCount": 0
  },
  "SEQ": {
    "Initial": 100,
    "Last": 100,
    "Min": 100,
    "Max": 100,
    "Sum": 187100,
    "GoodCount": 1871,
    "BadCount": 0
  },
  "BPS": {
    "Initial": 2863616,
    "Last": 6625120,
    "Min": 2863616,
    "Max": 6928928,
    "Sum": 12598293600,
    "GoodCount": 1871,
    "BadCount": 0
  },
  "PPS": {
    "Initial": 245,
    "Last": 568,
    "Min": 245,
    "Max": 594,
    "Sum": 1078629,
    "GoodCount": 1871,
    "BadCount": 0
  },
  "TSERR": {
    "Initial": 0,
    "Last": 0,
    "Min": 0,
    "Max": 0,
    "Sum": 0,
    "GoodCount": 1871,
    "BadCount": 0
  },
  "NETERR": {
    "Initial": 0,
    "Last": 0,
    "Min": 0,
    "Max": 0,
    "Sum": 0,
    "GoodCount": 1871,
    "BadCount": 0
  },
  "DVRBUF": {
    "Initial": 0,
    "Last": 0,
    "Min": 0,
    "Max": 0,
    "Sum": 0,
    "GoodCount": 0,
    "BadCount": 0
  },
  "DVRDROP": {
    "Initial": 0,
    "Last": 0,
    "Min": 0,
    "Max": 0,
    "Sum": 0,
    "GoodCount": 0,
    "BadCount": 0
  },
  "STREAMTIMEOUT": {
    "Initial": 0,
    "Last": 0,
    "Min": 0,
    "Max": 0,
    "Sum": 0,
    "GoodCount": 0,
    "BadCount": 0
  },
  "Grade": {
    "GoodCount": 1871,
    "BadCount": 0
  },
  "NetworkGrade": {
    "GoodCount": 1871,
    "BadCount": 0
  },
  "SignalGrade": {
    "GoodCount": 1871,
    "BadCount": 0
  },
  "StreamGrade": {
    "GoodCount": 1871,
    "BadCount": 0
  }
},
"BufferStats": {
  "BufferPct": {
    "Initial": 0,
    "Last": 0,
    "Min": 0,
    "Max": 0,
    "Sum": 0,
    "GoodCount": 0,
    "BadCount": 1874
  },
  "BufferDrop": {
    "Initial": 0,
    "Last": 0,
    "Min": 0,
    "Max": 0,
    "Sum": 0,
    "GoodCount": 1874,
    "BadCount": 0
  }
},
#2

If the duration of the MPEG-TS file is more than twice as long as the recording should be based on how long we recorded, we assume that there was something bad in the incoming MPEG-TS stream, and we rewrite it to make sure it's playable. Sometimes this happens because the broadcast encoder restarts in the middle of a recording. Other times because the MPEG-TS timestamps rolled over in the middle.

Make backup of recording before rewriting video timestamps
#3

Is there any way I can disable rewriting timestamps for my HDHR Prime recordings?
I remuxed this recording that had it's timestamps rewritten with ffmpeg and it spewed out hundreds of errors while remuxing.

#4

There currently is not a way to disable rewriting in this case. We added this after an extensive number of support issues that all were related to this specific symptom and all resolved by rewriting.

The rewriter reported no errors and only had to re-calculate the PTS once (discontinuity_detected=1). This leads me to believe that any errors you see from ffmpeg came from the original source, not from the rewriter.

What is a sample of the errors you're seeing from ffmpeg?

1 Like
#5

Too big to post it all, but here's a sample, where ... is the part I had to remove to fit in the post

from ffmpeg remux log 
[mpegts @ 0000029c4928ddc0] Stream 3, codec scte_35, is muxed as a private data stream and may not be recognized upon reading.
[mpegts @ 0000029c491d5640] PES packet size mismatch
[mpegts @ 0000029c491d5640] Packet corrupt (stream = 0, dts = 4534092).
[mpegts @ 0000029c491d5640] PES packet size mismatch
[mpegts @ 0000029c491d5640] Packet corrupt (stream = 2, dts = 4335902).
    Last message repeated 5 times
[mpegts @ 0000029c491d5640] PES packet size mismatch
[mpegts @ 0000029c491d5640] Packet corrupt (stream = 1, dts = 4335902).
    Last message repeated 5 times
...
[mpegts @ 0000029c4928ddc0] Non-monotonous DTS in output stream 0:1; previous: 145255414, current: 145255320; changing to 145255415. This may result in incorrect timestamps in the output file.
[mpegts @ 0000029c4928ddc0] Non-monotonous DTS in output stream 0:2; previous: 145255414, current: 145255320; changing to 145255415. This may result in incorrect timestamps in the output file.
[mpegts @ 0000029c491d5640] PES packet size mismatch
[mpegts @ 0000029c491d5640] Packet corrupt (stream = 0, dts = 156948354).
[mpegts @ 0000029c491d5640] PES packet size mismatch
[mpegts @ 0000029c491d5640] Packet corrupt (stream = 1, dts = 156727862).
    Last message repeated 5 times
...
[mpegts @ 0000029c4928ddc0] Non-monotonous DTS in output stream 0:2; previous: 242132783, current: 242131429; changing to 242132784. This may result in incorrect timestamps in the output file.
[mpegts @ 0000029c4928ddc0] Non-monotonous DTS in output stream 0:1; previous: 242132783, current: 242131429; changing to 242132784. This may result in incorrect timestamps in the output file.
[mpegts @ 0000029c491d5640] PES packet size mismatch
[mpegts @ 0000029c491d5640] Packet corrupt (stream = 0, dts = 337783891).
[mpegts @ 0000029c491d5640] PES packet size mismatch
[mpegts @ 0000029c491d5640] Packet corrupt (stream = 1, dts = 337570371).
    Last message repeated 2 times
[mpegts @ 0000029c491d5640] PES packet size mismatch
[mpegts @ 0000029c491d5640] Packet corrupt (stream = 2, dts = 337570371).
    Last message repeated 2 times
video:2690253kB audio:263461kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 4.137752%

I've already cut ads out and overwrote the recorded file.
I would just like to disable rewriting timestamps on my HDHR Prime source only.
I was under the impression that only HLS streams had their timestamps rewritten, I don't want my HDHR recordings messed with. If there are issues with the .ts stream, my video editor can find and fix them.

#6

Rewriting the PTS/DTS timestamps would not have caused the PES packet issue. It looks like the recording was corrupted before it hit the DVR and thus wasn't going to be recoverable regardless. We are very conservative on when and how we decide to rewrite timestamps, but in situations like this, we would prefer to make the timestamps contiguous vs having confusing durations and seek issues.

#7

OK, Thanks.
I ended up transferring that episode from my TiVo, cutting the ads and overwriting the Channels DVR recording with it.

#8

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.