Tâche de conversion ignorant l'âge minimum

J’ai pris le temps de vérifier que MCE Buddy fonctionnait correctement dans ma configuration (partages réseau, nombreux enregistrements en cours, MCE Buddy tournant dans une VM, etc.), puis j’ai décidé que j’étais en sécurité pour l’activer. La seule chose que je n’ai pas testée était l’âge minimum avant traitement. Je l’ai réglé à 3 heures et je suis allé me coucher… (je n’avais aucun enregistrement prévu pendant environ une heure, donc je ne voulais pas attendre). Quand j’ai vérifié aujourd’hui… tous mes enregistrements faisaient 1 minute. Il m’a fallu un moment pour réaliser que cela devait être MCE Buddy… puis j’ai fait des tests et, en effet, MCE Buddy commence à traiter le fichier 1 minute après le début de l’enregistrement (peut-être par hasard à l’intervalle d’interrogation).

Les horloges sont toutes synchronisées, etc.

Des idées ?

MCE Buddy Version 2.5.7 (je suis un peu réticent à payer pour une version plus récente alors que l’ancienne version fonctionnait auparavant, et je viens de changer de fournisseur pour l’enregistrement).

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.

Utilisez-vous un lecteur réseau mappé ou un lecteur partagé ? L’âge minimum est calculé à partir de l’horodatage de dernière modification fourni par le système de fichiers.

Vous voudrez peut-être vérifier quelques éléments :

  1. Si l’heure de votre machine virtuelle est synchronisée et correcte avec l’heure du lecteur où vos enregistrements sont surveillés.
  2. Vérifiez les horodatages sur le système de fichiers où les enregistrements sont stockés. S’ils sont incorrects ou ne sont pas mis à jour, MCEBuddy ajoutera simplement l’âge minimum à l’horodatage de dernière modification pour calculer quand démarrer les conversions. Cela peut indiquer un problème avec le système de fichiers.

Il existe des cas connus de produits NAS dont l’heure / les horodatages sont désynchronisés, ce qui crée de tels problèmes.

Oui, j’ai vérifié tout ça, ou du moins je le pensais. Quand je me suis connecté à la VM, je pouvais VOIR dans la barre de menu que l’heure était X:yy:zz et l’heure à laquelle le fichier a été écrit était X:yy:zz. MAIS ensuite j’ai vérifié le fuseau horaire défini sur la machine Windows et, d’une manière ou d’une autre (qui sait comment), il était réglé sur PST au lieu d’EST (PDT/EDT, peu importe lequel c’est maintenant lol). Le changer vers le bon fuseau horaire a tout réglé… une erreur si simple, mais l’heure affichée me trompait. Je ne suis pas du tout certain de comment Windows (c’est pour ça que je n’utilise pas Windows… mais aussi pourquoi j’ai besoin d’une VM pour faire tourner MCEBuddy haha) a réussi à afficher une heure correcte et, quand j’ai changé le fuseau horaire, elle est restée correcte… mais maintenant c’est réglé.

et ne pas s’approprier la solution, mais voulait simplement s’assurer que la vraie solution soit bien notée. la solution était, comme Goose l’a mentionné, un regard critique sur toutes les heures, non seulement sur le système de fichiers, mais aussi le fuseau horaire auquel votre ordinateur est réglé. il semble qu’Emby ignore le fuseau horaire (ce qui est raisonnable, je suppose, puisqu’Unix ne stocke PAS les données de TZ dans les horodatages de fichiers — à noter que NTFS le fait, donc PEUT-ÊTRE que cela fonctionnerait sur un système de fichiers entièrement NTFS avec des fuseaux horaires différents… je ne vais pas tester lol), mais le fait est qu’il semble simplement dire « est-ce maintenant plus de 3 heures… » et l’horodatage du fichier, quand l’horloge système locale est en retard de 3 heures… eh bien, il est 13h en local, mais l’horodatage du fichier indiquera 16h, et j’ai par hasard choisi un délai de 3 heures (principalement pour m’assurer de ne pas écraser 99 % des films).