Recording Skipping Straight to End

[mjodotcom]

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.

Yea, its almost like the problem has gotten worse because before running the fix-timestamps command plus redetect commercials (now one in the same) resolved the bad timestamp issues. Now, when running that command it seems to either erase the shows content or create NEW jumping issues than the one at the beginning that was typical and discussed above (the recordings today did this). Did you recently change how this is done on the backend at all?

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?

Can't power this one any other way since its a portable external USB. FWIW and for future reference I did reach out to Nvidia about this and they replied directly that the USB ports have a dedicated 10W power supply (at least on the 2019 version) so thankfully drop outs should be a non issue for that particular configuration.

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.

I appreciate the transparency here and glad to hear you are working on ways to improve it going forward. it does seem to work well for a majority of the shows I record, just some seem to consistently give it more trouble for whatever reason.

For now I guess my best course of action is to abandon the season pass for the show on this channel that has been giving me such a hard time, at least until further improvements are made on resolving timestamp problems. Please keep me in the loop as you learn more since you mentioned you plan to be putting some other more automated fixes in place in the future for issues like this.

Thanks for all the support thus far.

[eric]

Did you recently change how this is done on the backend at all?

We haven’t changed anything regarding this. I think it may have just been a fluke that it happened to work on the recordings before we ran the commercial redetection automatically. There’s nothing destructive about running the commercial detection. Unfortunately there’s just no good solution to getting great playback when there were reception issues.

I appreciate you working with me and providing the log messages for these different recordings. We’ve added these log messages and Fix Timestamps operations as a way to better understand situation where it would make sense to provide better feedback to users and potentially automatically fix things. Hearing real-world situations helps us better see what we can do going forward.

I did reach out to Nvidia about this and they replied directly that the USB ports have a dedicated 10W power supply (at least on the 2019 version)

That’s great news.

For now I guess my best course of action is to abandon the season pass for the show on this channel that has been giving me such a hard time, at least until further improvements are made on resolving timestamp problems.

Unfortunately there’s very little we’ll ever be able to do to get a good result out of a recording that suffered from reception issues. Without a good clean signal it is very difficult to play or do most other operations on the file. Your best solution is to work on your antenna placement to try to improve the situation.

[mjodotcom]

Unfortunately there’s very little we’ll ever be able to do to get a good result out of a recording that suffered from reception issues. Without a good clean signal it is very difficult to play or do most other operations on the file. Your best solution is to work on your antenna placement to try to improve the situation.

The channel of particular concern does show up as a questionable in range one based on antenna web, so I think thats the best its going to be given my other signals are solid.

I did watch the shows live yesterday while the DVR was recording and for the most part the quality was fine. A stutter here or there but nothing majority bad with it. However, the recordings still both had timestamp issues - one of which was resolved by fixing, one that was made worse (added a bunch of time to the end).

It is a little odd to me that signal quality would cause timestamps to be buggy and incorrect, especially when the feed was still more or less perfectly watchable in real time - wouldn't it just mean the video quality would suffer?. What causes this to be the case?

[eric]

MPEG-TS has a very simple mechanism for detecting corrupted packets and so often will be unable to tell that due to reception issues a packet was wrong. With these corrupted packets, it is getting garbage for the bytes that specify the timestamp for the packet.

When comskip sees these out-of-order timestamps, it does the best it can to understand them, but they are nonsense, so there isn't really a "correct" way of handling them.

When our Fix Timestamps sees these out-of-order timestamps, it tries to understand their meaning, but if they jump around randomly it eventually gives up and doesn't fix them. The goal of the Fix Timestamps tool is to fix a basic kind of timestamp issue where different MPEG-TS streams are spliced together. It wasn't originally written to recover MPEG-TS streams that were corrupted due to reception issues. For recordings with these sorts of problems, it would be better not to try to use the Fix Timestamps on them and just accept that the commercial detection isn't going to work.

[mjodotcom]

Thanks for the helpful and detailed response. Is there any way to turn off commercial detection / auto skip for a particular show vs having it be a system wide setting? That would be useful both in this instance and dealing with other problematic shows where comskip struggles so I wouldn’t break that feature for the rest of my recordings but could still use the “buggy” recordings like you described (otherwise with it on comskip gets confused and jumps to the end, etc).

[eric]

You can disable it per-show when you view the show details:

[mjodotcom]

I see that setting is within the show but not on the recording pass. Does the setting establish a rule for any past and future recordings of that particular show as well so I don't have to update it every time?

[eric]

Yeah, that's just an artifact of how the DVR UI is. It will be for any recording for that show.

[mjodotcom]

Ok cool - thanks again!

[mjodotcom]

So I tried this out and apparently Channels still gets confused by the bad timestamps, even when I don't have detect commercials on. It just hops right to the end of the recording. Is this expected behavior? Thought it could be a decent workaround.

[eric]

What does the duration show on these recordings?

[mjodotcom]

It says 1hr or 1hr 1min, depending on where you look. However, if I actually pause the video right before it ends after it skips it is saying it is at 1079min out of 60min.

[MERCEDESDVR]

Has his issue been addressed i am currently experiencing the same issue. I'm running a linux server and was wondering if that could be the problem? Maybe the file type?

[eric]

Please post a screenshot of the Recording Details from the DVR for the recording having problems.

[MERCEDESDVR]

log has been submitted 3b548d38-93fb-4886-9b78-e0b7e2d5033e

[eric]

What is the name of the recording you are having issues with?

[MERCEDESDVR]

It was 90 Day Fiancé The Other Way S02E02

[eric]

It doesn't appear you are having the same issue.

What client are you using? Please submit Diagnostics from the client after you've experienced this issue to help us track down what's going on.