TEST).
However when I use _FILENAME instead of _DIRECTORY, Mp3tag has no problem moving the audio files to new folders (leaving behind lyrics, covers, log files etc.).
Is _DIRECTORY unsupported on Linux or is this a bug?
TEST1.
I’m testing MP3tag on Linux via Wine and have also found that changing %_DIRECTORY% is the part that doesn't work. Tag changes work, and filename-based changes can work, but actions intended to rename the containing folder via %_DIRECTORY% don't.
The formatting/preview side can look correct, but when I apply the action using %_DIRECTORY%, the existing album folder remains unchanged. On Windows, the same general approach is part of my normal workflow.
The important distinction for me is that I’m not trying to move only the audio files into a newly named folder. I want MP3tag to rename the existing album folder so that artwork, logs, etc. are all kept together. Using %_FILENAME% can move the audio files, but that is not really a replacement for renaming the parent directory.
So from my side this looks like either %_DIRECTORY% is not fully supported in the Linux/Wine setup, there is a bug/limitation specifically around renaming/moving folders rather than files, or Wine’s handling of Linux-mounted paths/drive mappings is getting in the way somehow.
Not a Linux user here so this may not be correct. But doesn't the directory protocol there use forward slashes / to separate the structure levels?
Wine translates the file paths so Windows programs can access the host's file system. Per default, the root partition on Linux: / is mounted as Z:\.
This allows Mp3tag to access /home/malte/Music on the host as Z:\home\malte\Music in Wine without issues.
I can reproduce it and it looks like a missing API in Wine. I’ll see to work around that.
Yes, it was an only partially implemented IFileOperation which I've now worked around in Mp3tag v3.35-beta.2.
I've tested it with 330 songs, it works as expected so far. Thank you!