Así que parece que recibo este mensaje constantemente. Puedo lograr que las cosas funcionen si copio todo a un disco local, pero parece que leer desde el servidor de archivos causa este problema. Estoy viendo un rendimiento de lectura de ~100 MB/s desde mi NAS, lo cual no es tan malo. Archivo de registro adjunto.
Me pregunto si algo se está quedando dormido y luego no despierta. Además, vi que podía aumentar el tiempo de finalización de ffmpeg. ¿Qué se espera que suceda en 5 minutos? Eso parece bastante tiempo.
Este registro muestra que cancelaste la conversión
ERROR> 2019-08-18T12:00:06 MCEBuddy.AppWrapper.FFmpeg → Trabajo cancelado, matando proceso
Sin embargo, lo que describes no es infrecuente. Para evitar que un proceso defectuoso se “quede colgado”, si MCEBuddy no ve que un proceso responda durante 300 segundos (por defecto), lo mata y pasa al siguiente archivo.
Si estás usando una unidad de red/NAS y va lento y tarda más de 300 segundos, podría provocar este tiempo de espera. Si sabes que tu red o tu ordenador es lento, puedes aumentar este tiempo de espera o incluso desactivarlo poniéndolo a 0 en la página Configuración del sistema
Simplemente no he tenido tiempo de volver y pelearme con esto. ¿Puedes hablar un poco más sobre para qué sirve el tiempo de espera de 5 minutos de FFmpeg? ¿Es para la finalización completa del proceso de FFmpeg (en ese caso parece poco tiempo) o simplemente estás esperando algún tipo de mensaje de salida de texto?
Sí, con cualquier cosa que muestre que todavía está funcionando y no colgado esperando algo indefinidamente (hay una detección mucho más avanzada ahí, pero esa es la idea).
OK. Necesité hacer una reinstalación completa de Windows 10 por razones no relacionadas, y finalmente lo intenté de nuevo. Desde este archivo de registro, parece que todo iba bien, y pierde la conexión SMB y no puede encontrar el archivo. ¿Va a ayudar aumentar el tiempo de espera de 5 minutos?
Desde tus registros no parece tener nada que ver con tu red, es tu unidad C la que no responde. Parece que podrías tener un disco duro defectuoso (ya sea donde está instalado MCEbuddy, ya que los ejecutables y la carpeta temporal están ubicados en la misma unidad/carpeta):
2019-09-19T18:16:11 MCEBuddy.AppWrapper.Handbrake → Launching process C:\Program Files\MCEBuddy2x\handbrake\handbrakecli.exe
2019-09-19T18:16:11 MCEBuddy.AppWrapper.Handbrake → Process arguments -i “C:\Program Files\MCEBuddy2x\working0\Childhood’s End_Syfy_2015_12_16_15_58_00.ts” --loose-anamorphic --verbose=2 -f mp4 -O --start-at duration:0 -e x264 -b 3733 -x me=hex:trellis=1:subq=8:partitions=all:8x8dct:ref=3:rc-lookahead=50:keyint=25:keyint-min=20:bframes=1:weight-b:level-idc=40:b-pyramid=normal:direct-pred=auto:mixed-refs:deblock=-1,-1:nofast-pskip:nodct-decimate:b-adapt=0:threads=auto --crop 0:0:0:0 --disable-qsv-decoding -E faac -R auto -B 256 -D 2.5 -a 1,2,3,4,5 -6 6ch -o “C:\Program Files\MCEBuddy2x\working0\Childhood’s End_Syfy_2015_12_16_15_58_00-converted.mp4”
2019-09-19T18:16:11 MCEBuddy.AppWrapper.Handbrake → UI Session Admin Process : True
2019-09-19T18:16:11 MCEBuddy.AppWrapper.Handbrake → Starting process as a UISession process with Admin privileges. This requires atleast 1 user to be logged into the system (remote desktop or locally)
2019-09-19T18:16:11 MCEBuddy.AppWrapper.Handbrake → Setting process priority to Normal
ERROR → No response from process for 300 seconds, process likely hung - killing it
ERROR → Process hung, killing process
Hmm… no es descabellado dado otro comportamiento que he observado, pero varias utilidades de prueba para SSD no detectan nada. ¿Existe una opción para dejar los archivos intermedios en el directorio working0 después de un fallo?
Así que la solución final aquí pareció ser desactivar el sueño en la configuración de energía de Windows. Nota: NUNCA marqué la opción “Permitir sueño” en MCEBuddy.
FWIW: Todo esto se está ejecutando en un Surface 4, i7-7660U 16GB, Win 10 Pro 1904 B 18362.418
