Question about the default "Add Cover" behaviour

I am reporting back that, with these three directory configurations, the cover lookup "Ctrl+Alt+A" returned exactly the same directory, say "K:\Music" —



Is K:\Music the current working directory? What’s the directory of the first selected file and is there a cover image?

The first setting with %album%\ means that there has to be a folder below the folder of the current file.
I doubt that this folder exists, so the search mechanism hits as described here

If you want to address a folder higher up in the hierarchy, you have to use the path syntax and navigate up with ...
You can test what a variable returns in the preview of Convert>Tag-Tag (without the need to execute anything). This should show you what %_parent_directory% returns.

By "working directory", do you mean anything other than the "Favorite directory?

What’s the directory of the first selected file and is there a cover image?

Usually, all files in an album are selected—not just the first one. When the album cover box is blank, I right-click it to check if a stored cover image exists in the album's folder. Previously, this action performed as expected: it opened the folder relevant to the selected file(s). When a cover is visible in the cover-box, right-clicking it goes to the correct folder.

Question: Initially — i.e. before leaving it blank — the "Favorite directory" held the complete database. Upon starting Mp3tag, I aborted this directory-loading operation during several app startups (i.e., before the directory fully loaded). Could aborting the load have contributed to the current problem?


What about a short excursion into the documentation that describes the various presets for folders?

And if you need further explanations, then do come back.

The "working directory" is the folder that you selected last explicitly with "File>Change Directory" or "File>Add directory" or you added/opened last with drag&drop. The current working directory is shown in the tag panel element for Directory.

I've fixed an issue with Mp3tag v3.34-beta.1 where adding covers via Add Cover not always opened the configured cover directory if it used a format string.

Use %_folderpath% if you always want to open the directory of the file.

@florian

Thank you for providing this method. So far, %_folderpath% is taking good care of this haunting issue.