Samme show, varierende annonce-scan-tider

Jeg har 2 episoder fra samme show/kilde, der bruger samme profil og comskip.ini, med voldsomt forskellige annonce-scantider. Profilen er kun til test, så den er sat til ikke at transcode. De originale filer har omtrent samme størrelse og ser fine ud. Nogen idé om, hvorfor nogle bestemte filer tager over en time?

“Normal” logfil
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)

Usædvanligt langsom logfil
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: Efter yderligere test fandt jeg ingen problemer med de indbyggede profiler. Lige nu bruger jeg 2 brugerdefinerede profiler, men jeg har ingen idé om, hvorfor det udløser FPS-problemer i nogle optagelser men ikke andre.

Masser af disse linjer i comskip-loggen:

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: Det er næppe en profilfejl. Selvom skift af profil virkede for en af de problematiske optagelser, opfører de fleste andre optagelser sig stadig ens.

Her er mine 2 brugerdefinerede profiler. Den ene bruger NVENC-kodning, den anden giver comskip-logs uden kodning.

[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: Problemet ligger i den ældre comskip-version, der følger med MCEBuddy. Jeg så et lignende problem løst for 4-5 år siden her.

Det er ikke en profilfejl. Det er en Comskip-fejl. Lignende videofiler, samme INI-fil – den ene behandles med 800fps, mens den anden kører med 25fps i Comskip.

Det eneste, jeg kan komme i tanke om, er, om CPU’en er optaget af andet, mens den langsommere Comskip kører? Hvis ikke, så prøv at opgradere til den nyeste version af Comskip eller brug ShowAnalyzer i stedet.

Det er 100% en fejl i den ældre bundtede version af Comskip. Erik har rettet den, da problemet ikke opstår med en nyere version.

Jeg troede, det var en profilfejl, da det virkede som forventet, da jeg skiftede profil. Jeg må have brugt en fil, jeg troede var dårlig, men som i virkeligheden var fin.