Interesting find! And thank you for reporting. Seems 9 files went correct and the 10th one got stuck? Could this be related to access rights? (just wondering)

As for the feature request; Under macOS the last used location will be used by the OS. Is Windows ignoring that?
If so then I could add something like "last used directory" and if the directory doesn't exist keep going down a directory until the path exist, and otherwise have Windows pick whatever it would pick by default. Of course, a "default video path" could be an option as well, with the optional combination to use "last used path".
Something like that?

Note : each new version takes quite a bit of work, so I'd like to combine fixes/features as much as possible. Even fixing a small bug takes quite a bit of work. I'll definitely add this to the "to do" list 👍 

Note: in the current developers build (not yet published) I've added:

- Automatically store last used directory for video imports
- Option to set a default path for video imports (overrides "last used")

Both will try to determine if the path exists, and if not, it will try to find an existing parent directory. Useful for when a temporary directory was removed but we'd like to stay in the vicinity of the original choice (last used or set default path).
Default path will always rule, if checked.

May take a bit before I release this version.
Like I said: it takes quite a bit of work to prepare a release for 4 versions (Windows, macOS, Linux GTK and QT5).

Hi Hans,

    No problem on waiting for the next release as I said these two items are annoyances that's all.  The getting stuck item isn't a permission problem, it renames and moves the file fine.  The app just doesn't update itself after the last move.  Your fixes for the default path sound great thanks!

Greg

I'm wondering why that happens - I'll have to do more testing to see if I can reproduce this.
Most of my testing is done under macOS, so I'll have to do some more testing under Windows.

So I understand this is just a cosmetic annoyance. Correct me if I'm wrong.
What did you mean with "but the top folder is not deleted" (sorry for overlooking that when you first posted the bug).

Can you describe the actions and settings in more detail? Eg. rename, move, etc etc.
(sorry for being a pain - greatly appreciate you trying to help to debug things)

Hi Hans,

    So the directory tree is (TV show name is Goats in Space) 

Goats in Space

     Season 01

         Episodes for Season 01

     Season 02

         Episodes for Season 02

     and so on.

At the end of a rename the directory structure is copied completely correctly, the episodes are deleted , the Season folders are deleted, but the Goats in Space folder (which is what I selected) still remains.  I hope that clears it up - again - purely cosmetic and easy to live with.

Thanks,

Greg

Ah I see, that makes sense and works as intended.
Only the directory that holds an actual episode file is removed if that option is checked, but not any of its parent directories.
If this would be allowed, I'd have RMTV walk down to the root of a drive/share and have it remove each empty directory on it's path - or at least until the directory that was dropped on RMTV.

Best I can come up with is added yet another option: Remove a dropped directory if empty after rename.
For some (you for example) this ay desirable, for others (that drop for example their "downloads" directory on RMTV) not so much.

Let me see if I can implement something like that.
Technically very doable, just have to see how much space I have left in the preferences haha. 😉 

Well, I was a little too optimistic on this one.

I can only delete the directory where the actual episode was originally located in.
Looking at parent directories comes with issues since during a rename RMTV no longer knows if just a file or a directory was dropped on it.
So I'd potentially delete too much.

To illustrate this:

Lets say we have this structure for a file:

/some/directory/path/myfiles/show1/season1

The episode file resides in "season1" and the episode gets moved away after a rename.
Now "season1" is empty and we'd like to remove that one.
So far so good, and this is how it works right now.

If I'd look at the parent "show1" then that one could now be empty as well, but I am not sure if that one should be removed.
Now lets assume we would do this (RMTV does not know if you dropped a single file, or maybe the entire "myfiles" directory, it only knows the full path of the file).

Say "myfiles" is now empty as well, should this be removed? And on and on.
I can see directory structures being removed to a level that most users would not want to.

I'm keeping this in mind though as I do understand your use case. I just do not have a good option right now without causing problems for others.

Hi Hans,

   Totally acceptable answer, I wouldn't waste any more time on the parent directory deletion issue.

Thanks,

Greg

Your suggestions are most welcome Greg - keep 'm coming - I'll always try to find a solution if possible.
I've kept it on my ToDo list, incase I get an idea how to address this. 😉 

I still have to work on the other issue - I hope I will not forget. 😊 

Managed to reproduce the "Renaming File 9 of 10" bug. 👍 
Will try to fix that today as well.

Alrighty - got that fix and found a bug that has been there since the first version. Imagine my surprise nobody noticed it.
The file count went from 0-9 instead of 1-10 ... OMG what a silly noob mistake on my end.

Based on your findings I did revamp the detection of extra files as well (file.eng.srt, file.eng.sdh.srt, etc) as this caused an unexpected issue with files like 1.mp4 and 10.mp4 where RMTV mistakingly could see this as files that are similar named files.

Fix will be in 2.3.3 😊 

FYI: Just uploaded the 2.3.3 release 😎 

Hi Hans,

    2.3.3 loaded and tested.  The file renaming numbering is fixed thanks!  Looks like adding the default directory to process messes up the GUI on Generic Settings:

Thanks!

Greg

Hi Greg,

thanks for reporting ... fixed the issue. It's related to how Windows handles (not so great) screen scaling, and I forgot to check the option that it should not use the default font for these options (only a problem under Windows, not visible and work correct under Linux and macOS).

Anywhooo ... thank you for reporting. Fixed it and will be available with the next release (2.3.4) - which may take a few days. 😉