Bestehende Dateien konvertieren

Hallo, ich bin neu bei MCEBuddy. Ich habe zwei Lizenzen gekauft, eine für meine alte Win 8.1 WMC-Box mit Cablecard und eine für meine extrem schnelle neue Maschine mit dedizierter GPU.

Ich dachte, ich würde die schnelle Maschine verwenden, um die Hunderte von vorhandenen Aufnahmen zu transkodieren, und die transkodierten Dateien von meiner WMC-Maschine auf meine NAS-Box verschieben. Danach würde ich MCEBuddy auf der alten, langsamen Maschine laufen lassen, um neue Aufnahmen zu transkodieren, sobald sie eingehen.

Der erste Teil funktionierte einwandfrei, aber MCEBuddy auf der alten Maschine möchte alle Dateien erneut transkodieren. Ich war der Meinung, dass das Aktivieren von „Wiederholte Konvertierung überspringen“ (skip reconversion) das Ziel überprüfen sollte, um festzustellen, ob der Dateiname (wie er umbenannt würde) existiert, und falls ja, die Konvertierung überspringen sollte. Das scheint jedoch nicht zu funktionieren. Fehlt mir da etwas?

Ich habe eine benutzerdefinierte Umbenennungsregel, aber genau dieselbe Zeichenfolge auf der schnellen Maschine, die die Bibliothek konvertiert hat, und auf der langsamen Maschine, bei der ich nur neue Aufnahmen konvertieren möchte.

Hi John, and welcome to MCEBuddy!

You’re right, the “skip reconversion” option should prevent MCEBuddy from re-transcoding files that already exist in the destination with the same (renamed) filename. It sounds like you’ve set up your renaming rules identically on both machines, which is a good start.

Let’s try to figure out what might be happening. When you say the old machine “wants to re-transcode all the files,” do you mean it’s actually starting the conversion process, or is it just listing them as pending in the queue?

Here are a few things we can check:

  1. Exact Match: The “skip reconversion” feature relies on an exact match of the destination filename. Even a slight difference, like an extra space or a different case, can cause MCEBuddy to see it as a new file. Could you double-check that the renaming rules on both machines are truly identical character by character?
  2. Destination Folder: Is the destination folder configured identically on both machines? MCEBuddy needs to know where to look for the existing files.
  3. File Attributes: Sometimes, file attributes (like creation date or modification date) can play a role. Have the files been moved or copied in a way that might have altered these attributes significantly?
  4. Log Files: The MCEBuddy log files would be very helpful in understanding what’s happening. Can you share a snippet of the log from the old machine when it’s attempting to re-transcode the files? Look for entries related to “skip reconversion” or the files in question.
  5. MCEBuddy Version: While unlikely to be the primary cause, ensuring both machines are running the same version of MCEBuddy could eliminate any potential version-specific quirks.

Let’s start there. If you can provide some more details, especially from the logs, we can narrow down the issue.

Hier sind ein paar Dinge, die wir überprüfen können:

  1. Exakte Übereinstimmung: Die Funktion „Konvertierung überspringen“ (skip reconversion) setzt eine exakte Übereinstimmung des Ziel-Dateinamens voraus. Schon eine geringfügige Abweichung, wie ein zusätzliches Leerzeichen oder eine andere Groß-/Kleinschreibung, kann dazu führen, dass MCEBuddy die Datei als neu ansieht. Könnten Sie bitte noch einmal überprüfen, ob die Umbenennungsregeln auf beiden Maschinen Zeichen für Zeichen absolut identisch sind? \[JD Absolut, guter Punkt, werde das überprüfen, sobald ich zu Hause bin\]

    Zielordner: Ist der Zielordner auf beiden Maschinen identisch konfiguriert? MCEBuddy muss wissen, wo es nach den vorhandenen Dateien suchen soll. \[JD Ja, sie sind identisch, derselbe Ordner auf meiner NAS-Box, dieselben Anmeldeinformationen usw.\]

  2. Dateiattribute: Manchmal spielen Dateiattribute (wie Erstellungsdatum oder Änderungsdatum) eine Rolle. Wurden die Dateien auf eine Weise verschoben oder kopiert, die diese Attribute möglicherweise erheblich verändert hat? \[JD Das Einzige, was mit den Dateien passiert ist, ist, dass MCEBuddy sie transkodiert und in ein anderes Verzeichnis verschoben hat, das ist vermutlich in Ordnung? ]

  3. Protokolldateien (Log Files): Die MCEBuddy-Protokolldateien wären sehr hilfreich, um zu verstehen, was passiert. Können Sie einen Ausschnitt des Protokolls von der alten Maschine teilen, wenn diese versucht, die Dateien erneut zu transkodieren? Suchen Sie nach Einträgen im Zusammenhang mit „skip reconversion“ oder den betreffenden Dateien. \[JD Ja, werde ich mir auf jeden Fall ansehen und alle relevanten Teile posten.\]

  4. MCEBuddy-Version: Obwohl es unwahrscheinlich ist, dass dies die Hauptursache ist, stellt die Sicherstellung, dass beide Maschinen dieselbe Version von MCEBuddy verwenden, potenzielle versionsspezifische Eigenheiten aus. \[Ja, habe sie gleichzeitig heruntergeladen, aber ich werde es noch einmal überprüfen. Außerdem scheint es die Dateien neu zu konvertieren und nicht nur die bereits konvertierten Dateien in die Warteschlange aufzunehmen.\]

