Recalculate initial folder at startup if it's deleted

General Discussion
1

Hi,

I hope this is a good place to make suggestions. This is not technically a bug, but a suggestion that could make things slightly "better".

Suppose I've edited tags in MP3 files stored under C:\z1\z2\z3\z4.

Then I delete folder z3 with Explorer, with mp3tag still running. Obviously, this means folder z4 gets deleted along with it.

If I hit Ctrl-D to change folders, mp3tag does exactly the best thing it can possibly do under those circumstances: z4 is gone, so it looks for the parent, z3. z3 is also gone, so it also tries its parent, z2, which still exists, so the folder selection dialog box then starts at the z2 folder. That's great and it's exactly what I would want it to do given the situation.

Assume the same scenario again, where you have C:\z1\z2\z3\z4 on disk, and mp3tag is showing the content of z4.

If I shut down mp3tag and delete z3, I'd expect the same behavior: The folder no longer exists, so look at the parent folder hierarchy "from the bottom up" until you find something that exists, and select that. But no, when restarting mp3tag, if the last folder selected no longer exists, it doesn't start searching across the parents of the last folder that was used; rather, at startup, it defaults to wherever mp3tag itself is installed (C:\Program Files (x86)\Mp3tag), which is almost certainly always a "bad" folder to start with.

Obviously, you've worked out the logic to search across the folder hierarchy when a given folder no longer exists (use the "closest" parent). It would be nice if mp3tag could re-use that same logic to determine what folder to display at startup, when the last one it used no longer exists, rather than defaulting to the installation folder.

It's not a huge thing, but given you clearly already have the code to do this (and it works well), it ought to be trivial to invoke the same code at startup to decide what folder to use initially.

Just something I come across every once in a while.

Thanks.

2

I see a problem if files were treated on a removable storage or some other address that cannot be reached at the start.

The safest way would then be to resort to the installation folder as that clearly must exist as MP3tag has just been started from there. And that would reflect the current implementation.

3

That's really a different problem, isn't it? And it applies equally, whether the check is done at startup, or it's the user hitting Ctrl-D when the app is already running. And it should have the same solution in either case. I haven't checked what the app currently does when you disconnect an external drive and hit Ctrl-D (and a folder on that drive is the one that would otherwise have been selected).

Personally, I'd solve this by falling back to the user's Music or (failing that) Documents folder (in that order), which are almost guaranteed to exist all the way back to Windows XP--just like the installation folder, one might argue...but at least, there's a better chance that these are better defaults than any folder under Program Files, whose Access Control List intentionally tends to make both itself and any subfolder read-only. Anything under Program Files is almost guaranteed to be wrong, as this is not where the user should ever be storing his own data.

And if system folders like Music and Documents are also missing? Then the user already has bigger problems, as they're system-managed and in a lot of cases, Windows will try its best to recreate them at the first opportunity.

Still, in the rare case where these folders would both be missing, I'd then revert to the user profile folder. That way you're at least still selecting a folder the user has control over, and not a folder that is intended to only contain system binaries.

I've implemented this in one of my libraries decades ago and re-use it in just about every app I write. I wrote it once, and never had good reason to revisit it ever again. A list of default folder(s) to fall back to (in preferred order), when no parent can be found, can be provided to the function, so (for example) if I have an app where it does not make sense to include the Music folder, well, I just don't include it.

Again, not a big thing, I'm purely thinking about picking "a better default".

My two cents worth anyway. :slight_smile:

4

I agree that having a better default makes sense, but I wanted to share the reasoning behind the current implementation.

If the previous folder no longer exists, I fall back to the application directory because it's guaranteed to exist and is likely to contain relatively few files and subdirectories. This helps avoid unnecessary loading delays, which is especially important if the chosen directory isn't one the user would naturally pick as their default.

The application directory is also the default on new installations. I've considered using the Music directory instead, but again — that might not be the location the user would choose by default. Personally, I'm cautious about tools that automatically load all my music: too often, it's unclear whether the program has already modified any files during the initial import (I really don't enjoy this experience).

