Bestaande bestanden herconverteren

General Support / Questions
1

Hoi, ik ben nieuw bij MCEBuddy. Ik heb twee licenties gekocht, één voor mijn oude Win 8.1 WMC-box met kabelkaart, en één voor mijn extreem snelle nieuwe machine met een discrete GPU.

Ik was van plan de snelle machine te gebruiken om de honderden bestaande opnames te transcoderen en de getranscodeerde bestanden van mijn WMC-machine naar mijn NAS-box te verplaatsen. Daarna zou ik MCEBuddy op de oude, langzame machine draaien om nieuwe opnames te transcoderen zodra ze binnenkwamen.

Het eerste deel werkte prima, maar MCEBuddy op de oude machine wil alle bestanden opnieuw transcoderen. Ik had de indruk dat het aanvinken van “skip reconversion” (omzetting overslaan) de bestemming zou controleren om te zien of de bestandsnaam (zoals deze zou worden hernoemd) bestaat, en zo ja, dat de conversie zou worden overgeslagen. Dat lijkt echter niet te werken. Mis ik iets?

Ik heb wel een aangepaste hernoemregel, maar precies dezelfde string op de snelle machine die de bibliotheek heeft geconverteerd en de langzame machine die ik alleen nieuwe opnames wil laten converteren.

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

Hier zijn een paar dingen die we kunnen controleren:

  1. Exacte Overeenkomst: De functie “overslaan hercodering” is afhankelijk van een exacte overeenkomst van de bestemmingsbestandsnaam. Zelfs een klein verschil, zoals een extra spatie of een andere hoofdletter, kan ervoor zorgen dat MCEBuddy het als een nieuw bestand beschouwt. Kunt u dubbel controleren of de hernoemingsregels op beide machines echt identiek zijn, teken voor teken? \[JD Absoluut, goed punt, zal dit controleren zodra ik thuiskom\]

    Bestemmingsmap: Is de bestemmingsmap op beide machines identiek geconfigureerd? MCEBuddy moet weten waar het naar de bestaande bestanden moet zoeken. \[JD Ja, ze zijn identiek, dezelfde map op mijn NAS-box, dezelfde referenties, enz.\]

  2. Bestandsattributen: Soms kunnen bestandsattributen (zoals aanmaakdatum of wijzigingsdatum) een rol spelen. Zijn de bestanden op een manier verplaatst of gekopieerd waardoor deze attributen significant zijn gewijzigd? \[JD Het enige wat met de bestanden is gebeurd, is dat MCEBuddy ze heeft getranscodeerd en naar een andere map heeft verplaatst, dat is vermoedelijk oké? ]

  3. Logbestanden: De logbestanden van MCEBuddy zouden zeer nuttig zijn om te begrijpen wat er gebeurt. Kunt u een fragment van het logboek van de oude machine delen wanneer deze probeert de bestanden opnieuw te transcoderen? Zoek naar vermeldingen met betrekking tot “overslaan hercodering” of de betreffende bestanden. \[JD Ja, zal er zeker naar kijken en de relevante delen plaatsen.\]

  4. MCEBuddy Versie: Hoewel het onwaarschijnlijk is dat dit de hoofdoorzaak is, zorgt ervoor dat beide machines dezelfde versie van MCEBuddy draaien, kan het mogelijke problemen met versiespecifieke eigenaardigheden uitsluiten. \[Ja, heb ze tegelijk gedownload, maar zal het dubbel controleren. Bovendien lijkt het erop dat hij opnieuw converteert, en niet alleen de reeds geconverteerde bestanden in de wachtrij plaatst.\]

Hartelijk dank voor de snelle reactie en de lijst met dingen om te controleren!

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

Dat geldt voor bestanden op dezelfde machine. MCEBuddy houdt een geschiedenis-bestand bij dat conversies in de config-map bijhoudt. Dus als je MCEBuddy op 2 afzonderlijke machines draait, weten ze niet wat de andere machine doet en kunnen ze dienovereenkomstig geen bestanden tussen machines bijhouden. Er zijn manieren om dit te omzeilen, zoek op het forum naar “Daisy Chaining” om te zien hoe je dit bereikt met een combinatie van mappen en filters.

Je zou ze bijvoorbeeld in verschillende mappen voor de nieuwe en oude machine kunnen plaatsen, of je kunt filters gebruiken op basis van bestandsnamen of programmanamen, of zelfs op basis van de tijdstempels van de laatste wijziging om te bepalen of een conversietaak (of monitor-taak) de bestanden moet verwerken of monitoren.

6

Nou, het lijkt erop dat de namen het probleem zijn. Ik dacht dat ik het probleem had gevonden, hier zijn de hernoemingsregels die ik heb gebruikt:

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

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

De extra backslash stond op de snelle computer. Ik heb echter de regel van de oude computer gewijzigd om de backslash op te nemen en deze werd nog steeds opnieuw geconverteerd.

Hier zijn enkele relevante delen van het logboek. Ik moet alleen uitzoeken waarom de namen als verschillend worden beschouwd:

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, bedankt, ik begrijp het. Ik dacht dat de functie de bestandsnaam zou controleren om te zien of deze in de doelmap bestond en niet zou converteren als dezelfde bestandsnaam al bestond. Dat lijkt een nuttige functie, maar als deze alleen afhankelijk is van het geschiedenisbestand, begrijp ik waarom deze de herconversie uitvoert.

(Hoewel het logbestand lijkt aan te geven dat het controleert op het doelbestand voordat het opnieuw wordt geconverteerd:

INFORMATION\u003e 2025-09-08T15:37:37 MCEBuddy.Engine.ConversionJob → Bestemmingbestand \\\\192.168.0.46\\User Homes\\johndefiore\\Media\\Converted\\TV SeriesEva Longoria Searching for MexicoEva Longoria Searching for Mexico.S01E02.Yucatan.mp4 bestaat niet, doorgaan met conversie)

8

Ja, die functie bestaat ook, Conversietaak → Expertinstellingen zoek naar de optie genaamd Skip reconversion

Deze functie werkt puur op basis van de bestemmingsbestandsnaam. U kunt de pop-up help raadplegen voor een gedetailleerde beschrijving, maar in wezen zal MCEBuddy, wanneer deze is ingeschakeld, besluiten de conversie over te slaan als het vaststelt dat de “verwachte” naam van het bestand na de conversie overeenkomt met die van een bestand dat al in de doelmap bestaat. Dit is puur gebaseerd op de verwachte bestemmingsbestandsnaam, dus wees u bewust van hernoemingsregels, doelmappen, enz.

image

9

Ik ben geen expert, en ik denk dat je al de ultieme expert bij je hebt, maar kunnen beide kopieën van MCE geconfigureerd worden om hetzelfde geschiedenisbestand te gebruiken? Zou dat helpen?

10

Ik had dezelfde gedachte, maar ik heb geen idee hoe ik het werkend moet krijgen. Ik kon er niet achter komen waarom de namen niet overeenkwamen, ze leken identiek voor mij, dus ik laat mijn trage machine gewoon alles opnieuw converteren. Het is bijna klaar, dus dat is de onelegante manier om het probleem op te lossen. Misschien kijk ik er later nog eens naar als ik tijd heb.