Release file handle when opening new file
Open file, open new file, try to delete old file => file is till opened in LoselessCut
I assume this is on windows, right?
Yes, Windows 10
I just tested on Windows 8.1 and it works there.
- drag drop a file from my desktop into losslesscut
- drag drop another file from my desktop (choose open instead)
- right click the first file on my desktop and delete it
- success
Is this the same as you did?
Just reproduced with:
- Open file
- Select segments and export
- File -> Close
- App is still running
- Try to delete old file
It seems it doesn't reproduce every time...
Reproduce it again with a ~3h video with 18 segments reduced to ~1h30m
When delete gives an error, maybe you could check which process is holding the file open Whether it is ffmpeg, ffprobe or LosslessCut itself. https://superuser.com/questions/117902/find-out-which-process-is-locking-a-file-or-folder-in-windows
LosslessCut.exe has the file handle blocking delete.
I tried again now with the newest version and I'm still not able to reproduce this problem on Windows 8.1. I can even trash the file while it is open in LosslessCut. Could it be some stricter settings in your operating system configuration?
Forgot to check what version I'm using. It's 3.13.0.0. I'll try newest version and report back if it's still a problem.
With 3.19.0, the file handle remains open in ffprobe.exe, but it gets released after some time. I guess there is still pending work for ffprobe.
Also managed to reproduce stuck file handle in LoselessCut that doesn't get released. Same as before, it doesn't reproduce every time.
How long do you try to wait before checking the file handle? Does it get released after some time? I know that Windows has a lot of issue with file locking in general compared to MacOS/Linux which doesn't have a concept of locking files.
If it's locked by ffprobe.exe it gets released after some time (not much, ~1min). If it's locked by LoselessCut it doesn't get released and I have to quit the program for the file handle to be released.
Ok. Do you see any other patterns? Like did it ever happen from just opening a file and then closing it? Or do you have to cut first for this to happen? Does it happen with only some file types?
Just reproduced file handle stuck temporary by ffprobe.exe and also permanently by LoselessCut 3.19.0 with:
- Open file
- Browse timeline
- File -> Close
- Cannot delete file
So the editing has nothing to do with file handle getting stuck. Files are .mkv, 2-3 GB size.
I am experiencing the same issue consistently.
Windows 10 Enterprise LosslessCut 3.39.0 (Built locally - not installed from Windows Store)
Clicking the trash icon after editing file of size 433,373 KB displays the following messages in 'Developer Tools' view (I replaced some file path values with a string enclosed with <> for privacy):
react_devtools_backend.js:4049 react_devtools_backend.js:4049 trashResponse {tmpFiles: true, projectFile: true, sourceFile: true}
Command failed: C:\Users<acsii_string>\AppData\Local\Temp\7dd5c8b8-fe4c-41ff-bda7-7f7313e0caad.tmp.exe D:<ascii_string><ascii_string> 2021-10-12 15_04-cap.mp4
at ChildProcess.exithandler (child_process.js:308)
at ChildProcess.emit (events.js:210)
at maybeClose (internal/child_process.js:1021)
at Process.ChildProcess._handle.onexit (internal/child_process.js:283)
A dialog appears with message: "Unable to move file to trash. Do you want to permanently delete it?
User then selects button labeled "Permanently delete" and receives the following exceptions:
Error: ENOENT: no such file or directory, unlink ' D:<ascii_string><ascii_string> 2021-10-12 15_04-cap-proj.llc' overrideMethod @ react_devtools_backend.js:4049 Promise.catch (async) (anonymous) @ main.36c952cf.chunk.js:1 async function (async) (anonymous) @ main.36c952cf.chunk.js:1 Ve @ 2.02f77fbb.chunk.js:2 Ke @ 2.02f77fbb.chunk.js:2 (anonymous) @ 2.02f77fbb.chunk.js:2 Cr @ 2.02f77fbb.chunk.js:2 wr @ 2.02f77fbb.chunk.js:2 (anonymous) @ 2.02f77fbb.chunk.js:2 Le @ 2.02f77fbb.chunk.js:2 (anonymous) @ 2.02f77fbb.chunk.js:2 Ir @ 2.02f77fbb.chunk.js:2 Jt @ 2.02f77fbb.chunk.js:2 Zt @ 2.02f77fbb.chunk.js:2 t.unstable_runWithPriority @ 2.02f77fbb.chunk.js:2 Vi @ 2.02f77fbb.chunk.js:2 Pe @ 2.02f77fbb.chunk.js:2 Qt @ 2.02f77fbb.chunk.js:2
react_devtools_backend.js:4049 Error: EBUSY: resource busy or locked, unlink ' D:<ascii_string><ascii_string> 2021-10-12 15_04-cap.mp4' overrideMethod @ react_devtools_backend.js:4049 (anonymous) @ main.36c952cf.chunk.js:1 async function (async) (anonymous) @ main.36c952cf.chunk.js:1 Ve @ 2.02f77fbb.chunk.js:2 Ke @ 2.02f77fbb.chunk.js:2 (anonymous) @ 2.02f77fbb.chunk.js:2 Cr @ 2.02f77fbb.chunk.js:2 wr @ 2.02f77fbb.chunk.js:2 (anonymous) @ 2.02f77fbb.chunk.js:2 Le @ 2.02f77fbb.chunk.js:2 (anonymous) @ 2.02f77fbb.chunk.js:2 Ir @ 2.02f77fbb.chunk.js:2 Jt @ 2.02f77fbb.chunk.js:2 Zt @ 2.02f77fbb.chunk.js:2 t.unstable_runWithPriority @ 2.02f77fbb.chunk.js:2 Vi @ 2.02f77fbb.chunk.js:2 Pe @ 2.02f77fbb.chunk.js:2 Qt @ 2.02f77fbb.chunk.js:2
I think it may be related to this chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=969049
i suspect that it happens when first opening a natively supported file (which creates a <video> tag. Then if later opening a not natively supported file the <video> tag is automatically removed by React but the video is still open in chromium due to that bug. It may have been fixed in newest chromium/electron, but we are being held back from upgrading electron due to macos issues #714
Update: Seems that chromium bug is fixed already: https://bugs.chromium.org/p/chromium/issues/detail?id=1064749
And I don't think it's what's causing it because <video> is actually never removed from the dom in losslesscut
Same issue with Windows 11, Lossles Cut v3.4.3
"Trash Can" function also does not work for deleting original file
maybe we can have some hack to "restart" the program when the trash can button is hit...
@aCuria do you see which program is locking the file? Is it losslesscut.exe or is it ffprobe.exe ? and if you wait for a few minutes, will it resolve? Also is the file natively supported or converted to supported format?
do you see which program is locking the file?
Error message windows gives is "The action can't be completed because the file is open in LosslessCut"
Is it losslesscut.exe or is it ffprobe.exe ?
ffprobe process does not appear to be running in the task manager
and if you wait for a few minutes, will it resolve?
Not after 5min, and losslesscut cpu usage is at 0% all the way
Also is the file natively supported or converted to supported format?
converted
I did some improvements to the Canvas player (unsupported files player) that will hopefully resolve this in the next version
Would be nice to see whether the newest version has improved this situation
No change in v3.44...
The bug seems to be related to not closing the original file after proxy generation
Is it still LosslessCut.exe holding the file handle, or is it ffmpeg.exe or ffprobe.exe? And does the handle get released after some seconds/minutes?
Yes, LosslessCut is holding the file handle according to windows.
On Fri, Mar 18, 2022 at 1:23 PM Mikael Finstad @.***> wrote:
Is it still LosslessCut.exe holding the file handle, or is it ffmpeg.exe or ffprobe.exe?
— Reply to this email directly, view it on GitHub https://github.com/mifi/lossless-cut/issues/272#issuecomment-1072044800, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIOVH2LSR3KYYZC3L3WGLWDVAQHN5ANCNFSM4LFEOLWQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID: @.***>
Thank you. Then I honestly don’t know what’s causing it but hopefully after upgrading Electron to the latest version it will be solved.
I've been using release 3.44.0 and still run into this issue. The way I find myself running into it either exporting + deleting videos in a large batch, or exporting videos that are large in size. My typical workflow might be:
Large batch:
- Open a batch of 20-40 files
- Go through each one, export a portion of it, then delete it
- At some point, deleting one of them will fail
Large videos:
- Exporting part of a movie (mp4 or mkv) and then deleting
It seems extra likely for deleting to fail if you leave lossless cut open in the background for a while, and then come back to it. This may or may not be true.
What's useful to observe in order for me to fix this:
- Is it LosslessCut.exe, ffprobe.exe or ffmpeg.exe holding the file lock?
- Does the file get released/unlocked after a few minutes?
If 2 is true, it might be possible to workaround this issue by having losslesscut continuously retrying to delete the file in a while-try-catch loop for a few minutes after the delete button is pressed, to remedy these issues on windows.
- The Windows prompt says LosslessCut. I'll look closely next time it happens and update this thread.
- I don't believe so. I've been working my way through 40 files in a batch before, where one of the first gets locked, and even once I've gone through the rest of the batch, the first is still locked. I'll do a test for this the next time it happens though.