Same show, differing ad scan times

I’ve got 2 episodes from the same show/source, using the same profile and comskip.ini, with wildly different ad scan times. The profile I’m using is just for testing, so it’s set up to not transcode. The original files are of similar size, and appear to be just fine. Any idea why some specific files take over an hour?

“Normal” log file
King of the Hill S05E01 2000-10-01 The Perils of Polling 2023-08-08-1300-wk.mpg-Manual - No crop-2023-08-09T09-04-55.log (518.5 KB)

Unusually slow log file
King of the Hill S05E02 2000-11-05 The Buck Stops Here 2023-08-08-1330-wk.mpg-Manual - No crop-2023-08-09T09-09-52.log (1.6 MB)

EDIT: After further testing, I found no issue with the built in profiles. Right now I’m using 2 custom profiles, but no idea why it triggers some FPS issues in some recordings but not others.

Tons of these lines in the comskip log:

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

EDIT #2: Doubtful it’s a profile issue. While changing the profile worked for one of the problem recordings, it’s exhibiting the same behavior on most of the other recordings.

Here are my 2 custom profiles. One is for using NVENC encoding and the other is for getting comskip logs with no encoding.

[HEVC MKV NVENC 34cq]
Description=HEVC in MKV hard set to use NVidia.
order=handbrake
DisableEncoderReordering=true
handbrake-general=--decomb --auto-anamorphic --verbose=2
handbrake-video=--start-at duration:0 -e nvenc_h265_10bit --encoder-preset slowest -q 34 --encopts="rc-lookahead=32:temporal-aq=1:spatial_aq=1"
handbrake-audio=--aencoder copy --audio-copy-mask ac3,eac3,truehd,dts,dtshd,mp3,flac --audio-fallback ffac3 -R auto
handbrake-audioac3=--aencoder copy --audio-copy-mask aac,ac3,eac3,truehd,dts,dtshd,mp3,flac -R auto
handbrake-ext=.mkv
handbrake-audiodelay=skip
handbrake-UsingHardwareEncoding=true
handbrake-DisableSoftwareEncoderFallback=true
AllowAllCopyRemuxing=true
CustomCommandPath=C:\Windows\System32\curl.exe
CustomCommandParameters= -XPUT http://192.168.50.83:8089/dvr/pruner/deleted
CustomCommandHangPeriod=30
CustomCommandCritical=false
CustomCommandUISession=false
CustomCommandShowWindow=false
CustomCommandExitCodeCheck=false
PostCustomCommandPath=C:\Windows\System32\cmd.exe
PostCustomCommandParameters="/c del "%destinationpath%\%convertedfilename%.srt""
PostCustomCommandHangPeriod=60
PostCustomCommandCritical=false
PostCustomCommandUISession=false
PostCustomCommandShowWindow=false
PostCustomCommandExitCodeCheck=false

[MP4 Unprocessed LOGS]
Description=Logs Only 
order=ffmpeg,copy
copy-ext=.ts
copy-remuxto=.mkv
copy-audiodelay=skip
ffmpeg-general=-threads 0
ffmpeg-video=-ss 0 -vcodec copy -map 0:v -sn
ffmpeg-audio=-acodec copy -map 0:a
ffmpeg-audioac3=-acodec copy -map 0:a
ffmpeg-ext=.mkv
ffmpeg-audiodelay=skip
PreConversionCommercialRemover=true
FixedResolution=true
SkipCropping=true
AutoDeinterlace=false
DisableEncoderReordering=true
CopyLogFile=true

EDIT #3: The issue is with the older comskip version that is bundled with MCEBuddy. I saw a similar issue addressed 4/5 years ago here.

It’s isn’t a profile issue. It’s a Comskip issue. Similar video files, same INI file - one is being processed at 800fps while the other at 25fps hy comskip.

The only thing I can think of is, is the CPU busy doing something else while the slower Comskip is running? If not try upgrading to the latest version of Comskip or try using ShowAnalyzer instead.

It’s 100% a bug in the older bundled version of Comskip. Erik has fixed it, as using a newer version this issue doesn’t appear.

I had thought it was a profile issue, as when I changed the profile it worked as expected. I must have used a file I thought was bad, but was really fine.