Issues With Recording Length

[tycrum]

Hello,
I noticed I've had an issue with recording the show Naked and afraid last one standing the last couple weeks. This week it recorded but it shows a length of 37 seconds. The log shows recording for 2 hours and the file size is almost 5gig. Last week I had the same type of issue but the length was 13 minutes although the file size was almost 6gig. The recording info isn't in the current log anymore for last week. I do notice issues in the log (unhandled packets and discontinuity) this week and can find where there was mention of such with discovery earlier but did not see what the resolution was.

--
2023/07/09 22:08:26.597792 [SNR] Buffer statistics for "TV\Naked and Afraid Last One Standing\Naked and Afraid Last One Standing S01E10 Legendary Showdown 2023-07-09-1959.mpg": buf=0% drop=0%
2023/07/09 22:08:26.617382 [MTS] Statistics for "TV\Naked and Afraid Last One Standing\Naked and Afraid Last One Standing S01E10 Legendary Showdown 2023-07-09-1959.mpg": skipped=0 unhandled_packets=808 discontinuity_detected=1047 transport_errors=0 invalid_pts=0 invalid_dts=0 saw_pcr=true saw_pmt=true highest_pts=4086.461144

I've only seen this problem in the last two weeks. I'm running on win10, Server version
2023.07.06.1740 Prerelease. I have run fix timestamps and regenerate video index on the files an nothing has changed. If you play the file in VLC, it says it's 37 seconds but continues to play beyond that point. If this seems to be related to the issues with discovery earlier, was there a resolution. If not, any ideas? Thanks

I've only had this issue on this particular show. Logs submitted 3209f85d-7b4d-4667-a031-78029009a072

[Rice]

Enable experimental mpeg rewrite at the bottom of your dvr page settings. I don’t think it will fix your existing recordings but will fix all future recordings.

EXPERIMENTAL: New MPEG-TS Rewriter for HLS (TVE)

Our TV Everywhere and M3u sources ingests HLS streams that require us to rewrite the timestamps of to normalize them to consistent timestamps. We've released a new mechanism for doing this rewriting that we are in the initial testing stages of. We hope that it will better be able to handle some of the issues that users have experienced with Discovery network based TVE channels. This new system should give us more flexibility to handle more kinds of feeds that caused us trouble in the past. If…

[TV_Ken]

@tycrum

I've only seen this problem in the last two weeks. I'm running on win10, Server version
2023.07.06.1740 Prerelease. I have run fix timestamps and regenerate video index on the files an nothing has changed. If you play the file in VLC, it says it's 37 seconds but continues to play beyond that point. If this seems to be related to the issues with discovery earlier, was there a resolution. If not, any ideas?

I'm having the same symptoms using Windows 10 Pro server and latest beta Channels. The time seems to only get messed up after the recording is finished. I thought it only happened when I had watched part of the program while it was still recording form Fox Business, but now it is happening on other programs as well. I lost 2 weeks in a row of Deadliest Catch on Discovery and they were not watched in progress.

[TV_Ken]

@Rice

Enable experimental mpeg rewrite at the bottom of your dvr page settings.

I will try this.

[chDVRuser]

The experimental rewriter is the solution.

To fix the older recordings I remux them with ffmpeg instead of using Fix Timestamps.
ffmpeg -i recording.mpg -c copy recording.ts
Then move the remuxed recording.ts file over the recording.mpg, replacing it.
A refresh metadata then displays the correct duration.

I created a Windows command script to do this.
I drag and drop the recorded.mpg file on it.

ffmpeg_remux.cmd

@ECHO OFF
ECHO ...
IF %1.==. GOTO USAGE
REM Change current working directory to where this command script resides
%~d0
CD %~p0
REM Use ffmpeg.exe to remux the recording to a new .ts file in the current directory
REM and redirect standard and error output to originalfilename_remux_log.txt
ECHO Remuxing %1
ffmpeg -i %1 -c copy "%~dp0%~n1.ts" > "%~n1_remux_log.txt" 2>&1
REM Move the remuxed file.ts so as not to overwrite the original
ECHO Remuxed %1
ECHO to file "%~dp0%~n1.ts"
ECHO Press Ctrl-C to keep remuxed file here, or to move it to original directory
PAUSE
MOVE /Y "%~dp0%~n1.ts" "%~dp1"
GOTO FINISHED

:USAGE
REM Need the fully qualified filename to remux
ECHO Drop a file to be remuxed on this command file

:FINISHED
PAUSE
EXIT

[TV_Ken]

@Rice

Enable experimental mpeg rewrite at the bottom of your dvr page settings. I don’t think it will fix your existing recordings but will fix all future recordings.

Yes, this is the fix! I've been sending in bug reports for over a month with no answer in sight. I have no idea what the "EXPERIMENTAL MPEG-TS Rewriter for HLS (TVE)" is. No idea what it does. No idea as to why I didn't need it in the past and need it now. I already deleted all of the bad recordings before I knew there was a way to fix them. Thank you very much for getting my system working again.

[tycrum]

Thank you, I'll turn that on.

[tycrum]

Thanks. I was able to recover my recordings. Appreciate the help!

[eric]

Thanks for following up. This gives us more confidence that this is the right fix for these issues.

[babsonnexus]

@chDVRuser

I created a Windows command script to do this.
I drag and drop the recorded.mpg file on it.

Win64 seems to hate the .com, so I changed it to a .bat and just used command prompt to put ffmpeg_remux.bat "C:\Path\To\File\filename.mpg". Worked like a charm, thanks much!

[chDVRuser]

Good catch, should be .cmd not .com
I changed my post to reflect that.

[chDVRuser]

After remuxing problem recordings to fix timestamp issues, I would perform these actions on them;

• Refresh Metadata (to display the new, correct duration)
• Regenerate Video Index (to rebuild the streaming index)
• Redetect Commercials (since timestamps have been changed)

Using the new rewriter should eliminate the need to ever do this again

[rss7]

Will I need to rerecord after turning on the experimental feature?

[chDVRuser]

Turning the feature on will prevent the issue from happening on future recordings. To fix your previous recordings, you can remux them with ffmpeg. See the topic thread above for more info.