Can somebody explain how this is possible?
While a file is playing in GOM player, I can..
All without the player choking or the file being in some kind of lock.
That's how I imagine things to work! o)
Probably because the file hasn't actually gone anywhere. You're just altering the directory details (Master File Table) for it. The open handle to the file points to the data content. While you have that handle open, it's entirely feasible that you could do all those things. Try doing a secure wipe of the file content though and your player would no longer be able to play the content. 
Of course I don't believe in super natural things going on on my computer, if the bits are gone, there is nothing to be played back. But if opening and playing back a file like this is possible, then let's have it everywhere! o) This is GOM player v2 (quite old, the newer version is 10 times slower in playback and seeking).
Anyway, I wanted to show what I experienced with GOM player for the last decade and longer, maybe there is something we can learn from that?
I also would be ok with the playback being stopped, once I delete the file, no problem! o) If it keeps playing it could be irritating I guess, but you get used to it and it does not get in the way while you are sorting some files - very nice experience. o)
If GOM player is using an alternative file handle, maybe using MFT directly is the future? o)
As an additional "Next Gen" tool, I like to mention "WizTree", it's a WinDirStat / QDirStat alternative and it collects and analyses the size of over 810.000 items on my computer in about 3 seconds. Using regular WinDirStat always took minutes to complete - wow! o)
If DO could read file and folder information that quick as well.. nobody would complain I guess? o) Anyway, this is offtopic, but same mind blowing and different handling to what we were used to, so.
Let's go where nobody has gone before.. free all the files, no more locks! o)
GOM doesn't use the Windows MediaEngine API, AFAIK. It has the codecs baked into it and does everything itself, which gives it more control over how the files are opened.
(Something we don't want to do as then we'd have a full-time job just maintaining all the codecs, and have to add every new codec that came out to Opus instead of being able to use the system-wide ones automatically.)
Hello !
With the same configuration (dual pane + permanent pane preview), I had the same problem with MP4 videos once I installed MS HEVC codecs for h265 and a bunch of others with the K-Lite codec pack as I tried to display h265 10 bits files in the pane preview without an error message.
The codecs installation didn't resolve my problem
It was solved once the two first plugin choices where uncheck.
Then I had a problem with locked mp4 files. In my case it was impossible to rename a .MP4 file. Delete, move, etc worked overwhere. To rename a MP4, I had to close DO and rename with Win Explorer.
With your solution (uncheck the 3 plugins choice), my problem is solved 
I lost the possibility to play the videos in the preview pane as I now have just a static preview. But I can live with that (I also use Seer to preview videos). Thank you for the tip !
Is it possible to close the file handle of the viewer pane by script?
This works for renaming:
// Reload Viewer Pane
// (c) 2024 Ken
// This is a script for Directory Opus.
// See https://www.gpsoft.com.au/endpoints/redirect.php?page=scripts for development information.
// Called by Directory Opus to initialize the script
function OnInit(initData)
{
initData.name = "Reload Viewer Pane";
initData.version = "1.0 (2024.12.24)";
initData.copyright = "(c) 2024 Ken";
// initData.url = "https://resource.dopus.com/c/buttons-scripts/16";
initData.desc = "Reload the Viewer Pane when renaming (To prevent file locking)";
initData.default_enable = true;
initData.min_version = "13.0";
}
// Called to provide notification that a file operation is complete
function OnFileOperationComplete(fileOperationCompleteData)
{
if (fileOperationCompleteData.action == "rename" && DOpus.listers.lastactive.viewpane == 1) {
var cmd = DOpus.Create.Command;
if (fileOperationCompleteData.query) {
cmd.RunCommand('Show VIEWPANECMD=clear');
return true
} else {
DOpus.Delay(2000);
var focusItem = DOpus.listers.lastactive.activetab.GetFocusItem;
var path = focusItem.path;
var newMap = fileOperationCompleteData.data;
for (var e = new Enumerator(newMap); !e.atEnd(); e.moveNext())
{
var item = path + "\\" + newMap(e.item());
if (focusItem + "" == item) {
cmd.RunCommand('Show FILE="' + item + '" VIEWPANECMD=open'); // Re-preview
return
}
}
var e = new Enumerator(newMap);
var item = focusItem.path + "\\" + newMap(e.item());
cmd.ClearFiles();
cmd.AddFile(item);
cmd.RunCommand('Select FROMSCRIPT SETFOCUS'); // Focus on the renamed file (it will preview again)
}
}
}
Script event currently only support renaming:
Sensible approach, but it does not "scale" into any direction. The preview pane should not lock files by any means. I think there are no real arguments to have files locked while in the preview. It just makes no sense to me, it creates so many issues in the workflow.
I have a button which clears the content of a file to 0 byte. I use this to "mark" files I am already done with and for which I don't want to spend disk space anymore. The viewer pane currently blocks this "0 byte" button / process. It is the same problem as opening a file in an external application, which needs to work on the file content or if you try to delete from "some other place".
Currently, this is a problem for video files especially, but it happens for others as well iirc. I have set the player in the preview pane to "do not start playing", so I only see a black video frame, but it still locks the file. I don't know.. it is not really useful this way. I can disable the video preview plugin of course, but then the whole point of that preview area is in question.
Please don't make the preview pane lock files! SOS, Help! o)
I could live with a lock on the file while the preview is initialising (loading that video thumbnail and meta-data to build up the seek bar e.g.), but once that is done, the file should be free again? Maybe re-init the moment I press play? Would that work?
You can try changing the video decoder. If I switch to the LAV decoder, the file is locked and cannot be renamed.
What application is that?
It is Shark007Codecs, portable.
From my testing, the Microsoft Store codecs allow files to be renamed while open in the viewer. At least for the files themselves, if not the parent directories.
(I haven't checked what happens with LAV Filters, which may open/lock the files in a different way.)
Deletion and moving should generally already be handled internally, by closing the viewer if it's open.
If there are any missed cases where doing something in Opus is blocked due to the viewer, let us know the steps to reproduce them and we might be able to make it handle them better.
Avoiding locking files is already done where possible, but is not always possible due to third-party viewers we have no control over. Copying the file and opening the copy is the only guaranteed way to avoid every viewer locking a file, which is already there as an option where it makes sense (not for videos, as they're too large to copy like that).
That Shark GUI is probably the only thing "portable", right? As far as I know, codecs need to be registered in the system. I assume, removing that Shark folder will not restore the system to default codecs, right? So it's not portable! o)
I don't really understand yet. I assume by "applying" that Shark-thing, which is a pack of codecs, the behaviour in DO can be influenced, because DO uses Microsoft playback API and this codec pack changes things for the Microsoft playback API. Is this correct?
That's fine, I am not referring to 3rd party preview handlers, I know they have "their own" mind. o)
Maybe I don't understand, but how does this help in the case, where an external application is trying to access or modify the file in any way? DO cannot know when to release the lock on the previewed file, if it is to be modified by an external application, or can it?
Yes, Shark007Codecs is not truly portable. If you remove it from the options, the program folder will not be occupied if no other program is using it.
SettAttr also seems to fail for files being "previewed", but not playing (audio file in this case).
When using the Windows "Properties" dialog and enabling "compression" or some other attribute, the "lock" problem also comes up.
It would be nice if we find a solution to this in the future, yes, no, maybe?!
Now that the "Preview Pane Lock" symbol is more reachable, I use that often, but I still need to select a different file beforehand, then lock the pane, then do "the action", then unlock the pane and restore my actual selection, phew! o)
Thank you! o)
What's the command you're running? (SetAttr can do thousands of different things, some of which don't even involve opening the file.)
We can't do anything about that one, since it's not us making the change.
Good morning Leo.. o)
Regarding the SetAttr command, I actually cannot remember, but I think it also does not matter because if you "work around" SetAttr, the locking problem is not solved at all. I will run "ffmpeg.exe" tomorrow and up with a problematic lock anyway, right? I just wanted to "enrich" the problem situation with some more examples.. o)
You or DO is not making the change, that is correct, that's why I think the preview pane should not lock files in general and by any means. There are hundreds of external programs tied into DO, it will never know what an external program will do exactly with a file, so the file needs to "free" - always.
If I use some 3rd party preview handler which is locking the files, it's my fault I use that, but locked files with your own module is really not appropriate. It spoils the whole preview pane, makes it a love and (slowly growing o) hate relationship.
The DO preview is not a generic media player, which probably does not expect me to modify a file while it is playing. The DO preview is different, it should expect me to change the file with first priority, because I am in Directory Opus - a tool to manage and manipulate files and their meta data.
Can the media playback not just init, extract a frame and the duration, show this frame and information (along with the play/pause buttons) and then release the file again? I could live with a second or two until I can modify a video file.
For audio files this should be even quicker. Media files also don't end up being locked, if I use "duration" or some other information in a column, so why would the preview lock them?
I like the playback in the preview and the available settings in v13, this all feels and looks efficient and non-bloated, but the locking problem is.. it drives me nuts. o)
And to be fair, I did not yet explore the suggestions from above to try and install different codec packs, I actually don't want to or feel the need for them (the splitter(s), LAV, codec, filters and stuff, it is kind of "over my head" and I already spent too much time in my life with codec settings, I really did).
I also don't yet see the technical relation between using a different codec and why this would cure the problem. Is the actual "locking" problem not within the DO playback, is it because Microsofts original codec behaves bad and you already did everything possible to prevent the locking?
Thanks in advance for taking the time.. o)
Not possible for things like audio and video, unless you want a ling delay before opening each file while a copy is made.
Mhh, may I ask, what has "copy" to do with showing a file in the preview pane?
How is it not possible to only grab / lock the file after I hit the play button in the preview pane?
The GOM player allows to even delete currently playing files (demonstrated above), so is locking of any kind required at all? That GOM player is freaking awesome in this regard. o)
