Reconversion des fichiers existants

General Support / Questions
1

Bonjour, je suis nouveau sur MCEBuddy. J’ai acheté deux licences, une pour mon ancien boîtier WMC sous Win 8.1 avec carte câble, et une pour ma nouvelle machine extrêmement rapide avec un GPU discret.

J’ai pensé utiliser la machine rapide pour transcoder les centaines d’enregistrements existants, en déplaçant les fichiers transcodés de ma machine WMC vers mon boîtier NAS. Ensuite, j’exécuterais MCEBuddy sur l’ancienne machine lente pour transcoder les nouveaux enregistrements au fur et à mesure qu’ils arrivent.

La première partie a fonctionné correctement, mais MCEBuddy sur l’ancienne machine veut retravailler tous les fichiers. J’avais cru comprendre que cocher « sauter la reconversion » (skip reconversion) vérifierait la destination pour voir si le nom de fichier (tel qu’il serait renommé) existe, et si oui, cela sauterait la conversion. Cependant, cela ne semble pas fonctionner. Est-ce que je manque quelque chose ?

J’ai bien une règle de renommage personnalisée, mais exactement la même chaîne sur la machine rapide qui a converti la bibliothèque et sur la machine lente que je veux seulement convertir les nouveaux enregistrements.

2

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.

3

Voici quelques éléments que nous pouvons vérifier :

  1. Correspondance exacte : La fonctionnalité « ignorer la reconversion » repose sur une correspondance exacte du nom de fichier de destination. Même une légère différence, comme un espace supplémentaire ou une casse différente, peut amener MCEBuddy à le considérer comme un nouveau fichier. Pourriez-vous vérifier que les règles de renommage sur les deux machines sont véritablement identiques caractère par caractère ? \[JD Absolument, excellente remarque, je vais vérifier cela dès que je rentre à la maison\]

    Dossier de destination : Le dossier de destination est-il configuré de manière identique sur les deux machines ? MCEBuddy doit savoir où chercher les fichiers existants. \[JD Oui, ils sont identiques, le même dossier sur mon boîtier NAS, les mêmes identifiants, etc.\]

  2. Attributs de fichier : Parfois, les attributs de fichier (comme la date de création ou la date de modification) peuvent jouer un rôle. Les fichiers ont-ils été déplacés ou copiés d’une manière qui aurait pu modifier significativement ces attributs ? \[JD la seule chose qui est arrivée aux fichiers, c’est que MCEBuddy les a transcodés et déplacés vers un répertoire différent, c’est supposément OK ?\]

  3. Fichiers journaux (Logs) : Les fichiers journaux de MCEBuddy seraient très utiles pour comprendre ce qui se passe. Pouvez-vous partager un extrait du journal de l’ancienne machine lorsqu’elle tente de re-transcoder les fichiers ? Recherchez les entrées liées à « ignorer la reconversion » ou aux fichiers en question. \[JD Oui, je vais certainement y jeter un œil et publier toute partie pertinente.\]

  4. Version de MCEBuddy : Bien que peu probable d’être la cause principale, s’assurer que les deux machines exécutent la même version de MCEBuddy pourrait éliminer toute bizarrerie potentielle spécifique à une version. \[Oui, je les ai téléchargées en même temps, mais je vais vérifier. De plus, il semble qu’il reconvertisse réellement, et pas seulement qu’il mette en file d’attente les fichiers déjà convertis.\]

Un grand merci pour la réponse rapide et la liste des choses à vérifier !

4

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.

5

Ceci s’applique aux fichiers sur la même machine. MCEBuddy conserve un fichier d’historique qui suit les conversions dans le dossier config. Donc, si vous exécutez MCEBuddy sur 2 machines séparées, elles ne savent pas ce que l’autre fait et par conséquent ne peuvent pas suivre les fichiers entre les machines. Il existe des solutions, recherchez sur le forum « Daisy Chaining » pour voir comment y parvenir en utilisant une combinaison de dossiers et de filtres.

Vous pourriez par exemple les placer dans des dossiers différents pour la nouvelle et l’ancienne machine, ou vous pouvez utiliser des filtres basés sur les noms de fichiers ou les noms d’émissions, ou même l’enregistrement est basé sur les horodatages de la dernière modification pour déterminer si une tâche de conversion (ou une tâche de surveillance) doit traiter ou surveiller les fichiers.

6

Eh bien, il semble que les noms soient le problème. Je pensais avoir trouvé le problème, voici les règles de renommage que j’ai utilisées :

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

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

L’antislash supplémentaire se trouvait sur l’ordinateur rapide. Cependant, j’ai modifié la règle de l’ancien ordinateur pour inclure l’antislash et il a quand même reconverti.

Voici quelques parties pertinentes du journal. J’ai juste besoin de comprendre pourquoi les noms sont considérés comme différents :

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

7

Ah, je vois, merci. Je pensais que la fonctionnalité vérifierait le nom de fichier pour voir s’il existait dans le répertoire de destination et ne convertirait pas si le nom de fichier identique existait. Cela semblerait être une fonctionnalité utile, mais si elle ne repose que sur le fichier d’historique, je comprends pourquoi elle effectue la reconversion.

(Bien que le fichier journal semble indiquer qu’il vérifie le fichier de destination avant la reconversion :

INFORMATION\u003e 2025-09-08T15:37:37 MCEBuddy.Engine.ConversionJob → Le fichier de destination \\\\192.168.0.46\\User Homes\\johndefiore\\Media\\Converted\\TV SeriesEva Longoria Searching for MexicoEva Longoria Searching for Mexico.S01E02.Yucatan.mp4 n’existe pas, poursuite de la conversion)

8

Oui, cette fonctionnalité existe également, Tâche de conversion → Paramètres d’expert, recherchez l’option appelée Skip reconversion (Ignorer la reconversion)

Cette fonctionnalité se base uniquement sur le nom de fichier de destination. Vous pouvez consulter l’aide contextuelle pour une description détaillée, mais en substance, lorsqu’elle est activée, MCEBuddy décidera d’ignorer la conversion s’il constate que le nom « attendu » du fichier après la conversion correspond à celui d’un fichier qui existe déjà dans le répertoire de destination. Ceci est basé uniquement sur le nom de fichier de destination attendu, soyez donc attentif aux règles de renommage, aux dossiers de destination, etc.

image

9

Je ne suis pas un expert, et je pense que vous avez déjà l’expert ultime qui travaille avec vous, mais les deux copies de MCE peuvent-elles être configurées pour utiliser le même fichier d’historique ? Cela aiderait-il ?

10

J’ai eu la même pensée, mais je n’ai aucune idée de comment la faire fonctionner. Je n’arrivais pas à comprendre pourquoi les noms ne correspondaient pas, ils me semblaient identiques, alors je vais simplement laisser ma machine lente tout reconvertir. C’est presque terminé, c’est donc la manière peu élégante de résoudre le problème. Je vais peut-être y regarder de plus près si j’ai le temps à un moment donné.