Recording Skipping Straight to End

One of the shows I set up for a season pass is skipping straight through to the end after being played. It says that it is 60min long and shows the commercial breaks, etc but when played only the first and last few seconds display. This happened on two recordings of the same show on the same channel. One of the recordings plays normally so basically 2/3 don’t play any content beyond the start and end when played normally. If I tell it to rewind from the end it goes back to the beginning. The commercial skipping option doesn’t make any difference if it’s on or off.

Here’s the weirdest thing. If I pause first, advance the recording a minute or so and THEN play the show plays just fine...? So the content is clearly all there. If I then rewind back to the start and press play - same skip to the end result. What could be going on to cause this behavior?

I submitted diagnostic logs if helpful.

Did you record them from TVE or an HDHomerun?

My tuner is an HDHomeRun Extend with transcoding turned off in the sever settings. I did notice on this particular channel if I had the transcoding turned on for the tuner the video would be choppy so I left it off (is that a common thing? I was surprised the built in transcoding on the extend could mess up the signal quality that bad) - might as well use the original stream anyways for the best quality. The videos play normally if I do the skip ahead trick without any choppiness, etc. The problem happens on my Apple TV, iPhone and Shield players.

Yes. You did pick the preferred setting by disabling transcoding.

For the recording that is having problems, it may be resolved by running "Fix Video Timestamps" on the recording. Would you try that?

I don't see that option in my pulldown - I only have a subset of what your screenshot shows...? Also, it is multiple recordings now that are exhibiting this same behavior as I keep adding more to my library from the pass - all of them are from the same show on the same channel (the one that plays more choppy when streamed live if I have transcoding on for the tuner).

Same story with every recording - if I play from the start after a few seconds it jumps to the end, if I manually skip forward a bit right away the content plays normally. However, I did notice that it doesn't seem like the commercials are getting indexed correctly for these recordings either - it is missing sections throughout the recordings. This has been fairly spot on for my other recordings. That let me to go into edit commercials and something funky definitely seems to be going on - look at these very long timestamps right at the start. Also, the summary is all weird - says the show is 20hrs long with 19hrs cut. What could cause the DVR to behave this way? I tried to upload the com log file referenced on the recording but I don't see a way to do that via the forum (says uploads have to be images). I will email it to the support email address.

I haven't noticed it happen on other shows from other channels that I have passes set up for - seems unique to this one show pass.

So I was able to figure out how to get the timestamp option up by doing a long click server update. That made the video's playable such that they didn't skip right to the end, however, the commercial indexing is still off and if I go into edit commercials I see a big swing plus and minus on the order of 18hrs right at the start. The summary has the right time though. Running the redetect commercials command removed the big swing timestamps but the indexing is still not right - basically its keeping a lot of the commercials as part of the show (breaks are shorter than they should be).

Where do we go from here and any thoughts as to why every new recording of this show is coming in so messed up?

It may take some time for the redetection to finish, but once it does it should fix the commercial break detection.

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:

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 :smile:

Ah ok, I guess we will see which way I got lucky as more recordings accumulate :slight_smile:

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.