Konvertierungsaufgabe ignoriert Mindestalter

Ich nahm mir Zeit, um zu prüfen, ob MCE Buddy in meinem Setup korrekt funktioniert (Netzwerkfreigaben, viele gleichzeitige Aufnahmen, MCE Buddy läuft in einer VM usw.), und entschied mich dann, es zu aktivieren. Das Einzige, was ich nicht getestet hatte, war das Mindestalter vor der Verarbeitung. Ich stellte es auf 3 Stunden und ging schlafen … (ich hatte für etwa eine Stunde keine Aufnahmen geplant, wollte also nicht warten). Als ich heute nachschaute … waren alle meine Aufnahmen 1 Minute lang. Es dauerte eine Weile, bis ich realisierte, dass es MCE Buddy sein muss … und dann machte ich ein paar Tests, und tatsächlich beginnt MCE Buddy die Datei 1 Minute nach Beginn der Aufnahme zu verarbeiten (wahrscheinlich zufällig im Abfrageintervall).

Die Uhren sind alle synchronisiert usw.

Irgendwelche Hinweise?

MCE Buddy Version 2.5.7 (ich bin etwas abgeneigt, für eine neuere Version zu zahlen, wenn die ältere Version vorher funktioniert hat, und ich habe gerade einen anderen Anbieter für Aufnahmen bekommen).

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.

Verwenden Sie ein netzwerkgemapptes Laufwerk oder ein gemeinsames Laufwerk? Das Mindestalter wird aus dem Zeitstempel der letzten Änderung ermittelt, wie er vom Dateisystem bereitgestellt wird.

Sie sollten einige Dinge überprüfen:

  1. Ob die Zeit auf Ihrer virtuellen Maschine synchron und korrekt mit der Zeit auf dem Laufwerk ist, auf dem Ihre Aufzeichnungen überwacht werden.
  2. Prüfen Sie die Zeitstempel auf dem Dateisystem, auf dem die Aufzeichnungen gespeichert sind. Falls sie falsch sind oder nicht aktualisiert werden, wird MCEBuddy einfach das Mindestalter zum Zeitstempel der letzten Änderung addieren, um zu berechnen, wann mit den Konvertierungen begonnen werden soll. Dies kann auf ein Problem mit dem Dateisystem hindeuten.

Es sind Fälle bekannt, bei denen NAS-Produkte ihre Zeit/Zeitstempel nicht synchronisiert haben, was zu solchen Problemen führt.

Ja, ich habe all das geprüft – oder dachte zumindest, ich hätte es. Als ich mich bei der VM einloggte, konnte ich in der Menüleiste SEHEN, dass die Uhrzeit X:yy:zz war, und die Datei wurde ebenfalls um X:yy:zz geschrieben. ABER dann habe ich die Zeitzone auf dem Windows-Rechner überprüft, und IRGENDWIE (wer weiß wie) war sie auf PST statt EST (PDT/EDT, wie auch immer es gerade ist, lol) eingestellt. Als ich sie auf die richtige Zeitzone umgestellt habe, war alles behoben… so ein einfacher Fehler, aber die angezeigte Zeit hat mich durcheinandergebracht. Ich habe keine Ahnung, wie Windows (das ist auch der Grund, warum ich Windows nicht nutze… aber eben auch, warum ich eine VM brauche, um MCEBuddy laufen zu lassen, hehe) eine Zeit anzeigen konnte, die stimmte, und nachdem ich die Zeitzone geändert habe, war sie immer noch richtig… aber jetzt ist es behoben.

und nicht die Lösung für sich beanspruchen, aber sicherstellen wollte, dass die tatsächliche Lösung vermerkt ist. Die Lösung war, wie Goose erwähnte, ein kritischer Blick auf alle Zeitangaben – nicht nur im Dateisystem, sondern auch auf die Zeitzone, auf die dein Computer eingestellt ist. Es scheint, dass Emby die Zeitzone ignoriert (was vernünftig ist, da Unix keine Zeitzonen in Dateizeitstempeln speichert – als Hinweis: NTFS tut das, also KÖNNTE es auf einem vollständigen NTFS-Dateisystem mit verschiedenen Zeitzonen funktionieren… werde es aber nicht testen, lol), aber der Punkt ist, dass es einfach prüft: Ist es jetzt mehr als 3 Stunden her? Und der Zeitstempel der Datei, wenn deine lokale Systemuhr 3 Stunden zurückliegt… nun, es ist 13:00 Uhr Ortszeit, aber der Dateistempel zeigt 16:00 Uhr, und ich hatte zufällig eine Verzögerung von 3 Stunden ausgewählt (hauptsächlich um sicherzustellen, dass ich nicht 99 % der Filme übersehe).