Tarea de conversión ignorando la edad mínima

General Support / Questions
1

Me tomé un tiempo para validar que MCE Buddy funcionara correctamente en mi configuración (compartidos de red, muchas grabaciones simultáneas, MCE Buddy ejecutándose en una VM, etc.) y luego decidí que era seguro activarlo. Lo único que no probé fue la edad mínima antes del procesamiento. Lo configuré en 3 horas y me fui a dormir… (no tenía grabaciones programadas por una hora, así que no quise esperar). Cuando revisé hoy… todas mis grabaciones duraban 1 minuto. Me llevó un tiempo darme cuenta de que debía ser MCE Buddy… y luego hice algunas pruebas y, efectivamente, MCE Buddy comienza a procesar el archivo 1 minuto después de que comienza la grabación (quizás por coincidencia en el intervalo de sondeo).

Los relojes están todos sincronizados, etc.

¿Alguna pista?

MCE Buddy versión 2.5.7 (me cuesta pagar por una versión más nueva cuando la anterior había estado funcionando. Y acabo de conseguir otro proveedor para grabar).

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

¿Estás utilizando una unidad de red asignada o una unidad compartida? La edad mínima se calcula a partir de la marca de tiempo de última modificación proporcionada por el sistema de archivos.

Quizás quieras revisar algunas cosas:

  1. Si la hora de tu máquina virtual está sincronizada y es correcta con respecto a la hora de la unidad donde se están monitoreando tus grabaciones.
  2. Verifica las marcas de tiempo en el sistema de archivos donde se almacenan las grabaciones. Si son incorrectas o no se están actualizando, MCEBuddy simplemente sumará la edad mínima a la marca de tiempo de última modificación para calcular cuándo iniciar las conversiones. Esto puede indicar un problema con el sistema de archivos.

Se conocen casos de productos NAS cuya hora o marcas de tiempo están desincronizadas, lo que genera este tipo de problemas.

4

Sí, revisé todo eso o al menos creí haberlo hecho. Cuando inicié sesión en la VM, podía VER en la barra de menús que la hora era X:yy:zz y la hora en que se escribió el archivo era X:yy:zz. PERO luego verifiqué la zona horaria configurada en la máquina Windows y, DE ALGUNA MANERA (quién sabe cómo), estaba configurada en PST en lugar de EST (PDT/EDT, lo que sea ahora jajaja). Cambiarla a la zona horaria correcta lo arregló todo… un error tan simple, pero la hora que se mostraba me estaba confundiendo. No tengo ni idea de cómo Windows (por eso no uso Windows… pero también por eso necesito una VM para ejecutar MCEBuddy jeje) logró mostrar una hora que era correcta y, cuando cambié la zona horaria, seguía siendo correcta… pero ahora está arreglado.

5

y no llevarse el crédito POR la solución, pero quería asegurarse de que la solución real quedara registrada. La solución fue, como mencionó Goose, un análisis crítico de todas las horas, no solo las del sistema de archivos, sino también la zona horaria configurada en tu computadora. Parece que Emby ignora la zona horaria (lo cual es razonable, supongo, ya que Unix NO almacena datos de TZ en las marcas de tiempo de los archivos; como nota, NTFS sí lo hace, así que TAL VEZ funcionaría en un sistema de archivos totalmente NTFS con diferentes zonas horarias… no lo voy a probar, jajaja), pero el punto es que parece que simplemente pregunta: ¿es ahora más de 3 horas…? y la marca de tiempo del archivo cuando el reloj de tu sistema local está 3 horas atrás… bueno, son las 1 p.m. local, pero la marca del archivo mostrará las 4 p.m., y resulta que seleccioné un retraso de 3 horas (principalmente para asegurarme de no pasar por encima del 99% de las películas).