For some reason, if I play a video clip (.wmv, .mpg, .avi, etc.) in the film strip viewer mode, I then cannot delete it as normal. The file is LOCKED from deleting. And also, I cannot right click on the file to access an unlocker program, the context menu will not come up. I end up having to open Windows Explorer to right click on the file and unlock it for deletion. Why won't Directory Opus allow me to delete a file that is not in use any longer? And why can't I get a context menu by right clicking?
If it's what I (and others) have seen then it appears to be a bug in either a commonly-used video splitter/codec (not sure which one) or perhaps in DirectShow itself (which most Windows apps use to play videos).
I've seen the same thing happen on machines which don't even have Opus installed. After playing some videos and then trying to delete them the files are "there but not there" until whatever played them is exited or restarted.
As I stated, in order to delete the video file, I end up using Windows Explorer which allows me to open up a context menu (by right-clicking) and using a program like Unlocker to unlock the file for deletion. And when I do this, the Unlocker program lets me know WHICH program is causing the problem; and it always is Directory Opus (specifically DOPUS.EXE). In fact, what is weird, is there are always TWO instances of the .EXE file referenced in Unlocker, as if the program has created 2 instances of itself, one being the FILE VIEWER program. And, when I tell Unlocker to get Dopus.exe to unlock the file, I can immediately delete it with Windows Explorer.
There has to be a bug in the program, for there is NO REASON why I would not be able to get a context menu on a file, which always happens to be a VIDEO FILE! (Any other type of file will give me the context menu.)
So, any clues? Or work arounds? Because if I can't use Directory Opus to perform a simply deletion, and have to use Windows Explorer to do it, it kind of defeats the point of having Directory Opus. I am so glad that I didn't install it as a REPLACEMENT for Windows Explorer, or I'd be up a creek!
Just because Unlocker flags dopus.exe as the process does not mean that Opus itself caused the lock. Video codecs (etc.) run in-process and anything they do wrong is attributed to the process (dopus.exe in this instance).
If you view video files of the same type enough times using Windows Media Player or Windows Media Center the same thing will happen and those programs will be attributed with holding the lock. As I said, I've seen it happen on machines that don't even have Opus installed. (It happens quite regularly on my HTPC which has very little installed beyond Vista itself and some video codecs/splitters.)
The context menu issue is a red herring. Opus won't display a context menu for a file that it cannot open with read access. Explorer will. When the video files are in this "there but not there" state after an attempt to delete them they can no longer be opened for read access. (Try it; nothing will play them.)
Trust me, I noticed the same problem a long time ago and went on a mission trying to find out what in Opus was triggering it, until I realised that it could be triggered by any other DirectShow application as well... It's just that Opus was the only one that I used to play videos where I didn't typically exit the program after playing the video. (Until I started using Media Center on my TV.)
...there is NO solution with Directory Opus; that I must open Windows Explorer to do the job that I bought Directory Opus for. If it is as you say, a problem specifically with a video codex, why can't the programmers of Directory Opus find a solution? All I know is Windows Explorer CAN give me a context menu, and allow Unlocker to unlock it. So in my opinion, there just doesn't seem to be any reason why Directory Opus can't do the same exact thing.
The context menu not appearing is a symptom of the problem, not the problem itself. The problem is that a video playback component leaves the file locked in a way that if you try to delete it the deletion appears to succeed but leaves the filename behind, where the file then cannot be opened by anything. (The filename then vanishes when whichever program invoked DirectShow exits.)
You can more easily solve the problem by restarting Opus (or whichever program played the video and is still running). As soon as the program which played the file exits the file will disappear without any need to force an unlock.
Because it's a problem with the codec, not with DO. DO authors cannot fix someone's else codec.
Why do you use a broken one by the way? It seems the most popular and capable ones dont' have the problem.
I'm not sure that's true. I see this issue all the time on my HTPC and the only stuff I've installed on it is FFDShow (very popular & capable) and the MKV, MP4 and FLV splitters.
I've seen it happen with WMV files as well as AVI ones which makes me wonder if it's OS components causing the problem rather than third-party codecs/splitters, but I guess the OS will ask FFDShow (etc.) if they want to handle the WMV file which provides an opportunity for them to cause a problem even if they don't actually render the file. It's a difficult thing to track down, especially since there's no reliable way to reproduce it. (When you want it to happen to test a theory it never seems to!)
Anyway, it'd probably be easier to make Opus run video codecs in a separate process which gets shutdown when not in use. That won't solve the problem for Media Center etc. but it will mean people stop blaming Opus. It's something I plan to investigate, and something that has worked quite well in the ActiveX plugin already.
It's something I plan to investigate, and something that has worked quite well in the ActiveX plugin already.