Reconversión de archivos existentes

Hola, soy nuevo en MCEBuddy. Compré dos licencias, una para mi antigua máquina WMC con Win 8.1 y tarjeta de cable, y otra para mi nueva máquina extremadamente rápida con una GPU dedicada.

Pensé en usar la máquina rápida para transcodificar los cientos de grabaciones existentes, moviendo los archivos transcodificados de mi máquina WMC a mi NAS. Luego ejecutaría MCEBuddy en la máquina vieja y lenta para transcodificar las nuevas grabaciones a medida que llegaran.

La primera parte funcionó bien, pero MCEBuddy en la máquina vieja quiere volver a transcodificar todos los archivos. Tenía la impresión de que marcar “omitir reconversión” debería verificar el destino para ver si el nombre del archivo (tal como se renombraría) existe y, de ser así, omitiría la conversión. Sin embargo, eso no parece estar funcionando. ¿Me estoy perdiendo algo?

Tengo una regla de renombrado personalizada, pero exactamente la misma cadena en la máquina rápida que convirtió la biblioteca y en la máquina lenta que solo quiero que convierta las nuevas grabaciones.

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.

Aquí hay algunas cosas que podemos verificar:

  1. Coincidencia Exacta: La función “omitir reconversión” depende de una coincidencia exacta del nombre de archivo de destino. Incluso una ligera diferencia, como un espacio adicional o una mayúscula diferente, puede hacer que MCEBuddy lo vea como un archivo nuevo. ¿Podrías verificar dos veces que las reglas de cambio de nombre en ambas máquinas sean verdaderamente idénticas carácter por carácter? \[JD Absolutamente, excelente punto, lo verificaré tan pronto como llegue a casa\]

    Carpeta de Destino: ¿Está configurada la carpeta de destino de manera idéntica en ambas máquinas? MCEBuddy necesita saber dónde buscar los archivos existentes. \[JD Sí, son idénticas, la misma carpeta en mi caja NAS, las mismas credenciales, etc.\]

  2. Atributos de Archivo: A veces, los atributos de archivo (como la fecha de creación o la fecha de modificación) pueden influir. ¿Se han movido o copiado los archivos de una manera que pueda haber alterado significativamente estos atributos? \[JD Lo único que les ha pasado a los archivos es que MCEBuddy los transcodificó y los movió a un directorio diferente, ¿supongo que eso está bien?\]

  3. Archivos de Registro (Logs): Los archivos de registro (logs) de MCEBuddy serían muy útiles para entender lo que está sucediendo. ¿Puedes compartir un fragmento del registro de la máquina antigua cuando intenta retranscodificar los archivos? Busca entradas relacionadas con “omitir reconversión” o los archivos en cuestión. \[JD Sí, definitivamente echaré un vistazo y publicaré cualquier parte relevante.\]

  4. Versión de MCEBuddy: Aunque es poco probable que sea la causa principal, asegurarse de que ambas máquinas estén ejecutando la misma versión de MCEBuddy podría eliminar cualquier posible peculiaridad específica de la versión. \[Sí, las descargué al mismo tiempo, pero lo verificaré dos veces. Además, parece que está volviendo a convertir, no solo poniendo en cola los archivos que ya se convirtieron.\]

¡Muchas gracias por la rápida respuesta y la lista de cosas para verificar!

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.

Eso se aplica a los archivos en la misma máquina. MCEBuddy mantiene un archivo de historial que rastrea las conversiones en la carpeta config. Por lo tanto, si está ejecutando MCEBuddy en 2 máquinas separadas, no sabrán lo que está haciendo la otra y, en consecuencia, no podrán rastrear archivos entre máquinas. Hay formas de evitar esto, busque en el foro “Daisy Chaining” para ver cómo lograrlo mediante una combinación de carpetas y filtros.

Podría ponerlos en carpetas diferentes para la máquina nueva y la antigua, por ejemplo, o puede usar filtros basados en nombres de archivo o nombres de programas o incluso si la grabación se basa en marcas de tiempo de última modificación para determinar si una tarea de conversión (o tarea de monitoreo) debe procesar o monitorear los archivos.

Bueno, parece que los nombres son el problema. Pensé que había encontrado el problema, aquí están las reglas de cambio de nombre que usé:

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

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

La barra invertida adicional estaba en la computadora rápida. Sin embargo, cambié la regla de la computadora antigua para incluir la barra invertida y todavía se reconvirtió.

Aquí hay algunas partes relevantes del registro. Solo necesito averiguar por qué los nombres se ven diferentes:

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, entiendo. Pensé que la función comprobaría el nombre del archivo para ver si existía en el directorio de destino y no convertiría si el nombre de archivo idéntico ya existía. Eso parecería una característica útil, pero si solo se basa en el archivo de historial, puedo ver por qué está realizando la reconversión.

(Aunque el archivo de registro parece indicar que puede comprobar si el archivo de destino existe antes de reconvertir:

INFORMATION\u003e 2025-09-08T15:37:37 MCEBuddy.Engine.ConversionJob → El archivo de destino \\\\192.168.0.46\\User Homes\\johndefiore\\Media\\Converted\\TV SeriesEva Longoria Searching for MexicoEva Longoria Searching for Mexico.S01E02.Yucatan.mp4 no existe, continuando con la conversión)

Sí, esa característica también existe, Tarea de conversión → Configuración de experto busque la opción llamada Omitir reconversión

Esta característica se basa puramente en el nombre de archivo de destino. Puede ver la ayuda emergente para una descripción detallada, pero esencialmente, cuando está habilitada, MCEBuddy decidirá omitir la conversión si encuentra que el nombre “esperado” del archivo después de la conversión coincide con el de un archivo que ya existe en el directorio de destino. Esto se basa puramente en el nombre de archivo de destino esperado, así que tenga cuidado con las reglas de cambio de nombre, las carpetas de destino, etc.

image

No soy un experto, y creo que ya tienes al experto definitivo trabajando contigo, pero ¿se pueden configurar ambas copias de MCE para que usen el mismo archivo de historial? ¿Eso ayudaría?

Tuve el mismo pensamiento, pero no tengo idea de cómo hacerlo funcionar. No pude entender por qué los nombres no coincidían, me parecían idénticos, así que simplemente dejaré que mi máquina lenta reconvierta todo. Ya casi termina, así que esa es la forma poco elegante de resolver el problema. Puede que lo investigue más si tengo tiempo en algún momento.