Je reçois régulièrement ce message. Tout fonctionne si je copie tout sur un disque local, mais lire depuis le serveur de fichiers semble poser problème. J’obtiens environ 100 Mo/s en lecture depuis mon NAS, ce qui n’est pas si mauvais. Fichier journal joint.
Je me demande si quelque chose ne se met pas en veille puis ne se réveille pas. J’ai aussi vu qu’on pouvait augmenter le délai d’arrêt de ffmpeg. Que s’attend-il à voir se produire en 5 minutes ? Ça me paraît être un peu long.
Ce journal indique que vous avez annulé la conversion
ERROR> 2019-08-18T12:00:06 MCEBuddy.AppWrapper.FFmpeg → Job cancelled, killing process
Cependant, ce que vous décrivez n’est pas rare. Pour éviter d’être “bloqué” par un processus défectueux, si MCEBuddy ne détecte pas de réponse d’un processus pendant 300 secondes (par défaut), il le tue et passe au fichier suivant.
Si vous utilisez un disque réseau/NAS et qu’il fonctionne lentement et prend plus de 300 secondes, cela pourrait entraîner ce délai d’attente. Si vous savez que votre réseau ou votre ordinateur est lent, vous pouvez augmenter ce délai ou même le désactiver en le réglant sur 0 dans la page Paramètres système
Je n’ai simplement pas eu le temps de revenir m’en occuper. Peux-tu en dire un peu plus sur le délai d’expiration de 5 minutes pour FFmpeg ? Est-ce pour la fin complète du passage FFmpeg (auquel cas cela semble court) ou attends-tu simplement un message de sortie texte ?
Oui, juste n’importe quoi pour montrer que ça fonctionne toujours et n’est pas bloqué en attente de quelque chose indéfiniment (il y a une détection bien plus avancée là-dedans, mais c’est l’idée générale).
OK. J’ai dû réinstaller complètement Windows 10 pour des raisons sans rapport, et j’ai enfin réessayé. À partir de ce fichier journal, on dirait que tout allait bien, puis il perd la connexion SMB et ne trouve plus le fichier ? Est-ce qu’augmenter le délai d’expiration de 5 minutes va aider ?
D’après vos journaux, cela ne semble pas lié à votre réseau, mais plutôt à votre disque C qui ne répond plus. On dirait que vous avez un disque dur défectueux (soit celui sur lequel MCEBuddy est installé, puisque les exécutables et le dossier temporaire se trouvent tous deux sur le même disque/dossier) :
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… pas impossible compte tenu d’autres comportements que j’ai observés, mais divers utilitaires de test SSD ne détectent rien. Existe-t-il une option pour laisser les fichiers intermédiaires dans le répertoire working0 après un échec ?
La solution finale semblait donc être de désactiver la mise en veille dans mes paramètres d’alimentation Windows. Notez que je n’ai JAMAIS coché le paramètre « Autoriser la mise en veille » dans MCEBuddy.
Pour info : tout cela fonctionne sur un Surface 4, i7-7660U 16 Go, Win 10 Pro 1904 B 18362.418
