bugs when downloading a torrent with multiple .avi files and a shell command.

I have a shell command to use ffmpeg to convert incoming avi files to mp4 format.

I noticed on my transfer window that the torrent had stopped with an error:
I am also testing the new incomplete file name tag feature. And at the time of the error that stopped this torrent, 3 of the numerous avi files still had the 'incomplete' tag. I did  force check and the torrent was 100% complete, yet these 3 files were not renamed after completion.

All the avi files are still being processed by as many ffmpeg instances. None have finished. The move attempt that stopped the torrent seems premature since the shell command was not finished with that file.

It appears that 1] there was a premature move attempt (before the shell command was finished) and 2] when the torrent was stopped by that error, some files were not renamed when finished.

All the files are still in my Incoming folder, but assume that when the conversion processing is done, they will be moved to my Finished folder.

do you have 'Always auto-select files in new transfers' turned on? Settings-Transfers-Files

No...I don't understand the purpose or function of that new feature yet so do not have it enabled.

For the torrent I had this problem with, there are no small files. All it contains is 13 .avi files in size range of 250-550 MiB

And as an update since I originally posted on this, now that all my ffmpeg shell command instances are done, all 13 files were successfully converted, but the original torrent folder and all 13 avi files in it still remains in my Incoming folder, they were not moved.

And 3 of the completed .avi files still have the !ncomplete tag as well as the matching .mp4 conversions since the shell command was initiated before the files were renamed back to the original $file

I just manually edited the files names and removed the !ncomplete prefix from the file names without issue, but they stayed in the Incoming folder.

Just to clarify, I do believe it's generally supposed to do all the move on complete stuff first before doing shell commands.  There's no real good way for an app to tell if these shell commands are actually complete, because processes or commands can spawn others etc... so that's why they have to make it do all the moves first, then the shell commands after (and if you check the event log, that's pretty much how it goes.)

What's happening in your case, is that you have per-file shell completion commands, and a whole-transfer move on complete.

So first, a few files complete, and then the shell command(s) start on the individual files.  No problem so far.

But when the last file completes, before it's shell command happens, the whole transfer does it's move on complete.  It has no way to know those old shell commands are still running (shell commands are fire and forget, there's no way around that, but that's normally OK with per-file MOC).

So when the whole transfer move on complete is happening, and it tries to move one of the files that your shell command is holding a lock on, it eventually fails (it only retries for locking for about 40 seconds generally).

I'm sure the devs are still tackling these unintended complexities which pop up with new features...