Gleiche Sendung, unterschiedliche Werbe-Scanzeiten

Ich habe 2 Episoden derselben Sendung/Quelle, mit demselben Profil und comskip.ini, die stark unterschiedliche Werbeerkennungszeiten haben. Das Profil, das ich nutze, ist nur für Tests, daher ist es so eingestellt, dass es nicht transkodiert. Die Originaldateien sind von ähnlicher Größe und scheinen in Ordnung zu sein. Irgendeine Idee, warum bestimmte Dateien über eine Stunde brauchen?

„Normaler“ Log-Datei
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)

Ungewöhnlich langsame Log-Datei
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: Nach weiteren Tests habe ich keine Probleme mit den eingebauten Profilen festgestellt. Ich nutze momentan 2 benutzerdefinierte Profile, aber keine Ahnung, warum es bei manchen Aufnahmen FPS-Probleme auslöst, bei anderen nicht.

Tonnenweise dieser Zeilen im 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: Zweifelhaft, dass es ein Profil-Problem ist. Obwohl das Wechseln des Profils bei einer der problematischen Aufnahmen funktionierte, zeigt es bei den meisten anderen Aufnahmen dasselbe Verhalten.

Hier sind meine 2 benutzerdefinierten Profile. Eines ist für die Nutzung von NVENC-Encoding, das andere dient dazu, comskip-Logs ohne Encoding zu erhalten.

[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: Das Problem liegt bei der älteren comskip-Version, die mit MCEBuddy ausgeliefert wird. Ich habe ein ähnliches Problem vor 4/5 Jahren hier gesehen.

Es liegt nicht an einem Profil-Problem, sondern an einem Comskip-Problem. Bei ähnlichen Videodateien und derselben INI-Datei verarbeitet Comskip die eine mit 800 fps, die andere nur mit 25 fps.

Das Einzige, woran ich denken kann: Ist die CPU gerade mit etwas anderem beschäftigt, während das langsamere Comskip läuft? Falls nicht, versuche, auf die neueste Comskip-Version zu aktualisieren oder stattdessen ShowAnalyzer zu verwenden.

Es ist zu 100% ein Bug in der älteren mitgelieferten Version von Comskip. Erik hat ihn behoben, da das Problem mit einer neueren Version nicht auftritt.

Ich hatte gedacht, es sei ein Profilproblem, da es nach dem Wechsel des Profils wie erwartet funktionierte. Ich muss eine Datei verwendet haben, von der ich dachte, sie sei fehlerhaft, die aber in Wirklichkeit in Ordnung war.