Lige siden jeg opgraderede til version 2.5.7, har jeg bemærket en lejlighedsvis konvertering, der kører mere end én gang uden en “periode”. I går aftes kørte The Blacklist og en Hallmark-film mere end én gang. Jeg har vedhæftet logfilerne til gennemsyn.
Tak.
mcebuddy.zip (333,0 KB)
Flytter dette til et nyt emne, tak for logfilerne. Vi har identificeret den potentielle årsag til, hvorfor nogle af dine konverterede filer havner i en konverteringsløkke, som skyldes en race condition, når systemet er under hård belastning.
Dette er blevet rettet i dagens 2.5.7 BETA-build, prøv den og lad mig vide, om du stadig oplever problemer.
Jeg vil lade dig vide, hvis det sker med den nye build. Tak.
@Goose
Jeg oplevede endnu en konverteringsløkke i går aftes. Her er logfilerne.
Tak,
dcmcebuddy.zip (163,3 KB)
Okay, jeg tror, vi har fundet en potentiel race condition, hvor monitorplaceringen hentede den nye fil, før motoren kunne registrere den konverterede fil. Vi har implementeret en rettelse. Prøv dagens 2.5.7 BETA-build, og dette burde nu være løst.
Tak, jeg installerer den nye version i dag.
@Goose
Se venligt de vedhæftede logs fra gårsdagens dobbeltkonvertering.
Tak,
djc
mcebuddy.zip|vedhæftet (69,1 KB)
Hmm, okay, vi tror, vi ved, hvad der foregår, og det har noget at gøre med, at dit netværksfilsystem rapporterer en forkert status, som vildleder MCEBuddy.
Det, der sker, er, at din destinationsmappe er en netværdsmappe. Den oprindelige fil er cirka 5 GB stor, og det tager lang tid at flytte filen til destinationsnetværdsmappen, som også tilfældigvis er din kildemappe, der overvåges af Monitor-lokationen. Så når den konverterede fil kopieres, og Monitor-opgaven på det pågældende tidspunkt beslutter at scanne din mappe, vises den nye konverterede fil. Ideelt set vil et normalt system rapportere filen som skrevet/låst, så MCEBuddy springer den over. Af en eller anden grund rapporterer dit netværksdrev, at filen er klar til læsning, hvilket vildleder MCEBuddy til at tro, at den er tilgængelig, og den ender med at tilføje den til køen.
Vi har implementeret en rettelse til at håndtere sådanne filsystemer, som kan rapportere en ukorrekt fillåsestatus, så med dagens 2.5.7 BETA-build burde det være løst.
Som reference ville den alternative måde at løse dette på være at øge Minimumsalderen for filen i Monitor-opgavens avancerede indstillinger (standard 1 min – i dit tilfælde tog kopieringsprocessen over 1 minut) til f.eks. 30 minutter. Dette betyder, at selv hvis filsystemet fejlagtigt rapporterer, at filen er klar (når den faktisk er låst til skrivning), vil MCEBuddy vente 30 minutter, før den tilføjer den til køen, og på det tidspunkt vil konverteringen være afsluttet, og databaserne opdateret, så når 30 minutter er gået, vil den registrere den som allerede konverteret og springe den over.
Jeg vil prøve den nye version og øge minimumsalderstiden i morgen. Jeg har dog et spørgsmål: Da dette problem først opstod, efter at problemet med filnavnet, der sluttede med et punktum, blev rettet, hvorfor sker det så nu?
Før denne rettelse oplevede jeg kun dette problem, når filnavnet sluttede med et punktum.
Jeg sætter virkelig al din hjælp pris.
Dette er to helt forskellige og urelaterede problemer. Det første var en fejl i, hvordan punktummet blev håndteret (ignoreret af Windows men ikke af MCEBuddy), hvilket forårsagede et mismatch i filnavnet.
Det andet er et race condition, der opstår under helt bestemte omstændigheder (monitoropgaven skal køre en scanning lige når filen flyttes) og muligvis forårsaget af en ændring i, hvordan dit netværksfilsystem rapporterer (eller ikke rapporterer) låste filer.
Med denne opdatering bør du ikke behøve at øge minimumsalderen. Prøv det først for at bekræfte, at det fungerer som forventet.
Indtil videre har der ikke været nogen problemer at rapportere.