Vielen Dank für die schnelle Antwort und die Liste der zu überprüfenden Punkte!

Hi John,

Thanks for the additional information! It’s good to know that the destination folder and credentials are identical, and that you’ll be checking the renaming rules and logs.

The fact that MCEBuddy is actually re-converting the files, and not just queuing them, is a key piece of information. This strongly suggests that it’s not recognizing the existing files as identical, even with the “skip reconversion” option enabled.

Regarding your question about file attributes, it’s generally fine if MCEBuddy moves the files after transcoding. The “skip reconversion” feature primarily relies on the destination filename, not the original file’s attributes. However, if the files were moved in a way that significantly altered their modification dates (e.g., if a new copy was created rather than a move), it could potentially cause issues with other features, but it’s less likely to be the direct cause of “skip reconversion” failing if the filenames are indeed identical.

Let’s focus on those renaming rules and the logs. The logs will be the most valuable in telling us why MCEBuddy thinks it needs to reconvert the files. Look for messages related to the “skip reconversion” check and any discrepancies it might be reporting.

Once you have a chance to check the exact renaming rules and share those log snippets, we should be able to get a clearer picture of what’s going on.

No problem at all! We’ll get this sorted out.

Das gilt für Dateien auf demselben Computer. MCEBuddy führt eine Verlaufsdatei (history file), die Konvertierungen im Konfigurationsordner (config folder) verfolgt. Wenn Sie also MCEBuddy auf zwei separaten Maschinen ausführen, wissen diese nicht, was die andere tut, und können daher Dateien nicht zwischen den Maschinen verfolgen. Es gibt Möglichkeiten, dies zu umgehen. Suchen Sie im Forum nach „Daisy Chaining“, um zu sehen, wie Sie dies mithilfe einer Kombination von Ordnern und Filtern erreichen können.

Sie könnten sie beispielsweise in verschiedenen Ordnern für die neue und die alte Maschine ablegen, oder Sie können Filter verwenden, die auf Dateinamen, Sendungsnamen oder sogar darauf basieren, dass die Aufnahme auf Zeitstempeln der letzten Änderung beruht, um zu bestimmen, ob eine Konvertierungsaufgabe (oder Überwachungsaufgabe) die Dateien verarbeiten oder überwachen soll.

Nun, es scheint, dass die Namen das Problem sind. Ich dachte, ich hätte das Problem gefunden, hier sind die Umbenennungsregeln, die ich verwendet habe:

TV Series%showname%%showname%.S%season%##E%episode%##.%episodename%>>

\TV Series%showname%%showname%.S%season%##E%episode%##.%episodename%>>

Der zusätzliche Backslash war auf dem schnellen Computer. Ich habe jedoch die Regel des alten Computers so geändert, dass sie den Backslash enthält, und er wurde trotzdem neu konvertiert.

Hier sind einige relevante Teile des Protokolls. Ich muss nur herausfinden, warum die Namen als unterschiedlich angesehen werden:

Skip ReProcessing → True

Check Reprocessing History → True

Auto Increment Filename → False

Add to iTunes Library → False

INFORMATION> 2025-09-08T15:37:37 MCEBuddy.Engine.ConversionJob → Checking for destination file skip reprocessing

- → Custom Renaming Command → TV Series%showname%%showname%.S%season%##E%episode%##.%episodename%>>

INFORMATION> 2025-09-08T15:37:37 MCEBuddy.Engine.ConversionJob → Destination file \\192.168.0.46\User Homes\johndefiore\Media\Converted\TV SeriesEva Longoria Searching for MexicoEva Longoria Searching for Mexico.S01E02.Yucatan.mp4 does not exist, continuing with conversion

