This has happened a few times where a recording,, when playing it back, it will get stuck at a certain point and can't progress through it. On Fire TV playback, just gets stuck and can't FF / Rewind or stop. On the time tracker at the bottom, it will show where it is but just keeps spinning. When I try to play back on PC, I can jump over the bad part, but sometimes it will just completely stop and boot me out of the playback. I see nothing at all in the logs, so wondering if there is some way to troubleshoot. I have one video right now with this situation. In the past I've just deleted. Thanks in advance for any advice.
Can you try playing the same file on a computer with VLC and see if it has problems around the same time?
Which FireTV model? The hardware decoder on the FireTV devices can choke on signal issues. You can try changing Settings > Playback > Advanced > Video Decoder: Software
Finally you can check the Log tab of your DVR- scroll back to the time when the recording in question was created and look for the [SNR] line which will show if there were signal or networks issues at the time.
The Fire TV is Stick 4K. The setting was already on Video Decoder = Software.
I tried the show on Apple TV 4K and the same thing happened.
I tried on a computer with VLC (raspberry pi) and the video played fine, no issues that I could tell at all.
The log in the UI did not go back to 8/31 when the show was recorded. Is there a place in the file system (Windows 10) that I can find the full log file?
Thanks!
See the FAQ answer about it: https://getchannels.com/docs/getting-started/faqs/channels-plus/#how-can-i-view-more-of-the-channels-dvr-server-log
No matter what number I put after n, the number of lines displayed seems to stay the same. Anywhere else I can find the log file on the file system?
Using http://127.0.0.1:8089/admin/log?n=100000
Shows the same lines and having just http://127.0.0.1:8089/admin/og
Remove the /admin part
Thanks... my bad not following directions the first time.
For the show in question, there is no SNR entry. It shows starting & stopping recording and processing comskip, but no SNR entry. I see SNR entry for other shows. Must have been an internet issue?
Ah, I see. SNR is only present for OTA/HDHR recordings. I guess this was from TVE? Which channel?
Yes, TVE. It was TLC.
so. not sure if this is the same thing that happened to me....
I tired to play back a recording of Wheeler Dealers from Motortrend that recorded last night....I skip through the end of previous show, to start of actual show, and it just gets stuck, and will not skip any more, and if i went back, it would just play from the point i had first stopped at from first skip. backed out and tried again, selecting Resume, and same thing, start from the point it got stuck, but cant skip forward or back(it woudl just jump back to the part it got stuck at and play from there). Had to close out and press start from beginning and then it worked fine. even skipping back and forth. I did submit diags in the app. This is on Beta for Android tv on Shield....not a fire stick.
Sounds similar - as far as the getting stuck part and not being able to do anything expect restart the show. However, even after restart, still happens at certain points in the show.
I've noticed problems starting just a couple weeks ago, and all of the problems were with Discovery TVE feeds. The Discovery Networks channels are 6100 (OWN) to 6114 (MotorTrend), inclusive.
I believe this is related to how Discovery inserts ads and merged portions of their feeds together when generating their TVE streams; it's most likely a timestamp–related issue.
1 Like
yeah, I did notice some messages about timestamps coming up, so you might be onto something with that.
D:\DVR\Streaming\file986-ip192.168.1.27-958488193\encoder-58-095705568 at 58 (144.516793) (encoder=h264_nvenc, resolution=720, deinterlacer=blend, bitrate=3000 segment_size=0.01)
2020/09/01 21:29:00.411246 [ENC] Segment 271 has unexpected duration: inputs=442-444 expected=2.669333 actual=2.736066 expected_pts=642.205752-644.875085 actual_pts=642.139011-644.841700
2020/09/01 21:29:27.810030 [ENC] Segment 420 has unexpected duration: inputs=735-736 expected=1.633333 actual=1.7 expected_pts=967.755350-969.388683 actual_pts=967.688678-969.355344
2020/09/01 21:29:44.057615 [HLS] ffmpeg: file986-ip192.168.1.27: [mpegts @ 00000000024dc180] DTS 428961344 < 8684361200 out of order
2020/09/01 21:29:44.570245 [HLS] ffmpeg: file986-ip192.168.1.27: [Parsed_aresample_0 @ 00000000029cca00] [SWR @ 0000000002522e00] Failed to compensate for timestamp delta of 181205.183729
2020/09/01 21:29:44.574235 [HLS] ffmpeg: file986-ip192.168.1.27: [Parsed_aresample_0 @ 00000000029cca00] [SWR @ 0000000002522e00] Failed to compensate for timestamp delta of 180657.685063
2020/09/01 21:29:44.592694 [HLS] ffmpeg: file986-ip192.168.1.27: Last message repeated 5 times
2020/09/01 21:29:44.592694 [HLS] ffmpeg: file986-ip192.168.1.27: [hls @ 00000000029d0980] Non-monotonous DTS in output stream 0:0; previous: 103817029, current: -2147483648; changing to 103817030. This may result in incorrect timestamps in the output file.
2020/09/01 21:29:44.601670 [HLS] ffmpeg: file986-ip192.168.1.27: [Parsed_aresample_0 @ 00000000029cca00] [SWR @ 0000000002522e00] Failed to compensate for timestamp delta of 180657.685063
2020/09/01 21:29:44.603665 [HLS] ffmpeg: file986-ip192.168.1.27: [hls @ 00000000029d0980] Non-monotonous DTS in output stream 0:0; previous: 103817030, current: -2147483648; changing to 103817031. This may result in incorrect timestamps in the output file.
2020/09/01 21:29:44.603665 [HLS] ffmpeg: file986-ip192.168.1.27: [Parsed_aresample_0 @ 00000000029cca00] [SWR @ 0000000002522e00] Failed to compensate for timestamp delta of 180657.856396
Fixing timestamps may help. To do this for an affected recording, in the web UI go to Recordings > Shows > All > Series > Episode > 
> Fix Video Timestamps. After that, try playing the recording in a client and see if it's improved. (Series and Episode are placeholders for the program name and particular episode you're having issues with.)
Most likely a Discovery issue with the ad inserts as rcameron says.
Sometines Fix timestamps helps, but mostly not.
My guess is they switch the feed to a feed that carries ads and the timestamps don't match and then it switches back to the program material and the timestamps don't match so you get these strange behaviors depending on what you use to view it.
Have been seeing this for a long time and have posted many times about it. Don't know if the devs can do anything about it.
Here's my latest post on the issue.
I tried fixing timestamps, it turned the hour long show into 4 hours and looks like it has even more problems now when trying to play back. Let's see if it happens again on anymore shows...
This was fixed
Great! I had tuned off comskip for any Discovery show. Seemed to help. But now I’ll try turning it back on with this fix in place.