Extraktion von Untertiteln/Videotext bei OTA-Aufnahmen fehlgeschlagen

Untertitel-Extraktion schlägt fehl:

2026-03-31T06:05:26 MCEBuddy.AppWrapper.CCExtractor → Issues · CCExtractor/ccextractor · GitHub
→ Prozess beendet mit Code 0
→ Überprüfung der SRT-Datei S:\MCEBuddy-Temp\working1\Henry David Thoreau S01E01 Who Are We 2026-03-30-2000.srt
INFORMATION> → Validiere und bereinige SRT-Datei
FEHLER> → Fehler beim Validieren der SRT-Datei System.Exception: Nullzeichen erkannt, keine Textdatei
bei MCEBuddy.Transcode.CCandSubtitles.SRTValidateAndClean(List`1 srtFiles, Log jobLog, Double offset, Single duration)
FEHLER> 2026-03-31T06:05:28 MCEBuddy.Transcode.CCandSubtitles → Fehler beim Validieren der Untertiteldatei
FEHLER> 2026-03-31T06:05:28 MCEBuddy.Engine.ConversionJob → Extrahieren der geschlossenen Untertitel fehlgeschlagen
WARNUNG> 2026-03-31T06:05:28 MCEBuddy.Engine.ConversionJob → Extrahieren der geschlossenen Untertitel aus der Originaldatei fehlgeschlagen, versuche, die geschlossenen Untertitel aus der remux‑Datei zu extrahieren
INFORMATION> 2026-03-31T06:05:28 MCEBuddy.Transcode.CCandSubtitles → Extrahiere geschlossene Untertitel als SRT-Datei

2026-03-31T06:05:39 MCEBuddy.AppWrapper.CCExtractor → Issues · CCExtractor/ccextractor · GitHub
→ Prozess beendet mit Code 0
→ Überprüfung der SRT-Datei S:\MCEBuddy-Temp\working1\Henry David Thoreau S01E01 Who Are We 2026-03-30-2000.srt
INFORMATION> → Validiere und bereinige SRT-Datei
FEHLER> → Fehler beim Validieren der SRT-Datei System.Exception: Nullzeichen erkannt, keine Textdatei
bei MCEBuddy.Transcode.CCandSubtitles.SRTValidateAndClean(List`1 srtFiles, Log jobLog, Double offset, Single duration)
FEHLER> 2026-03-31T06:05:41 MCEBuddy.Transcode.CCandSubtitles → Fehler beim Validieren der Untertiteldatei
FEHLER> 2026-03-31T06:05:41 MCEBuddy.Engine.ConversionJob → Extrahieren der geschlossenen Untertitel fehlgeschlagen
WARNUNG> 2026-03-31T06:05:41 MCEBuddy.Engine.ConversionJob → Keine Untertiteldatei nach der Extraktion gefunden

Henry David Thoreau S01E01 Who Are We 2026-03-30-2000.mpg-ChannelsDVR - TV - NO Comskip-2026-03-31T06-00-00.log (1.9 MB)

Es sieht so aus, als ob CCExtractor erfolgreich läuft (Exit-Code 0), aber die resultierende SRT-Datei wird von MCEBuddy abgelehnt, da sie Null-Zeichen enthält (System.Exception: Null character detected, not a text file). Dies passiert häufig, wenn der Stream binäres Rauschen enthält oder die Kodierung beschädigt ist.

Um bei der Fehlersuche zu helfen, könntest du Folgendes versuchen:

  1. CCExtractor-Version überprüfen: Verwendest du den “Standard”-CCExtractor, der mit MCEBuddy geliefert wird, oder hast du ihn gegen eine andere Version ausgetauscht?
  2. Einen benutzerdefinierten CCExtractor-Befehl versuchen: Versuche in deinen Konvertierungsaufgaben-Einstellungen (Conversion Task Settings) → Experteneinstellungen (Expert Settings), -utf8 in das Feld für benutzerdefinierte CCExtractor-Parameter (Custom CCExtractor parameters) einzufügen, um zu sehen, ob das Erzwingen einer bestimmten Kodierung hilft, den Fehler mit dem Null-Zeichen zu umgehen.
  3. Manuelle Überprüfung: Wenn du kannst, öffne die temporäre SRT-Datei (S:\MCEBuddy-Temp\working1\...srt) in einem Texteditor wie Notepad++, bevor der Vorgang abgeschlossen ist oder fehlschlägt, um zu sehen, ob sie wie Datenmüll oder wie tatsächlicher Text aussieht.