INFORMATION> 2025-09-08T15:37:37 MCEBuddy.Engine.ConversionJob → Running [LINK REMOVED]

- → Custom Renaming Command → TV Series%showname%%showname%.S%season%##E%episode%##.%episodename%>>

- → Custom Renaming Command → TV Series%showname%%showname%.S%season%##E%episode%##.%episodename%>>

2025-09-08T15:37:37 MCEBuddy.Transcode.CustomCommand → Engine running as service, enabling PreCustomCommandUISession, since PreCustomCommandShowWindow is enabled

2025-09-08T15:37:37 MCEBuddy.Transcode.CustomCommand → [Link entfernt] parameters read →

PreCustomCommandPath =

PreCustomCommandParameters =

PreCustomCommandHangPeriod = 300

PreCustomCommandCritical = False

PreCustomCommandUISession = True

PreCustomCommandShowWindow = True

PreCustomCommandExitCodeCheck = False

INFORMATION> 2025-09-08T15:37:37 MCEBuddy.Transcode.CustomCommand → No [LINK REMOVED] found

2025-09-08T15:37:37 MCEBuddy.Engine.ConversionJob → Finished pre remuxing custom command , source file size [KB] 2,233,088.00

2025-09-08T15:37:37 MCEBuddy.AppWrapper.FFmpegMediaInfo → Launching process C:\Program Files\MCEBuddy2x\ffmpeg\ffprobe.exe

2025-09-08T15:37:37 MCEBuddy.AppWrapper.FFmpegMediaInfo → Process arguments -hide_banner -probesize 100M -analyzeduration 300M -v quiet -print_format json -show_programs -show_format -show_streams -show_chapters -i “E:\Recorded TV\Eva Longoria- Searching for Mexico_CNNHD_2025_05_25_20_58_00.wtv”

2025-09-08T15:37:37 MCEBuddy.AppWrapper.FFmpegMediaInfo → UI Session Admin Process : False

2025-09-08T15:37:37 MCEBuddy.AppWrapper.FFmpegMediaInfo → Setting process priority to Idle

Ah, danke, ich verstehe. Ich dachte, die Funktion würde den Dateinamen überprüfen, um festzustellen, ob er im Zielverzeichnis existiert, und würde nicht konvertieren, wenn der identische Dateiname bereits vorhanden wäre. Das wäre eine nützliche Funktion, aber wenn sie sich nur auf die Protokolldatei verlässt, kann ich verstehen, warum sie die Rekonvertierung durchführt.

(Obwohl die Protokolldatei darauf hindeutet, dass sie möglicherweise nach der Zieldatei sucht, bevor sie konvertiert wird:

INFORMATION> 2025-09-08T15:37:37 MCEBuddy.Engine.ConversionJob → Ziel-Datei \\\\192.168.0.46\\User Homes\\johndefiore\\Media\\Converted\\TV SeriesEva Longoria Searching for MexicoEva Longoria Searching for Mexico.S01E02.Yucatan.mp4 existiert nicht, Konvertierung wird fortgesetzt)

Ja, diese Funktion existiert auch, Konvertierungsaufgabe → Experten-Einstellungen suchen Sie nach der Option namens Skip reconversion (erneute Konvertierung überspringen)

Diese Funktion richtet sich rein nach dem Ziel-Dateinamen. Sie können die Pop-up-Hilfe für eine detaillierte Beschreibung einsehen, aber im Wesentlichen entscheidet MCEBuddy, wenn sie aktiviert ist, die Konvertierung zu überspringen, wenn es feststellt, dass der „erwartete“ Name der Datei nach der Konvertierung mit dem eines bereits im Zielverzeichnis vorhandenen Dateinamens übereinstimmt. Dies basiert rein auf dem erwarteten Ziel-Dateinamen, seien Sie sich also der Umbenennungsregeln, Zielordner usw. bewusst.

image

Ich bin kein Experte, und ich denke, Sie haben bereits den ultimativen Experten an Ihrer Seite, aber können beide Kopien von MCE so konfiguriert werden, dass sie dieselbe Verlaufsdatei verwenden? Würde das helfen?

Ich hatte den gleichen Gedanken, aber ich habe keine Ahnung, wie ich es zum Laufen bringen kann. Ich konnte nicht herausfinden, warum die Namen nicht übereinstimmten, sie schienen mir identisch zu sein, also lasse ich meine langsame Maschine einfach alles neu konvertieren. Es ist fast fertig, also ist das die unfeine Art, das Problem zu lösen. Vielleicht werde ich es mir genauer ansehen, wenn ich irgendwann Zeit habe.