Force re-hashing in GUI

[Wolfie]

I know about the -clear-cache option, but this is more of a case-by-case basis option.

When using the GUI and matching files, if a filename has already been hashed, then it uses that previous value instead of doing a fresh hash of the file. Okay so far. However, if encoding the same (movie/episode) a few different times to see how it will look as a final result on a TV (via Plex, of course), you ultimately end up with a same file name but it will have different hash values. Now, what I'm asking for as a feature is a way to force a re-hash on an individual file or matching basis, so that previous values are retained, with only matching names causing any changes in the cache. So, same functionality is retained overall, with the only change being when needed. Much like visiting a webpage and then pressing CTRL+F5 to do a hard refresh to force a fresh load of content vs relying on the browser's cache.

For the record, overall, I like the cache feature, so definitely not asking for that to be replaced nor removed or anything else, just a way to override is as needed.

[rednoah]

Please defined "re-hashing" more clearly, with examples, and perhaps screenshots.


Otherwise, my best guess is that you're talking about the {crc32} binding? The {crc32} value will be stored as xattr when first computed, and so -clear-cache would have no effect on that.


EDIT:

{crc32} is also stored in memory for a while, just like xattr metadata, just to make sure things keep working even if your file system doesn't support xattr.

The long-term in-memory cache is set to 2 days by default, typically far exceeding the life-time of the filebot process, but you can override it like so:

Code: Select all

filebot -script fn:properties --def net.filebot.MemoryCache.days=PT48H

EDIT 2:

The poor mans solution is to just quit FileBot and start FileBot again. That will clear the in-memory cache. Hence, this also wouldn't be an issue on the command-line since each individual filebot call would but short-lived.

[Wolfie]

Yes, the {crc32} tag. The fact that it's stored in memory for awhile can causes issues in certain circumstances, such as the one I mentioned above. I use it on a file, decide that the resulting file and such can be tinkered with, so I get a new file that is different (obviously), but then it hashes super fast and tells me that the destination file already exists (because it's using the same {crc32} value).

[rednoah]

In this case, I would recommend adding the [12345678] part via a shell script first.

The {crc32} binding will prefer to use existing information (from the file name, from nearby sfv files, etc) and will only compute the CRC32 as a last resort, and since that computation is so expensive we cache the result so we don't have to compute it again during this session. This means that the in-memory cache only comes into play when computing the CRC32 is necessary.


EDIT:

Closing FileBot and starting FileBot again will also work.

[Wolfie]

Closing and re-opening is what I'm trying to avoid since it's a nuisance and I'm a lazy butt. Any chance that it could also compare the file size so that if the file size is different, it will generate a new hash instead of using the old one simply based on the same filename?

[rednoah]

Closing and re-opening is what I'm trying to avoid since it's a nuisance and I'm a lazy butt. Any chance that it could also compare the file size so that if the file size is different, it will generate a new hash instead of using the old one simply based on the same filename?

I'll look into it. Probably a good-enough / fast-enough workaround.


EDIT:

FileBot r7625 will now use the Last-Modified date to automatically invalidate cached values.