Ich werde das Forum durchsuchen, um zu sehen, ob es kürzlich Berichte über “Null character detected” bei den neuesten OTA-Aufnahmen gibt.

Henry David Thoreau S01E01 Who Are We 2026-03-30-2000.srt (79,9 KB)

Ich verarbeite eine der Dateien neu, die fehlgeschlagen ist. Ich habe die temporäre SRT-Datei angehängt. Es handelt sich um eine normale SRT-Datei. Am Ende der Datei befindet sich ein NULL-Zeichen (möglicherweise gibt es weitere NULLs – ich habe nicht systematisch danach gesucht).

Ich habe die „Comskip Donators Version“. Ich verwende jedoch den Standard-Closed-Captions-Extractor (es sei denn, das übernimmt das Comskip-Plugin).

Ich sehe kein Feld „Benutzerdefinierte CCExtractor-Parameter“ in den Experteneinstellungen.

Es scheint, dass das Problem spezifisch bei der Validierung nach der Extraktion durch MCEBuddy liegt. Obwohl CCExtractor die SRT-Datei erfolgreich erstellt, durchsucht die Engine von MCEBuddy sie als Sicherheitsüberprüfung auf „Null-Zeichen“ (binäre Nullen), um sicherzustellen, dass es sich um eine gültige Textdatei handelt. Wenn sie auch nur ein einziges findet, wird die gesamte Datei abgelehnt.

Zu deinen Punkten:

  1. CCExtractor vs. Comskip: Du hast recht; während Comskip die Erkennung von Werbeunterbrechungen übernimmt, ist CCExtractor ein separates Werkzeug, das von MCEBuddy speziell für die Untertitel-Extraktion verwendet wird.
  2. Feld für benutzerdefinierte Parameter: Entschuldige bitte – ich hätte präziser sein sollen. Das Feld „Custom CCExtractor parameters“ (Benutzerdefinierte CCExtractor-Parameter) befindet sich tatsächlich in der Konfiguration des Profils, nicht in der Konvertierungsaufgabe.

Empfohlene Schritte:

1. Füge -utf8 zu deinem Profil hinzu

Da du erwähnt hast, dass die SRT-Datei „normal“ aussieht, aber ein Null-Zeichen enthält, könnte das Erzwingen von UTF-8 CCExtractor dabei helfen, eine sauberere Ausgabe zu erzeugen, die vom Validierungstool von MCEBuddy akzeptiert wird.

  1. Öffne profiles.conf (normalerweise in C:\Programme\MCEBuddy2x\config).
  2. Suche das Profil, das du verwendest (z. B. [MKV HEVC]).
  3. Füge die folgende Zeile zu diesem Profil hinzu:
    cc_params=-utf8
  4. Speichere die Datei und starte den MCEBuddy-Dienst neu.

2. Deaktiviere die Prüfung auf Null-Zeichen (Fortgeschritten)

Falls das Erzwingen von UTF-8 nicht funktioniert, gibt es eine interne MCEBuddy-Einstellung, um die Validierung zu überspringen, die fehlschlägt.

  1. Klicke in der MCEBuddy-GUI auf Settings (Einstellungen) → Advanced Settings (Erweiterte Einstellungen).
  2. Suche nach einem Kontrollkästchen mit der Bezeichnung Skip subtitle validation (Untertitel-Validierung überspringen) oder ähnlich, je nach Version.
  3. Alternativ kannst du SkipSubtitleValidation=true zum Abschnitt [Common] deiner mcebuddy.conf-Datei hinzufügen.

3. Warum passiert das jetzt?

Da du erwähnt hast, dass dies erst kürzlich aufgetreten ist, ist es wahrscheinlich, dass der Over-the-Air-Sender für „Henry David Thoreau“ (oder die DVR-Software) ein gewisses Rauschen im Stream einfügt, das CCExtractor als Zeichen interpretiert.

Falls es dir nichts ausmacht, könntest du mir mitteilen, welche MCEBuddy-Version du aktuell verwendest? (z. B. 2.6.4). Das würde mir helfen zu prüfen, ob für diesen spezifischen Build ein bekannter Fehler bei der Validierung vorliegt.

MCEBuddy 2.7 Release 1

Ich bin mir nicht sicher, wie lange das schon ein Problem ist – es besteht seit mindestens den letzten 8 Tagen. Es tritt bei allen Episoden einiger PBS-TV-Serien auf, bei anderen jedoch nicht.

