Genkonvertering af eksisterende filer

General Support / Questions
1

Hej - Jeg er ny hos MCEBuddy. Jeg købte to licenser, en til min gamle Win 8.1 WMC-boks med kabelkort og en til min ekstremt hurtige nye maskine med et dedikeret grafikkort.

Jeg regnede med at bruge den hurtige maskine til at transkode de hundredvis af eksisterende optagelser og flytte de transkodede filer fra min WMC-maskine til min NAS-boks. Derefter ville jeg køre MCEBuddy på den gamle, langsomme maskine for at transkode nye optagelser, efterhånden som de kom ind.

Den første del fungerede fint, men MCEBuddy på den gamle maskine vil gen-transkode alle filerne. Jeg var under indtryk af, at afkrydsning af “skip reconversion” (spring genkonvertering over) skulle tjekke destinationen for at se, om filnavnet (som det ville blive omdøbt til) eksisterer, og hvis det gør, ville den springe konverteringen over. Det ser dog ikke ud til at virke. Er der noget, jeg overser?

Jeg har en brugerdefineret omdøbningsregel, men præcis den samme streng på den hurtige maskine, der konverterede biblioteket, og den langsomme maskine, som jeg kun ønsker at konvertere nye optagelser på.

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

Her er et par ting, vi kan tjekke:

  1. Præcis Match: Funktionen “spring genkonvertering over” er afhængig af et præcist match af destinationsfilnavnet. Selv en lille forskel, som et ekstra mellemrum eller en anden store/små bogstaver, kan få MCEBuddy til at se det som en ny fil. Kan du dobbelttjekke, at omdøbingsreglerne på begge maskiner er fuldstændig identiske tegn for tegn? \[JD Helt sikkert, godt punkt, vil tjekke det, så snart jeg kommer hjem\]

    Destinationsmappe: Er destinationsmappen konfigureret identisk på begge maskiner? MCEBuddy skal vide, hvor det skal lede efter de eksisterende filer. \[JD Ja, de er identiske, den samme mappe på min NAS-boks, de samme legitimationsoplysninger osv.\]

  2. Filattributter: Nogle gange kan filattributter (som oprettelsesdato eller ændringsdato) spille en rolle. Er filerne blevet flyttet eller kopieret på en måde, der kan have ændret disse attributter væsentligt? \[JD Det eneste, der er sket med filerne, er, at MCEBuddy har transkodet dem og flyttet dem til en anden mappe, formodentlig er det OK? ]

  3. Logfiler: MCEBuddy-logfilerne ville være meget nyttige til at forstå, hvad der sker. Kan du dele et uddrag af loggen fra den gamle maskine, når den forsøger at genkonvertere filerne? Kig efter poster relateret til “spring genkonvertering over” eller de pågældende filer. \[JD Ja, vil helt sikkert kigge på det og poste alle relevante dele.\]

  4. MCEBuddy-version: Selvom det er usandsynligt, at det er hovedårsagen, kan det at sikre, at begge maskiner kører den samme version af MCEBuddy, eliminere potentielle versionsspecifikke særheder. \[Ja, downloadede dem på samme tid, men jeg vil dobbelttjekke. Det ser også ud til, at den genkonverterer, ikke bare sætter de allerede konverterede filer i kø.\]

Mange tak for det hurtige svar og listen over ting, jeg skal tjekke!

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

Det gælder for filer på den samme maskine. MCEBuddy gemmer en historik-fil, der sporer konverteringer i config-mappen. Så hvis du kører MCEBuddy på 2 separate maskiner, ved de ikke, hvad den anden laver, og kan derfor ikke spore filer mellem maskiner. Der er måder at omgå dette på, søg i forummet efter “Daisy Chaining” for at se, hvordan du opnår dette ved hjælp af en kombination af mapper og filtre.

Du kunne for eksempel placere dem i forskellige mapper til den nye og den gamle maskine, eller du kan bruge filtre baseret på filnavne eller programnavne eller endda den optagelse, det er baseret på tidsstempler for seneste ændring for at bestemme, om en konverteringsopgave (eller overvågningsopgave) skal behandle eller overvåge filerne.

6

Nå, det ser ud til, at navnene er problemet. Jeg troede, jeg havde fundet problemet, her er de omdøbningsregler, jeg brugte:

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

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

Den ekstra omvendte skråstreg var på den hurtige computer. Jeg ændrede dog den gamle computers regel til at inkludere den omvendte skråstreg, og den konverterede stadig tilbage.

Her er nogle relevante dele af loggen. Jeg skal bare finde ud af, hvorfor navnene opfattes som forskellige:

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, tak, jeg forstår. Jeg troede, funktionen ville tjekke filnavnet for at se, om det eksisterede i destinationsmappen, og ikke konvertere, hvis det identiske filnavn eksisterede. Det ville virke som en nyttig funktion, men hvis den kun er afhængig af historikfilen, kan jeg se, hvorfor den genkonverterer.

(Selvom logfilen ser ud til at indikere, at den muligvis tjekker for destinationsfilen, før den genkonverterer:

INFORMATION\u003e 2025-09-08T15:37:37 MCEBuddy.Engine.ConversionJob → Destinationsfil \\\\192.168.0.46\\User Homes\\johndefiore\\Media\\Converted\\TV SeriesEva Longoria Searching for MexicoEva Longoria Searching for Mexico.S01E02.Yucatan.mp4 eksisterer ikke, fortsætter med konvertering))

8

Ja, den funktion findes også, Konverteringsopgave → Ekspertindstillinger se efter muligheden kaldet Skip reconversion

Denne funktion er udelukkende baseret på destinationsfilnavnet. Du kan se pop op-hjælpen for en detaljeret beskrivelse, men dybest set, når den er aktiveret, vil MCEBuddy beslutte at springe konverteringen over, hvis den finder ud af, at det “forventede” navn på filen efter konverteringen stemmer overens med navnet på en fil, der allerede findes i destinationsmappen. Dette er udelukkende baseret på det forventede destinationsfilnavn, så vær opmærksom på navngivningsregler, destinationsmapper osv.

image

9

Jeg er ikke ekspert, og jeg tror, du allerede har den ultimative ekspert, der arbejder sammen med dig, men kan begge kopier af MCE konfigureres til at bruge den samme historikfil? Ville det hjælpe?

10

Jeg havde den samme tanke, men jeg aner ikke, hvordan jeg får det til at virke. Jeg kunne ikke finde ud af, hvorfor navnene ikke stemte overens, de virkede identiske for mig, så jeg lader bare min langsomme maskine konvertere alt igen. Det er næsten færdigt, så det er den uelegant måde at løse problemet på. Jeg vil måske undersøge det nærmere, hvis jeg får tid på et tidspunkt.