cache directory cleanup inhibits file identification #1860

mbunkus opened this Issue Jan 20, 2017 · 0 comments


None yet

1 participant

mbunkus commented Jan 20, 2017

As reported by hello_hello on Doom9:

The MKVToolNix cache folder.....

The way I understand it, creating a cache for MKVToolNixGUI allows it to re-open large files quickly once they've been opened initially, however..... when you're working with large numbers of smaller input files, the cache seems to eventually slow the process down.

I almost always add the initial file or stream to be muxed via the Explorer right click SendTo menu. ie Right Click/SendTo/mkvtoolnix-gui.exe. but as the number of files in the cache folder increases, so too does the amount of time it takes MKVMergeGUI to "get itself ready". If MKVMergeGUI isn't running when I add a file that way, the GUI still opens in a speedy manner, but all the input fields are initially "greyed out", I assume until MKVMerge has finished loading the cache files.

I haven't timed it exactly, but at the moment the cache folder contains 894 files totalling 3.9MB, which doesn't seem excessive (in respect to size), however the time between the GUI opening and the input fields becoming usable would now be close to ten seconds.

I doesn't happen every time the GUI is opened. If I close it and open it again in a short period of time, it opens normally, but if too much time has passed between closing and re-opening, it goes back to taking a long time to become ready. I assume that must due to the cached data still being in RAM, or not, as the case may be.

I deleted the contents of the cache folder a short while ago, and so far that seems to have fixed the slow opening problem, but I've only used MKVToolNix a couple of times since then, so time will tell.

@mbunkus mbunkus added a commit that closed this issue Jan 20, 2017
@mbunkus GUI: don't lock cache dir for whole duration of cleanup operation
With a large number of files cleaning the cache can take quite some
time. During that time file identification won't work as it tries to
acquire a lock that's already held by the cleanup process.

With this change the cleanup process will release the lock after having
processed each file allowing the identification process to obtain the
lock temporarily.

Fixes #1860.
@mbunkus mbunkus closed this in 830c64e Jan 20, 2017
@mbunkus mbunkus added a commit that referenced this issue Jan 20, 2017
@mbunkus GUI: only clean the cache once per version
The process can take a lot of time, therefore only do it if there's a
reasonable chance that files will have to be cleaned up — which is after
a version change.

Another piece of the fix for #1860.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment