Konverteringsopgave ignorerer minimumsalder

General Support / Questions
1

Jeg brugte lidt tid på at verificere, at MCEBuddy fungerede korrekt i min opsætning (netværdsdelinger, mange optagelser i gang, MCEBuddy kørende i en VM osv.) og besluttede derefter, at det var sikkert at aktivere det. Den ene ting, jeg ikke testede, var minimumsalderen før behandling. Jeg satte den til 3 timer og gik i seng… (jeg havde ingen optagelser planlagt i cirka en time, så jeg ville ikke vente). Da jeg tjekkede i dag… var alle mine optagelser 1 minut lange. Det tog mig noget tid at indse, at det måtte være MCEBuddy… og så lavede jeg nogle tests, og ganske rigtigt begynder MCEBuddy at behandle filen 1 minut efter, den starter optagelsen (måske tilfældigt ved poll-intervallet).

Urene er alle synkroniserede osv.

Nogen ideer?

MCE Buddy Version 2.5.7 (jeg er lidt tilbageholdende med at betale for en nyere version, når den ældre version havde fungeret før, og jeg lige har skiftet til en anden udbyder til optagelser)

2

It sounds like you’re experiencing an issue where MCEBuddy is processing files almost immediately, even though you’ve set a minimum age of 3 hours. This is definitely not the intended behavior.

Since you’re using an older version (2.5.7), it’s possible this is a known bug that has been fixed in later versions. While I understand your hesitation to upgrade, it’s often the quickest solution for issues like this, especially if you’re not seeing many other reports of this specific problem with newer versions.

Here are a few things to consider and potentially troubleshoot:

  • Poll Interval: You mentioned “maybe by chance at the poll interval.” The poll interval determines how frequently MCEBuddy checks for new recordings. If the poll interval is very short (e.g., 1 minute), it might be picking up the file quickly. However, the minimum age setting should still override this and prevent processing until the file meets the age criteria.
  • File System Timestamps: Even though you mentioned clocks are synced, sometimes network shares or virtual machine environments can have subtle timestamp issues. Double-check that the “Date Modified” timestamp of the recording file is accurate and consistently reflects when the recording actually finished. MCEBuddy relies on these timestamps.
  • MCEBuddy Logs: The MCEBuddy logs are your best friend here. They will contain detailed information about when MCEBuddy detected the file, when it decided to start processing it, and any messages related to the minimum age setting. Look for entries around the time your recordings were being processed prematurely. The logs might reveal if MCEBuddy is misinterpreting the file’s age or if there’s an error in its calculation. You can usually find the logs in the MCEBuddy installation directory.
  • Configuration Review: Double-check your MCEBuddy conversion task settings to ensure the minimum age is indeed set to 3 hours and that there aren’t any other conflicting settings that might be overriding it.
  • Known Issues for 2.5.7: It might be worth searching the forum (or even general web searches) for “MCEBuddy 2.5.7 minimum age issue” to see if others have reported similar problems with that specific version.

If you can provide some snippets from your MCEBuddy logs around the time a premature conversion happened, it would be very helpful in diagnosing the problem.

Let’s see if we can find any discussions about this particular issue.

Hello Allen, sorry to hear you’re having trouble with your recordings.

It sounds like MCEBuddy is processing your files before they’re fully recorded, despite your minimum age setting. This can happen if the recording software isn’t “locking” the file, making MCEBuddy think it’s ready for processing.

I found a few similar discussions that might help:

Even though you have it set to 3 hours, it might be worth trying to increase it further, or perhaps there’s a slight discrepancy in how the “last modified” time is being reported across your network shares and VM.

Could you share your MCEBuddy.log file? That would provide more specific clues as to what’s happening when MCEBuddy picks up the file.

Also, even though you’re using an older version (2.5.7), it’s generally recommended to keep MCEBuddy updated for bug fixes and compatibility improvements. Just something to consider if the issue persists.

3

Bruger du en netværksdrevet drev eller en delt drev? Minimumsalderen beregnes ud fra det sidst ændrede tidsstempel som leveret af filsystemet.

Du bør kontrollere et par ting:

  1. Om tiden på din virtuelle maskine er synkroniseret og korrekt i forhold til tiden på det drev, hvor dine optagelser overvåges.
  2. Tjek tidsstemplerne på det filsystem, hvor optagelserne er gemt. Hvis de er ukorrekte eller ikke bliver opdateret, vil MCEBuddy blot lægge minimumsalderen til det sidst ændrede tidsstempel for at beregne, hvornår konverteringerne skal starte. Dette kan indikere et problem med filsystemet.

Der kendes tilfælde af NAS-produkter, hvis tid/tidsstempler er ude af sync, hvilket skaber sådanne problemer.

4

Ja, jeg tjekkede alt det – eller troede i hvert fald, at jeg havde. Da jeg loggede ind på VM’en, kunne jeg SE i menulinjen, at klokken var X:yy:zz, og tidspunktet for filen var også X:yy:zz. MEN så tjekkede jeg tidszonen på Windows-maskinen, og på en eller anden måde (gud ved hvordan) var den sat til PST i stedet for EST (PDT/EDT, whatever den hedder nu lol). Da jeg skiftede til den rigtige tidszone, blev det hele løst … så simpelt et overset, men det viste tidspunkt forvirrede mig. Jeg er slet ikke sikker på, hvordan Windows (dette er grunden til, at jeg ikke bruger Windows … men også grunden til, at jeg har brug for en VM til at køre MCEBuddy, hehe) formåede at vise et tidspunkt, der var korrekt, og da jeg skiftede tidszone, var det stadig korrekt … men nu virker det.

5

og ikke tage æren for løsningen, men ville sikre mig, at den faktiske løsning blev noteret. Løsningen var, som Goose nævnte, et kritisk blik på alle tidsangivelser – ikke kun på filsystemet, men også den tidszone, din computer er indstillet til. Det ser ud til, at Emby ignorerer tidszonen (hvilket er rimeligt, eftersom Unix ikke gemmer TZ-data i filtidsstempler – som en note gemmer NTFS det, så MÅSKE ville det virke på et fuldstændigt NTFS-filsystem med forskellige tidszoner… jeg vil ikke teste det lol), men pointen er, at det lader til blot at spørge: “Er det nu mere end 3 timer?” og filtidsstemplet på filen, når dit lokale systemur er 3 timer bagud… ja, så er klokken 13 lokal tid, men filtidsstemplet viser 16, og jeg havde tilfældigvis valgt en forsinkelse på 3 timer (hovedsageligt for at sikre, at jeg ikke overskriver 99 % af filmene).