it's been there since at least 2013.
locked media files is nothing new to anyone who browses media filled directories with explorer, maybe the app is using the process through com or similar ? the old fix used to be unregistering shmedia.dll (not sure on the name) google will fix all i'm sure :) -- Jon Swindells [email protected] On Wed, May 28, 2014, at 06:43 PM, Ed Manning wrote: definitely part of XSI, and I'm nearly certain it's new in 2014. On Wed, May 28, 2014 at 3:13 AM, Ales Dlabac <[1][email protected]> wrote: Are you sure it's part of XSI? We are dealing with locked files too(even without using any mov file in scene) but I never noticed that application. On Tue, May 27, 2014 at 3:31 PM, Ed Manning <[2][email protected]> wrote: Hey -- I guess this is the only place to bring up bugs for Soft now?!? Okay, Soft now starts something called MediaFileParserServer.exe whenever any sort of movie file is present in a scene. If you start a render and then abort it, for some reason, even though there's no obvious reason for an executable that deals with input formats to care about output images, you can't delete the stub file that an aborted render often leaves behind; Windows thinks MediaFileParserServer.exe is using that stub file. You can't kill the MediaFileParserServer.exe process without putting Soft in an unstable state, so you have to kill Soft in order to release the lock on the stub file. I don't recall ever seeing this executable in the process viewer -- is it new for 2014? My workaround will be to not use movie files, which will be inconvenient as a lot of image sequence assets from my clients get delivered to me as .mov or .avi. References 1. mailto:[email protected] 2. mailto:[email protected]
