[tars]

I've added a change to force releasing it and I could not reproduce the issue any more

For me there's no change. It still keeps the file handles open locking the video file, producing the same error when renaming. When is it supposed to release the file? When closing the search subtitle window? Or some specific follow-up actions? 
By the way why does it need to access the video file just for a manual subtitle search which doesn't need to check the movie hash when the database already has all the information about the file?

[mlaggner]

the subtitle hash is especially calculated for opensubtitles - it is not only the file hash (rather the hash of the filesize, a block from the beginning of the file, a block from the end of the file); this is not stored in the database and must be calculated at runtime

with the actual nightly you should not have the issue any more (at least I did not have it yesterday)

[tars]

I understand it needs to access video file for the movie hash when using "Automatically download subtitles" command.
But I'm asking about "Search & download subtitle" command. Isn't it a search based on IMDb ID? And their API says "If you define imdbid, then moviehash, moviebytesize and query is ignored". Doesn't that mean the hash and moviebytesize aren't required for this command?

As for the bug fix, I'm still seeing the file handles left open with the video file locked even after the subtitle search is done (updated tmm three times including one manual update). Could be only me and I'll see what other users have to say.

[tars]

I don't think your "fix" is working at all. Tons of files keep getting locked without being released (sometimes for hours) after subtitle search.
It seems there's no real workaround of the issue other than just waiting until the mapped buffer gets garbage collected:

https://stackoverflow.com/questions/2972...el-in-java
https://bugs.java.com/bugdatabase/view_b...id=4715154
https://bugs.java.com/bugdatabase/view_b...id=4724038

If that's the case, I think you could try the following:
- If you can, try to rewrite the hash function code from openSubtitles without using FileChannel.map to avoid this issue.
- Or, as I suggested earlier, separate the manual subtitle search command (IMDb ID/query) from automatic search command (hash/bytesize) so that at least using of the manual search command won't suffer from this bug.

[mlaggner]

I've just rewrote that part of code for being used without the FileChannel.map; could you try the latest nightly?

[tars]

Great! it's fixed now. No file handle getting opened with subtitle search and no file getting locked. Thanks!