Here are some images - it is still missing chucks of the commercials after doing the redetect command (and calling the start of the show a commercial), but the weird huge 60,000 second stuff is gone from the timestamps now after doing it.
What are the next steps to fix this recording going forward, and what could cause the DVR to think the show is 20hrs long?
Also for reference, this is how the shows look post fixing timestamps but pre redoing commercials. They actually play instead of jumping to the end with the timestamp fix (maybe because the second large time chuck is auto-selected now vs not selected in the images I sent yesterday), however, the large timestamps within the commercial editor remain. The summary doesn't say 20hr though like it does pre-timestamp fix.
What does the video indexing command do? Also, today I noticed that for whatever reason I have the same channel ("bounce") on my guide for two different channels, 8.6 and 57.4. When I looked at the series pass on the web client it had both channels listed for the recording (the same content is played on both channels). However, in my DVR only one recorded shows up from one channel (8.6). I wonder if Channels was getting confused by this somehow? I turned off the other station from the tuner but the alternate channel still showed up on the series pass so I manually told it to only do channel 8.6. Will report back on how the recordings look in the morning when the next ones hit.
Could you try unselecting the first two segments, saving them, leaving the commercial editor, and going back again to see if that fixes that issue?
Interestingly, the show on the pass that I recorded today (after eliminating the dual channel thing I mentioned yesterday) seem to have mapped the commercials perfectly, however, the large jumps were still in the start of the timeline so the show would jump right to the end.
De-selecting the early sections of the recording with the large timestamp via edit commercials as you suggested also makes the shows play without having to do the fix timestamps or re-detect commercials. However it doesn't seem to completely stick because if I go back into re-edit the commercials the negative 80,000-15s timestamp is still unchecked but the positive 0-80,000 is reselected on its own...? They still play ok though.
Is there a way I can force this deselection going forward to happen automatically, or does the application learn that thats how I want to treat this show? Would certainly prefer to not have to manually go into each recording to make them playable.
Any thoughts on what could be causing this odd timeline coding with this show every time?
I believe there is a setting you can pass to comskip to have it ignore a certain duration at the start and/end of a recording. However, the best place to check for that would be on their forum: http://www.kaashoek.com/comskip/
More information about using custom settings for the commercial detection program are here:
I see - seems complicated :). It's just so odd that this is the only program where this problem happens. Also odd that a re-detect commercials command fixes the timestamp issues...
I'm very confused by those big jumps after you re-ran the commercial detection.
In the next DVR pre-release coming out in a few minutes it will automatically run commercial detection after rewriting timestamps.
I recently ran into similar timestamp issues with the last 3 weeks of Doctor Who recordings and had to run the Timestamp Rewriting on them to fix the issue. We've talked internally and think that there are some things we can do to detect this kind of issue and automatically run Timestamp Rewriting on them after the recording has finished.
I'm not sure when we'll be able to release that change, but I'll let you know when we have.
Appreciate the continued support. To be clear, running the fix timestamps command doesn't resolve the huge timestamp values for me. I had to do a redetect commercials as well which then seems to fix the issue. I have typically done fix timestamps first though so I'm not sure if only doing redetect commercials would also work.
Perhaps a fix for it could be something on the order of look for any time chunks in the file that are super large (like 2+ hours positive or negative or something - the ones I have seen are even crazier at 16+ hours but maybe others have similar issues with smaller windows) and if detected automatically run a fix timestamps+redetect commercials sequence on the recording in the background?
Any thoughts on why unselecting the large time blocks via edit commercials doesn't seem to hold after saving? Not sure how magically the commercials are actually getting detected correctly now either (even after redetect with the previous recordings I had to go in and clean up some mistakes). Does the app learn from previous edits and adjust accordingly?
The latest pre-release build now will automatically re-run the commercial detection when you fix the timestamps.
You did need to do both.
We have not done this work yet, but we are going to check and see if the reported duration of the recording is different from the expected duration (based on how long the recording lasted) and if it's very different, we will automatically re-run the Timestamp Rewriter (which now will also re-detect commercials)
I would have expected re-running the commercial detection would have wiped out any commercial edits you had done, so the behavior that you saw was very confusing to me. I'm not completely sure why it did what it did in that case.
If you reload the browser window, does it change what is shown for the commercial breaks at all? I'm grasping at straws here but thought it could have to do with some bad client-side caching we may be doing.
No you are right - for any of the previous recordings I was talking about earlier in the feed if I do a re-detect commercials it does erase any edits I had made. My question was more around the fact that for the most recent few recordings of the same show the commercials seems to be detecting correctly now so I was wondering if the detector algorithm learns from previous manual edits to get better in the future, etc.
Also just FYI once the large timestamp sections are scrubbed from the recording any commercial edits seem to stick. Its just when they are present in the feed somewhere that they don't seem to stay unselected even after a save (this is in reference to your previous suggestion to uncheck them).
Nope. Our current commercial detection tool does not use any sort of re-enforced learning. It treats each new file as new. You must have just gotten lucky the other times 
Ah ok, I guess we will see which way I got lucky as more recordings accumulate 
Glad to hear you are going to work on a fix for this. Would the recording length toggle be sufficient? Not sure if every recording has displayed as ~18hrs off the bat or not, but recordings can still show up with the correct length but have the large timestamps in their commercial feed (as shown above after running fix timestamps only). Has that always been the case for your troubled recording? I'll see how the three recordings look tomorrow AM before touchup as well and report back.
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.
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.
