For those of you seeing the VRD problem only on certain recordings, do those start on a commercial? One thing I've found that helps with that is to create basically just a rough trim to eliminate any potentially bogus frames at the start (set start and end points a few seconds outside the real ones for the show, making sure the start is set at actual programming and not an ad). Then, use Tools > Trim and Copy Source File, set to Use Selection markers, and save an intermediate file. Since this just straight byte copying without any processing, it doesn't have problems with any video changes. Then, load that file you just saved and do all the actual cuts on that and save it, and that has worked for me on everything so far. I also keep View > Display On-Screen Information enabled since it will display the resolution if it changes from whatever is at the start of the file, which is useful in making sure all the junk frames are removed. I have had a couple recordings drop from 1080p to 720p at commercial and never go back, and I just have to trash those and wait for a rerun.
Two of the three problem recordings that I've saved start recording during the closing credits of the previous show which in both cases was the same episode shown back to back. I pre-pad one minute and post pad three minutes on my recordings. My recordings are not displaying a resolution change in VideoRedo.
I've noticed more affinity towards streams that are not 29.97 fps having problems than anything else.
Not in my case either.
Appears to be something in the stream, either from the provider or from how ChannelsDVR captures the HLS streams from the provider into a .TS recording that mis-represents the true frame rate.
I'm keeping those 4 TVE test recordings I made in case the devs want more info on them.
They're either onto the problem or aren't responding to posts about it.
I'm only using TVE for one channel that's HD via TVE, where my Xfinity sub only has it in SD.
Any updates on this issue?
Another TVE recording where VideoRedo SaveAs or QuickStreamFix will remove either 3,369 or 85,950 audio resync frames depending on VRD Source frame rate option selected.
ch6108 (DIY) Building Off the Grid 1920x1080p @ 29.97
[MTS] Statistics for "TV/Building Off the Grid Killer Views/Building Off the Grid Killer Views 2018-06-26 2019-08-18-1100.mpg": skipped=0 unhandled_packets=0 discontinuity_detected=76 transport_errors=0 invalid_pts=0 invalid_dts=0 saw_pcr=false saw_pmt=true highest_pts=3683.336744
File plays in sync in VideoReDo.
VideoReDo Source frame rate "Automatic" and "Calculate" shows 29.97 fps and removes 3,369 audio resync frames.
VideoReDo Source frame rate "From Stream" and "From Container" shows 48000.00 fps and removes 85,950 audio resync frames.
@JJJJJ Recording begins during last minute of previous show and ends 1 minute into next show, so not beginning/ending on a commercial.
If I do my comm cuts and then save, it only removes about 40 audio resync frames (acceptable for me).
UPDATE: Redid my comm cuts making sure every frame that wasn't program material was cut out and now no audio resync frames removed. I also noticed the ts stream PCR is on the audio es stream pid in the recording and VRD puts the PCR on the video es stream pid when saving it. Still not sure exactly what is unusual with the recorded ts streams, but sure seems to have something to do with commercials, maybe video frame rate change like from 29.97 to 30 fps?
I still maintain my original theory.. it has to do with the providers inserting commercials of varying bitrates, frame rates, and resolutions in programs. VRD navigates them fine in the newer versions but if you pay attention when making cuts it is easy to identify the lower resolution commercials. They’re more blurry than usual and stand out in most cases. If you use a program like TS Doctor it clearly identifies these problem areas and tells you what the resolution drops to. Every instance of a drop is a commercial. The same issues occur if you capture a stream directly from WatchESPN outside of Channels. They display the same symptoms in Explorer and VRD and have the same resolution bouncing issues. I think this is a stream provider issue because it isn’t unique to Channels
Definetly something with the adverts.
Using the same recording I inverted all my cuts in VRD so only the commercial blocks would be saved and I saved each of the 6 blocks (seen in green) one at a time. cb1.ts - cb6.ts. Every block gets audio resync frames removed.
cb1.ts
Video length: 00:02:04
Video size: 86MB
Output scenes: 1
Video output frames: 3724
Audio output frames: 2914
Processing time (secs): 8
Processed frames/sec: 465.50
Actual Video Bitrate: 5.26 Mbps
Audio resync frames removed: 430
cb2.ts
Video length: 00:03:26
Video size: 139MB
Output scenes: 1
Video output frames: 6202
Audio output frames: 4852
Processing time (secs): 10
Processed frames/sec: 620.20
Actual Video Bitrate: 5.09 Mbps
Audio resync frames removed: 497
cb3.ts
Video length: 00:03:15
Video size: 136MB
Output scenes: 1
Video output frames: 5854
Audio output frames: 4579
Processing time (secs): 14
Processed frames/sec: 418.14
Actual Video Bitrate: 5.27 Mbps
Audio resync frames removed: 711
cb4.ts
Video length: 00:03:03
Video size: 125MB
Output scenes: 1
Video output frames: 5514
Audio output frames: 4314
Processing time (secs): 10
Processed frames/sec: 551.40
Actual Video Bitrate: 5.19 Mbps
Audio resync frames removed: 506
cb5.ts
Video length: 00:03:25
Video size: 139MB
Output scenes: 1
Video output frames: 6159
Audio output frames: 4818
Processing time (secs): 12
Processed frames/sec: 513.25
Actual Video Bitrate: 5.12 Mbps
Audio resync frames removed: 574
cb6.ts
Video length: 00:02:19
Video size: 99MB
Output scenes: 1
Video output frames: 4173
Audio output frames: 3265
Processing time (secs): 11
Processed frames/sec: 379.36
Actual Video Bitrate: 5.39 Mbps
Audio resync frames removed: 640
It's not the dogs fault.
For this recording at least, case closed.
Each of the 6 commercial blocks contains the following encoded at 30 frames per second, where the rest of the recording is at 29.97 fps.
I think the reason why some software (including Windows) is getting confused with these TVE streams and thinking the video frame rate is 48,000.00 fps is because the audio stream is first (lowest pid, first stream) and the video stream is second (higher pid, second stream) and sees the audio sampling rate of 48,000.
Most ts streams have the video as the first stream and the pcr is usually on that. With these TVE streams the audio is the first stream and has the pcr on it.
Not sure if you use VRD, but you can see the issues if you comskip the recordings and view the comskip video.log file for the recording.
Example:
Lots of
Frame Rate set to 48000.000 f/s
DFps[1]= 29.970 f/s
RFps[1]= 29.970 f/s
AFps[1]= 29.970 f/s
Frame Rate corrected to 29.970 f/s
and then
Strange video pts step of 0.04533 instead of 0.03387 at frame 7
Strange video pts step of 0.05485 instead of 0.03387 at frame 16152
Strange video pts step of 0.04887 instead of 0.03387 at frame 17234
Strange video pts step of 0.04709 instead of 0.03387 at frame 18311
Strange video pts step of 0.04887 instead of 0.03387 at frame 27131
Strange video pts step of 0.04802 instead of 0.03387 at frame 45017
Strange video pts step of 0.04636 instead of 0.03387 at frame 45513
Strange video pts step of 0.04557 instead of 0.03387 at frame 46184
Strange video pts step of 0.05211 instead of 0.03387 at frame 59889
Strange video pts step of 0.04802 instead of 0.03387 at frame 60610
Jump in base apts from 2188.71532 to 2188.72930, delta=0.01398
Strange video pts step of 0.04887 instead of 0.03387 at frame 74094
Jump in base apts from 2663.14002 to 2663.15400, delta=0.01398
Strange video pts step of 0.04887 instead of 0.03387 at frame 90681
Strange video pts step of 0.04636 instead of 0.03387 at frame 92346
Strange video pts step of 0.04604 instead of 0.03387 at frame 93017
Strange video pts step of 0.04637 instead of 0.03387 at frame 93377
Strange video pts step of 0.04541 instead of 0.03387 at frame 93736
Frame 58450 (2023.281s) - Resolution change from 1920 x 1080 to 1280 x 720
Frame 59889 (2083.305s) - Resolution change from 1280 x 720 to 1920 x 1080
Frame 61957 (2158.671s) - Resolution change from 1920 x 1080 to 1280 x 720
Frame 62848 (2188.754s) - Resolution change from 1280 x 720 to 1920 x 1080
Frame 75620 (2633.095s) - Resolution change from 1920 x 1080 to 1280 x 720
Frame 76509 (2663.179s) - Resolution change from 1280 x 720 to 1920 x 1080
Parsed 106072 video frames and 118595 audio frames at 30.45 fps
WARNING: Actual framerate (28.800) different from specified framerate (29.970)
Internal frame numbers will be different from .txt frame numbers
WARNING: Complex timeline or errors in the recording!!!!
Results may be wrong, .ref input will be misaligned. .txt editing will produce wrong results
Use .edl output if possible
@chDVRuser posted information from the comskip log which got me looking at my logs too. I am noticing a correlation between "problem" files and how they are parsed by Comskip. I suspect that Windows Explorer is not able to recover like Comskip does. It seems that problem files have audio stream listed first, and then video stream. It appears that the frame rate gets interpreted from the audio sampling rate (48000) for some reason. I'm not familiar which specifics around containers, and may be using terminology wrong, but it does appear to be a recurring pattern on the shows I've recorded. Here are some examples:
Problem file 1 - excerpt from comskip log
Input #0, mpegts, from 'K:\ChannelsDVR\TV\Deadliest Catch\Deadliest Catch S15E18 2019-08-20 Dark Ship 2019-08-20-1959.mpg':
Duration: 01:02:40.02, start: 0.033378, bitrate: 5102 kb/s
Program 1
Stream #0:0[0x101]: Audio: aac (HE-AAC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 126 kb/s
Stream #0:1[0x102]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(progressive), 1920x1080, Closed Captions, 29.97 fps, 29.97 tbr, 90k tbn, 96k tbc
Stream #0:2[0x103]: Data: timed_id3 (ID3 / 0x20334449)
Initial audio pts = 0.000
Frame Rate set to 48000.000 f/s
DFps[1]= 29.970 f/s
RFps[1]= 29.970 f/s
AFps[1]= 29.970 f/s
Frame Rate corrected to 29.970 f/s
Format changed to [1920 : 1080]
Frame: 1 Ratio: 1.80 MinY: 1 MaxY: 1080 MinX: 1 MaxX: 1920
Frame: 1 Channels: 2
Problem file 2 - excerpt from comskip log
Input #0, mpegts, from 'K:\ChannelsDVR\TV\Queen Sugar\Queen Sugar S04E09 2019-08-14 Stare at the Same Fires 2019-08-14-1959.mpg':
Duration: 01:03:41.05, start: 0.033378, bitrate: 3218 kb/s
Program 1
Stream #0:0[0x101]: Audio: aac (HE-AAC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 124 kb/s
Stream #0:1[0x102]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, progressive), 1280x720, 29.97 fps, 29.97 tbr, 90k tbn, 96k tbc
Stream #0:2[0x103]: Data: timed_id3 (ID3 / 0x20334449)
Initial audio pts = 0.000
Frame Rate set to 48000.000 f/s
DFps[1]= 29.970 f/s
RFps[1]= 29.970 f/s
AFps[1]= 29.970 f/s
Frame Rate corrected to 29.970 f/s
Format changed to [1280 : 720]
Frame: 1 Ratio: 1.80 MinY: 1 MaxY: 720 MinX: 16 MaxX: 1280
Frame: 1 Channels: 2
Sample of a "good" comskip log which doesn't cause problems:
Input #0, mpegts, from 'K:\ChannelsDVR\TV\Suits\Suits S09E05 2019-08-14 If the Shoe Fits 2019-08-14-1959.mpg':
Duration: 01:04:51.99, start: 0.732544, bitrate: 4025 kb/s
Program 1
Stream #0:0[0x101]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(progressive), 1920x1080, Closed Captions, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
Stream #0:1[0x102]: Audio: aac (LC) ([15][0][0][0] / 0x000F), 44100 Hz, stereo, fltp, 96 kb/s
Stream #0:2[0x103]: Data: timed_id3 (ID3 / 0x20334449)
Frame Rate set to 29.970 f/s
Format changed to [1920 : 1080]
Frame: 1 Ratio: 1.23 MinY: 1 MaxY: 1080 MinX: 82 MaxX: 1382
Frame: 1 Channels: 0Here's another data point. For me, it's not problem recordings, it's problem channels which trigger this issue with Windows Explorer. I recorded random shows on these four channels and had problems with every recording. My TVE provider is Comcast.
- Discovery
- FX HD
- National Geographic
- OWN
I'm sure there are other channels that may cause issue, but these four are consistent for me.
Any channels that don't have the issue?
Wasn't sure if Suits came from your Prime or from TVE, but now looking at it, it must be from TVE as the audio is AAC.
Audio: aac (LC)
Any other channels that always work?
Channels that I've recorded and have yet to see an issue:
- AMC
- Hallmark
- Syfy
- TBS
- TNT
- TruTV
- USA
Yes, Suits was from TVE. I don't have a Prime, but I have a Quattro for locals.
You beat me to it.
Was going to say no issues with TruTV. VRD QSF completes w/o any sync errors.
Here's the info from comskip
Input #0, mpegts, from '/volume1/arkives/ChannelsDVR/TV/The Carbonaro Effect/The Carbonaro Effect S03E08 2017-03-29 Impractically Carbonaro Jokers Effect 2019-08-22-1959.mpg':
Duration: 00:31:23.41, start: 0.566733, bitrate: 3683 kb/s
Program 1
Stream #0:0[0x1e1]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(progressive), 1280x720 [SAR 1:1 DAR 16:9], Closed Captions, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
Stream #0:1[0x1e2]: Audio: aac (LC) ([15][0][0][0] / 0x000F), 44100 Hz, stereo, fltp, 122 kb/s
Initial audio pts = 0.000
Frame Rate set to 29.970 f/s
Format changed to [1280 : 720]
Frame: 1 Ratio: 1.80 MinY: 1 MaxY: 720 MinX: 1 MaxX: 1280
Frame: 1 Channels: 2
Any further progress on this issue??? I did record something from SUNDANCE recently, that was OK in Explorer and VRD/QSF. Still have issues with anything recorded from SCI, NatG, and AHC.
I am also still having this issue on some TVE channels.
Most recently on Destination America. 2020.08.19.2205 version of Channels DVR.
It is super annoying to have to re-mux your recordings just to copy/paste them from Windows.
I have been meaning to mention this...not sure if this related to this specific issue
All my Recordings from Channels DVR, the .mpg files, will lock up Windows Explorer, if i right click try to play them direct from the network shared folder.
I can copy the file off to the local computer i am using, and the file is fine.
Also, trying to open/play the file over network, the media player is active in the background, and after a long will, will just open and start playing the file...like 5 to 10 min.
My server is on a Linux Mint 19.3 system, with the Recordings folder shared over network, same as as many other folders i use often. Even my Emby library and Recordings folder reside on the same network share, and have no issues.
I just assume it was some file permission issue with how Channels DVR writes to that folder??
Or some thing i did not setup right in how the SMB works on that version of Mint, as they did have some known issues/bugs with SAMBA in that version.
Linux is weird, as the other file access issue i have on the same machine, is my Qbittorrent Completed folder. I can not delete any of the completed files via Windows Explorer over the network, but only when the download is in its own sub-folder folder created by the torrent program. If it is just the single file (not in a folder) of that directory, i can delete it fine from network. In either case though, i can right click and even play the file fine, does not lock up Explorer.
so....I suspect some sort of user/file permission issue on my Linux share.
You may have a different issue. The issue here is Windows Explorer gets hung up trying to determine the video specs of the file if it was recorded from one of the TVE channels that misrepresents the video frame rate as 48000 fps.
If you have VLC on your Windows PC you can open the TVE stream from Channels DVR and view the codec info which displays the frame rate. If that channel displays as 48000 fps (most all Discovery networks), then recordings from that channel will have the Windows Explorer issue.
Ah. i see.
I use MediaInfo program to view video stats like that.
It is on my right click context menu.
(think it came with Klite codec pack)
I have not had any issue with erroneous frame rate stat like that
Is it supposed to be or thinking it is 50fps for PAL?
weird.
Has there been anymore discovered on this? I went through the thread but some things are just going over my head here. So would I have to remux my videos in order for these problems to go over. My recent recordings on ESPN and FS1 are causing problems.
Playing these problem recordings in VLC it has the Audio stream as Stream 0 and thinks the Frame rate is 48,000 Frames per second.
After editing the recording in my video editor and saving it the Video Stream is now Stream 0 and the Frame rate is corrected (not to mention it got rid of 117 transport stream continuity errors)
