Todo iba bien con MCEBuddy y comskip eliminando comerciales de programas de media hora. Luego añadí un programa de una hora y empecé a tener fallos con ese nuevo programa. MCEBuddy reportaba “comskip falló” y cancelaba la conversión.
Si arrastraba manualmente el archivo .ts a comskip.exe funcionaba perfectamente y completaba sin errores.
Resulta que MCEBuddy estaba matando el proceso de comskip después de que tardara demasiado en completarse. Lo observé manualmente y el proceso de detección de comerciales PARECÍA congelarse con 10 segundos restantes. Durante ese tiempo el registro de comskip crecía y crecía. MCEBuddy eventualmente mataba el proceso — asumo que hay un tiempo de espera fijo — y reportaba fallo.
Resulta que el registro en este programa en particular se volvió ENORME. La configuración predeterminada de comskip para “verbose” es 5, y estaba escribiendo una TONELADA de datos de registro al archivo de log. Aunque la carpeta de trabajo estaba en un SSD con un procesador XEON rápido, una vez que el archivo de registro se volvió muy grande tomó mucho tiempo escribir cada nueva línea. Creo que la rutina de registro de comskip necesita ser optimizada.
De todos modos, cambié verbose a 0 y funcionó perfectamente y muy rápido. MCEBuddy dejó de matarlo y completó la conversión.
Creo que MCEBuddy debería extender el tiempo de espera del proceso de comskip o hacer de esto una opción de configuración. Pero editar la configuración de comskip para establecer verbose=0 funcionó, aunque signifique no tener un registro de detalles de comskip.
