Slow Ad scan on some TVE/FXX episodes (Frame Rate issue)

Channels Version: 2023.08.07.2138
MCEBuddy 2.5.7
Comskip 0.82.003 (donator)

This may or may not be a Channels issue. Though I am starting to suspect the original recorded files may be the issue. I use MCEBuddy to cut commercials and transcode, but I imagine this community is familiar enough with the software to figure out where the problem may be.

I noticed that some episodes recorded from FXX (also FX) show a frame rate of 29.97 while others show 59.94. Episodes that are 29.97 have no issue and take 2-4 minutes in the ad scan, But ones that show a frame rate of 59.94 will take over 1hr 15min for the ad scan.

I've tried different settings in MCEBuddy, as well as different comskip.ini files. I'm currently running tests on different networks. An episode on FX and Disney are also having the same frame rate/long ad scan time issues.

Here's what a good comskip log looks like:

Input #0, mpegts, from 'T:\apps\MCEBuddy\temp\working0\King of the Hill S05E01 2000-10-01 The Perils of Polling 2023-08-08-1300-wk.ts':
  Duration: 00:30:27.01, start: 1.400000, bitrate: 6181 kb/s
  Program 1 
    Metadata:
      service_name    : Service01
      service_provider: FFmpeg
    Stream #0:0[0x100]: Audio: aac (HE-AAC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 136 kb/s
    Stream #0:1[0x101]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
Frame Rate set to 29.970 f/s
Format changed to [1280 : 720]
Frame: 1 Channels:  0

Initial audio pts =      0.000

Initial video pts =      0.017
Frame Rate set to 59.940 f/s
DFps[1]= 29.970 f/s
RFps[1]= 29.970 f/s
AFps[1]= 29.970 f/s
Frame: 2 Channels:  2
Frame      2 (0.000s) - Black frame because large scene change of 99, uniform 43516

Initial video pts =      0.033
Framerate forced to 29.97fps at frame 7
Frame Rate set to 29.970 f/s
Frame: 2	Ratio: 1.78	MinY: 1	MaxY: 720	MinX: 1	MaxX: 1280
Frame    104 (3.370s) - Uniform frame with brightness of 16 and uniform of 0
Frame    105 (3.403s) - Uniform frame with brightness of 16 and uniform of 0

And here's what the bad ones look like:

Input #0, mpegts, from 'T:\apps\MCEBuddy\temp\working0\King of the Hill S05E02 2000-11-05 The Buck Stops Here 2023-08-08-1330-wk.ts':
  Duration: 00:30:39.15, start: 1.400000, bitrate: 6216 kb/s
  Program 1 
    Metadata:
      service_name    : Service01
      service_provider: FFmpeg
    Stream #0:0[0x100]: Audio: aac (HE-AAC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 124 kb/s
    Stream #0:1[0x101]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], Closed Captions, 59.94 fps, 59.94 tbr, 90k tbn, 119.88 tbc
Frame Rate set to 59.940 f/s
Format changed to [1280 : 720]
Frame: 1 Channels:  0

Initial video pts =      0.008
Frame Rate set to 119.880 f/s
DFps[1]= 59.940 f/s
RFps[1]= 59.940 f/s
AFps[1]= 59.940 f/s
Frame Rate corrected to 59.940 f/s
Frame      2 (0.000s) - Black frame because large scene change of 96, uniform 35308

Initial video pts =      0.017
Frame Rate set to 119.880 f/s
DFps[1]= 59.940 f/s
RFps[1]= 59.940 f/s
AFps[1]= 59.940 f/s
Frame Rate corrected to 59.940 f/s
Frame Rate set to 119.880 f/s
DFps[1]= 59.940 f/s
RFps[1]= 59.940 f/s
AFps[1]= 59.940 f/s
Frame Rate corrected to 59.940 f/s
Frame Rate set to 119.880 f/s

Which continues on for some time.

EDIT: it's the older version of comskip that's bundled with MCEBuddy. When I point MCE to the comskip bundled with Channels it works as expected.

That version is almost 6 years old. Can't you replace it with the latest version (I'm assuming that's why it works with the Channels DVR comskip)
https://www.kaashoek.com/files/

If not, just point it to the Channels DVR version, like you said.

Thankfully, the MCEBuddy software is flexible enough where using a different version is pretty simple.

Unfortunately the MCEBuddy developer is pretty slow when it comes to updates. And given the age and state of both MCE and Comskip, I'm surprised no one has done a modern rewrite, with a better design, clearer instructions, that uses machine learning.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.