Mismo programa, tiempos de escaneo de anuncios diferentes

Tengo 2 episodios de la misma fuente/serie, usando el mismo perfil y comskip.ini, con tiempos de escaneo de anuncios muy diferentes. El perfil que uso es solo para pruebas, así que está configurado para no transcodificar. Los archivos originales tienen tamaños similares y parecen estar bien. ¿Alguna idea de por qué algunos archivos específicos tardan más de una hora?

Archivo de registro “normal”
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)

Archivo de registro inusualmente lento
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: Tras más pruebas, no encontré problemas con los perfiles integrados. Ahora uso 2 perfiles personalizados, pero no tengo idea de por qué desencadena problemas de FPS en algunas grabaciones y no en otras.

Montones de estas líneas en el registro de comskip:

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: Dudo que sea un problema del perfil. Aunque cambiar el perfil funcionó para una de las grabaciones problemáticas, el mismo comportamiento se presenta en la mayoría de las demás grabaciones.

Aquí están mis 2 perfiles personalizados. Uno es para usar la codificación NVENC y el otro es para obtener registros de comskip sin codificar.

[HEVC MKV NVENC 34cq]
Description=HEVC en MKV configurado para usar 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=Solo registros
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: El problema es con la versión antigua de comskip que viene incluida con MCEBuddy. Vi un problema similar tratado hace 4/5 años aquí.

No es un problema del perfil. Es un problema de Comskip. Archivos de vídeo similares, mismo archivo INI: uno se procesa a 800 fps mientras que el otro a 25 fps por Comskip.

Lo único que se me ocurre es que el CPU esté ocupado haciendo algo más mientras se ejecuta el Comskip más lento. Si no es así, intenta actualizar a la última versión de Comskip o prueba usando ShowAnalyzer en su lugar.

Es 100% un error en la versión anterior incluida de Comskip. Erik lo ha corregido, ya que al usar una versión más nueva este problema no aparece.

Pensé que era un problema del perfil, ya que cuando cambié el perfil funcionó como se esperaba. Debo haber usado un archivo que creía que estaba mal, pero en realidad estaba bien.