CC extraction has failed for these new TV Series:
. The Forsytes on Masterpiece (Season 1)
. Henry David Thoreau (Ken Burns series)
. Call the Midwife (Season 15)

But CC extraction is working okay for these TV Series:
. The Count of Monte Cristo on Masterpiece (Season 1)
. Horizons from PBS News (Season 1)
. Compass Points from PBS News (Season 1)

Ich habe den MCEBuddy‑Daemon gestoppt, beide vorgeschlagenen Änderungen vorgenommen (in der Annahme, dass ich sie korrekt durchgeführt habe) und den MCEBuddy‑Daemon neu gestartet. Diese Änderungen haben das Problem jedoch nicht behoben. (Allerdings konnte ich die temporären SRT‑Dateien erfassen.)

profiles.conf:
[MKV HEVC]
Description=HEVC in MKV (H.265/AC3) conversion. Creates a smaller file (50% smaller than H.264) with comparable quality but very slow.
order=handbrake,ffmpeg
ffmpeg-general=-threads 0
ffmpeg-video=-ss 0 -tag:v hvc1 -vf yadif=0:-1:1,hqdn3d -vcodec libx265 -preset medium -crf 26 -map 0:v -sn
ffmpeg-audio=-acodec ac3 -ab 160k -map 0:a
ffmpeg-audioac3=-acodec ac3 -ab 256k -map 0:a
ffmpeg-ext=.mkv
ffmpeg-audiodelay=skip
handbrake-general=–decomb --loose-anamorphic --verbose=2
handbrake-video=–start-at duration:0 -e x265 --encoder-preset medium -q 26
handbrake-audio=-E ffac3 -R auto -B 160 -D 0 -a 1,2,3,4,5
handbrake-audioac3=-E ffac3 -R auto -B 256 -D 0 -a 1,2,3,4,5
handbrake-ext=.mkv
handbrake-audiodelay=skip
PreConversionCommercialRemover=true
cc_params=-utf8

mcebuddy.conf:
[Engine]
Tasks=Convert to MP4,ChannelsDVR - TV - NO Comskip,ChannelsDVR - TV - Comskip,PlayOnHome - NO Comskip,PlayOnCloud - NO Comskip,PBS - NO Comskip,Manual
SearchRecords=PlayOnHome,ChannelsDVR-TV,PlayOnCloud,PBS
UserName=Guest
DomainName=
ArchiveDomainName=
ArchiveUserName=Guest
FailedDomainName=
FailedUserName=Guest
WakeHour=-1
WakeMinute=-1
StartHour=6
StartMinute=0
StopHour=7
StopMinute=0
DaysOfWeek=Sunday,Monday,Tuesday,Wednesday,Thursday,Friday,Saturday
MaxConcurrentJobs=3
LogJobs=True
LogLevel=3
LogKeepDays=15
DeleteOriginal=False
UseRecycleBin=False
ArchiveOriginal=False
DeleteConverted=False
AllowSleep=False
SuspendOnBattery=False
SendEmail=False
Locale=en-US
TempWorkingPath=S:\MCEBuddy-Temp
ArchivePath=
FailedPath=
SpaceCheck=True
CustomComskipPath=C:\Comskip_Donators_Version\comskip.exe
CustomProfilePath=
HangPeriod=300
PollPeriod=60
ProcessPriority=Normal
CPUAffinity=0
EngineRunning=True
LocalServerPort=23332
UPnPEnable=False
FirewallExceptionEnable=False
SubtitleSegmentOffset=0
SkipSubtitleValidation=True
MinimumSegmentSize=4
eMailServer=
eMailPort=25
eMailSSL=False
eMailFrom=
eMailTo=
eMailSuccess=True
eMailFailed=True
eMailCancelled=True
eMailStart=True
eMailDownloadFailed=True
eMailQueue=True
eMailSuccessSubject=
eMailFailedSubject=
eMailCancelledSubject=
eMailStartSubject=
eMailDownloadFailedSubject=
eMailQueueSubject=
eMailSkipBody=False
eMailUsername=

Ich verwende die neueste Version von McEBuddy, die bisher konsistent SRT-Dateien für alle einfachen Kabelkanäle erstellt hat. Jetzt nehme ich über Antenne (OTA) auf und erhalte für keine der Aufnahmen eine SRT-Datei – nicht einmal für solche, die ich vor Jahren aufgenommen habe und für die ich bereits eine SRT-Datei hatte (ich habe die Quelldatei erneut verarbeitet, um das Format zu ändern).

