Reconverting existing files

Hi- I’m new to MCEBuddy. I bought two licenses, one for my ancient Win 8.1 WMC box with cablecard, and one for my extremely fast new machine with a discrete GPU.

I figured I would use the fast machine to transcode the hundreds of existing recordings, moving the transcoded files from my WMC machine to my NAS box. Then I’d run MCEBuddy on the old, slow machine to transcode new recordings as they came in.

The first part worked fine, but MCEBuddy on the old machine wants to re-transcode all the files. I was under the impression that checking “skip reconversion” should check the destination to see if the filename (as it would be renamed) exists, and if so it would skip conversion. However, that doesn’t seem to be working. Is there something I’m missing?

I do have a custom renaming rule, but exactly the same string on the fast machine that converted the library and the slow machine that I only want to convert new recordings.

1 Like

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.

1 Like

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? [JD Absolutely, great point, will check this as soon as I get home]

    Destination Folder: Is the destination folder configured identically on both machines? MCEBuddy needs to know where to look for the existing files. [JD Yes, they are identical, the same folder on my NAS box, same credentials etc.]

  2. 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? [JD the only thing that’s happened to the files is that MCEBuddy transcoded them and moved them to a different directory, presumably that’s OK?]

  3. 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. [JD Yes, will definitely take a look and post any relevant parts.]

  4. 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. [Yes, downloaded them at the same time, but I’ll double-check. Also it does appear to be re-converting, not just queueing the already converted files.]

Many thanks for the quick response and list of things to check!

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.

1 Like

That applies to files on the same machine. MCEBuddy keeps a history file which tracks conversions in the config folder. So if you’re running MCEBuddy on 2 separate machines they don’t know what the other one is doing and consequently can’t track files between machines. There are ways around this, search the forum for “Daisy Chaining” to see how you achieve this using a combination of folders and filters.

You could put them in different folders for the new and old machine for example or you can use filters based on filenames or show names or even old the recording is based on timestamps of last modified to determine if a conversion task (or monitor task) should process or monitor the files.

Well, it does seem like the names are the issue. I thought I had found the problem, here are the renaming rules I used:

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

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

The extra backslash was on the fast computer. However, I changed the old computer’s rule to include the backslash and it still reconverted.

Here are some relevant parts of the log. I just need to figure out why the names are seen as different:

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 removed] 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, thanks, I see. I thought the feature would check the filename to see if it existed in the destination directory and wouldn’t convert if the identical filename existed. That would seem to be a useful feature, but if it’s only relying on the history file I can see why it’s doing the reconversion.

(Though the log file seems to indicate that it may check for the destination file before reconverting:

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)

Yes, that feature also exists, Conversion task → Expert settings look for the option called Skip reconversion

This feature goes purely by the destination filename. You can see the pop up help for a detailed description but essentially when enabled, MCEBuddy will decide to skip the conversion if it finds that the “expected” name of file after the conversion matches that of a file that already exists in the destination directory. This is purely based on the expected destination filename, so be aware of renaming rules, destinations folders etc.

I’m no expert, and I think you already have the ultimate expert working with you, but can both copies of MCE be configured to use the same history file? Would that help?

I had the same thought, but I have no idea how to make it work. I couldn’t figure out why the names didn’t match, they seemed identical to me, so I’m just going to let my slow machine re-convert everything. It’s almost done, so that’s the inelegant way to solve the problem. I may look into it more if I have time at some point.