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.
1 Like
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)
Oh okay I understand now. Which video editor did you use? I have seen people use VideoRedo which I actually do have since I manually take out the commercials myself. I don't trust those automated programs since those haven't worked for me.
I use VideoRedo v6.
I have Channels DVR comskip create a VRD Project file and if I cut every frame of commercials out of those TVE recordings it saves without removing any resync frames and the resulting file has no issues with Windows Explorer.
If you create an override comskip.ini file with the following line added
output_videoredo3=1
Channels DVR comskip creates a VRD Project file with scene markers and cut points defined.
Then it's just a matter of fine tuning the cut points in VRD.
The problem recordings have the PCR on the Audio PID.
My video editor rewrites this when saving to put the PCR on the Video PID.
This can be seen by viewing the output of ffprobe -show_programs -i filename
If you have TSReader or TSReaderLite you can also see this by viewing the PMT.
1 Like
Doing some experimenting with ffmpeg (I used the windows binaries) I found that doing a remux with just a stream copy to an mp4 file fixes things up. And since it's just a stream copy it runs really quick. Maybe a 'fix' is to convert the mpg files as the first step and use mp4 to save the recordings?
ffmpeg -i "filename.mpg" -c copy "filename.mp4"
Does anyone else have a Transport Stream analyzer?
I'm using 'Altais Digital DemuxToy Lite TS Anayser'
What I'm seeing is every TVE recording having stream 0 as the audio is missing the PCR.
The PMT table points to the Audio PID as carrying the PCR, but it's not there.
Other TVE recordings that show stream 0 as the video have the PCR.
PCR is Program Clock Reference
Is this mix up on stream 0 something that is happening when Channels is writing the .mpg file, or is it inherent in the TVE stream?
It's the stream coming from the networks. Channels doesn't rewrite anything; it takes the streams exactly as they're delivered to it.
I also verified with another tool that the PCR is missing from these recordings.
MPEG-2 TS packet analyser
They're actually MPEG2 Transport Stream (normally .ts file extension) containers.
Remuxing the problem files would help with Windows, but not sure that remuxing to an MP4 Program Stream wouldn't cause issues with Channels clients trying to play them.
MPEG Transport Streams are codec agnostic. It can be MPEG-2/H.262 or MPEG-4/H.264/AVC video, but it has no effect on the container.
What I meant was the .mpg files are not Program Streams, but Transport Streams.
Converting the MPEG2 Transport Streams recorded by Channels DVR to MPEG4 Program Streams by remuxing may not work for playback with Channels clients.
I'm not 100% sure, but I think Channels DVR expects its recording files to be in the MPEG2 Transport Stream container it saved them in, even though the file extension is .mpg.
You could just remux the files with
ffmpeg -i "filename.mpg" -c copy "filename.ts"
This should make the Video stream 0 and add a PCR to that stream.
one of mine for example
Input #0, mpegts, from 'SportsCenter 2020-10-27-2008.mpg':
Duration: 00:30:05.11, start: 0.016689, bitrate: 5492 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, 60 fps, 59.94 tbr, 90k tbn, 120 tbc
Stream #0:2[0x103]: Data: timed_id3 (ID3 / 0x20334449)
Output #0, mpegts, to 'SportsCenter 2020-10-27-2008.ts':
Metadata:
encoder : Lavf58.20.100
Stream #0:0: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, progressive), 1280x720, q=2-31, 60 fps, 59.94 tbr, 90k tbn, 90k tbc
Stream #0:1: Audio: aac (HE-AAC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 124 kb/s
Stream mapping:
Stream #0:1 -> #0:0 (copy)
Stream #0:0 -> #0:1 (copy)
Try it with one of your problem files.
If that works you could delete your original recording "filename.mpg" and rename the newly remuxed file from "filename.ts" to "filename.mpg"