Es ist möglich, dass mein Profil für SRT nicht richtig eingestellt ist, aber ich hatte in den Jahren, in denen ich McEBuddy verwende, noch nie dieses Problem. Ich werde das weiter untersuchen und schauen, was ich herausfinden kann.

Jon – mein Workaround, wenn die SRT-Datei fehlt, besteht darin, die Konvertierung erneut durchzuführen und dabei den temporären Ordner zu

Das ist nicht normal. Wenn du eine SRT-Datei mit einer Größe von mehr als null Bytes sehen und manuell kopieren kannst, sollte sie eigentlich von MCEBuddy direkt in den Zielordner kopiert werden.

Kannst du dein Konvertierungsprotokoll anhängen, damit ich sehen kann, was da los ist?

Gutes Timing. Ich hatte eine Aufnahme, die ich neu machen musste, um die Untertitel zu erhalten. Hier ist das Protokoll:

The Kimberley Australia’s Wild West S01E01 River Of Life 2026-06-17-2100.mpg-ChannelsDVR - TV - NO Comskip-2026-06-18T16-42-37.log (1,7 MB)

Das war sehr hilfreich. Es sieht so aus, als ob sich ungültige Zeichen in der extrahierten SRT-Datei befinden, die zu einer Validierung oder einem Fehler führen, weshalb MCEBuddy die extrahierten Untertitel löscht.

Checking SRT file S:\MCEBuddy-Temp\working2\The Kimberley Australia’s Wild West S01E01 River Of Life 2026-06-17-2100.srt
INFORMATION> → Validating and cleaning SRT file
ERROR> → Error validating SRT file System.Exception: Null character detected, not a text file
at MCEBuddy.Transcode.CCandSubtitles.SRTValidateAndClean(List`1 srtFiles, Log jobLog, Double offset, Single duration)
ERROR> 2026-06-18T16:46:29 MCEBuddy.Transcode.CCandSubtitles → Error validating Subtitle file
ERROR> 2026-06-18T16:46:29 MCEBuddy.Engine.ConversionJob → Extracting closed captions failed

Können Sie die ursprüngliche Videodatei und die extrahierte SRT-Datei hochladen, damit wir sie analysieren und sehen können, was da los ist?

Man sollte meinen, ich hätte vorhersehen können, dass du die Quelldatei benötigen würdest. Leider habe ich das nicht. Ich habe die Untertiteldatei angehängt. Ich habe weitere Aufnahmen verschiedener Sendungen geplant und werde dies auch weiterhin tun, um zu versuchen, ein weiteres Beispiel zu finden. PBS-Aufnahmen über Antenne (Over-The-Air) scheinen am ehesten von diesem Problem betroffen zu sein. Ich bin sicher, dass innerhalb einer Woche (spätestens) eine weitere Aufnahme auftauchen wird.

The Kimberley Australia’s Wild West (2026) - S01E01 - River Of Life (2026-04-05).srt (56,7 KB)

Wie groß darf die hochgeladene Aufnahme eigentlich sein? Ich schätze, das werde ich dann herausfinden.

Lade die gesamte Datei hoch. Es gibt keine Größenbeschränkung.

Hier ist ein Beispiel von letzter Nacht.

Ups. Es gibt eine Größenbeschränkung:

Entschuldigung, die Datei ist zu groß (maximale Größe beträgt 10 MB). Warum lädst du deine große Datei nicht bei einem Cloud-Speicherdienst hoch und fügst dann den Link hier ein?

Ich habe die Dateien auf Google Drive abgelegt: MCEBuddy - Google Drive

Hier ist ein weiteres Beispiel: CBS News Sunday Morning (OTA-Aufnahme). Ich habe die Dateien auf OneDrive hochgeladen: MCEBuddy

Danke, dass du das gemeldet hast, es wurde im heutigen Beta-Build 2.7.2 behoben. Du kannst es ausprobieren und uns wissen lassen, ob du immer noch Probleme hast.

Hallo Goose.

Großartig. Das ist so eine Situation, in der keine Nachricht von mir eine gute Nachricht ist. Basierend auf der Erfahrung der Vergangenheit würde ich definitiv erwarten, dass innerhalb einer Woche ein Problem auftritt. Wenn ich sehe, dass dieses Problem erneut auftritt, werde ich hier einen Beitrag verfassen.

Steve