FileBot

Hey Red!

Been a long while since I posted!

Using Docker via Unraid.
Posted about this in the forum support there but they had recommended posting here. Well life got busy and I completely forgot about it and finally getting around to asking about it.

Ran into a strange issue using the [{crc32}] attribute during the matching/fetching process.
When you do the initial fetch it is only adding the brackets [] to the filename. Not the actual crc number inside of the brackets. Sometimes its all of the files in a series..sometimes its random ones.

I did figure out a workaround. Before you go and select rename....you can go to the edit format option. Then without changing anything just click "use format".
It updates the name correctly with the crc32 like its supposed to for all files.

I thought it might be a error in my format (due to upgrades or something)....so i deleted it and just used {n} [{crc32}] and got the same results as described above.

Thanks,
Urlryn

What does the log say?
viewtopic.php?f=5&t=1868

{crc32} can't not work. If there's no [00000000] pattern in the file name, and no nearby *.sfv file, then FileBot will compute the {crc32} from the file content itself. Assuming that FileBot has read-access, it can't not work, but it might take a long time reading the entire file to compute the crc32 checksum.

If it indeed does not work, then it's an IO error preventing FileBot from reading the file content. That doesn't really happen for normal local files, but if network shares are involved, then things can get flaky.

I'm having the same issue. First run through, no CRC32 value is appearing, though it IS being generated (it's taking the time to generate it). Double click one of the items in the "New Names" list to edit format, click to use it, then it goes through the list again, much faster, popping up the values. It's not that it's not working, it's that it's sometimes simply not showing the value unless it's already been generated.

Yes, if {crc32} is not known, then it is calculated, which requires the entire file to be read, which means that it can take a few seconds, perhaps even numerous minutes if the file is located on a remote network share.

If you're using the GUI, then an hourglass icon is displayed while the format expression is being evaluated, but the CLI will not display such a progress indicator.

You can use the verify script to pre-compute CRC32 checksums and write the value to xattr metadata for future reference.

I think you're missing what I'm saying. I'm using the GUI (how else would I be able to double click on the file and then "Use Format" to return to it?). I know it's calculating the values, and I see it taking its time on each file to do so, which is fine because I know it's not going to be instant. It's just that after it's finished calculating the value, it doesn't show it on the filename, without repeating the steps mentioned in the first post. Once it's calculated all the crc32 values, double click a file to "change the format" then click "use format" and then it goes through the "new names" list again, but this time faster and with the crc32 values (since they were already calculated).

The issue is that they aren't showing up on the first pass, when it has to calculate the values, but it does on the second pass, with the values that have already been figured out.

Wolfie wrote: ↑25 Aug 2019, 13:19 The issue is that they aren't showing up on the first pass, when it has to calculate the values, but it does on the second pass, with the values that have already been figured out.

That is very strange indeed. I can't seem to reproduce this issue on any of my machines though.

You said that using a network shared folder could cause issues, which I am (sort of) doing. Had the same setup running using 2012 until a week ago (got hit with ransomware). Before then, don't think I noticed any issues. Also, the command line seems to handle things just fine. It's just in the GUI.

It's almost like it only returns a value if it's already known (been calculated), ie, if it has to calculate it, it's not properly returning the value from the routine that handles it. (It's saving it but not returning it.)

I hope you get what I'm saying, even though it sounds almost like I'm describing the symptoms again, vs an analytical perspective of it.

Oh! I see!

It's got to do with xattr. It's disabled on my share. Looks like the first time around it fails when setting back the last-modified data after writing xattr, but fails on that, so xattr are already written for sub-sequent operations.


EDIT:

Fixed with FileBot r6627.

Since you got it fixed, I'm guessing that means you were able to reproduce it. Glad it wasn't something that would be elusive for several weeks, I hate those kinds of bugs.

Superb work as always dude!