As for the behaviour when changing folders: I think this differs significantly from startup. In that case, the goal is to preserve the user's context, and the folder isn’t traversed or loaded in full right away. I could apply the same logic on startup, using the next possible parent folder as you've suggested in your original post. However, if the parent folder is, e.g., the Documents folder, it might be a bad experience.

Hope this makes sense! If you have any ideas for a better default given this background, I'd be happy to hear them!

5

Hi Florian,

You make a good argument, but I think I managed to get myself misunderstood a bit, so I'll give it another shot. I'm glad you welcome feedback. :slight_smile:

Let me start off by saying I totally agree that the app should never pick a folder on its own and automatically start enumerating it, for the very reason you mention - it could be large, and might turn out to be not one the user would ever have selected, wasting time.

Assume the app has to pick a folder on its own, because the "last used folder" was deleted, and the entire parent chain is gone as well, say, because it was on an external drive that no longer exists. When this happens, it doesn't matter whether (a) the app was already running and the user hit Ctrl-D, or (b) it's at startup. The bottom line is, the app now has to pick another folder, because we've exhausted the entire parent hierarchy, and that's a (semi-)arbitrary choice.

I think if we find ourselves in that situation, the app should bring up the File Open dialog box and stay there - let the user decide whether to click Select or Cancel. Until that's done, nothing's being automatically enumerated. So yeah, that means, you start the app and the app has to pick its own folder? Bring up File Open and don't do anything until you get the user's response.

The question becomes, what folder do we initialize the File Open dialog box with?

This is where I feel the Music folder becomes the better choice, for the simple reason that Music might be a good guess, whereas the Install folder would never be. And remember, this is just to select what folder the File Open dialog box should be initialized with - not selecting it and enumerating it without the user confirming he's okay with that.

So the suggestion I'm making is that if, at startup (and only at startup), the app has to pick a folder on its own, then instead of picking a default and enumerating its content, bring up the File Open dialog box (on the default suggested folder) and wait for the user to either approve, or change the folder and click Select (or Cancel).

And if the user clicks Cancel, then we really can't proceed, can we? Warn the user a folder must be selected in order to carry on (with OK/Cancel options). If OK, bring the File Open dialog box back again until he selects something. If Cancel, then exit the app (we told him we can't proceed without having a folder selected).

If you feel like I'm splitting hairs, it's all good. :slight_smile: Admittedly, this really isn't a common occurrence. I just thought I'd try to explain myself more clearly, and this certainly will not make me rage-quit and lead me to look for a "better" app to let me tag MP3s in a more straightforward fashion - the answer to that is pretty simple, there is nothing else that even comes close.

Again, I appreciate the openness.

6

I see, I misunderstood you earlier. I thought you were suggesting that the folder should be picked automatically by traversing up the folder hierarchy. Thanks for clarifying!

I've experimented a bit with showing the open folder dialog on startup in those cases, but unfortunately, it doesn't feel quite right. Without an additional message box explaining what's happening, it simply has a wrong feel to it.

Instead, I'll try to do the follwing: if the directory to open on startup isn't available anymore, Mp3tag will fall back to its temporary folder. This is also the folder used when the option to open with an empty folder is set at Options → Directories → Startup directory.

Then, on File → Change directory or Ctrl+D while the current directory is the temporary one, the open folder dialog will be initialized using the Favorite directory set at Options → Directories. If that's empty or also doesn't exist anymore, Mp3tag will fall back to the Music directory.

This approach, I think, offers several improvements:

  1. Mp3tag avoids starting in a directory where it usually lacks write access (i.e., the application directory).
  2. It standardises behaviour by falling back to the temporary folder when the previous one doesn't exist anymore.
  3. It uses meaniful defaults — Favorite and Music folder — when prompting the user to choose a directory.

Hope that's close enough to what you were suggesting! Let me know what you think.

7

I wasn't even aware of the Options / Directories set of folders. I guess that shows how straightforward the app is - I've never even had a need to try to hunt down features.

If the user can provide his preferences, then sure, you can leave it up to him to decide what to use and when.

Sounds a good compromise.

8

I've just released Mp3tag v3.30a, where I've implemented the new approach described above.