Deploying the default Windows Explorer — in this case xplorer2 Ultimate v6.2.0.3:
Open the window pane on a a directory of folders.
Select a number of folders less than 15 (Windows restriction).
Right-click to open the context menu.
Select Mp3tag in the menu with which to open the folders for editing.
Issue: Not all the folders once selected, will open into Mp3tag every time. This behaviour is, however, not consistent. Sometimes only a few files open, sometimes more, sometimes all. Sometimes refreshing inside Mp3tag helps to open all, sometimes not. Better to go back and repeat the action from Step 3 again — more than once if necessary.
And what happens if you use the normal windows explorer?
Where are the folders located? On a local mass storage or a network drive?
Do the folders open, if you open them individually?
How did you get the context menu entry as that is not included in a
In my regular installation, I defined additional file types in the options that should be displayed in MP3tag. However, in the portable installations I tested, I used MP3tag's default settings. This resulted in a difference, as external cover art files, among other things, were not displayed in MP3tag.
And what happens if you use the normal windows explorer?
Did not check, and probably not likely to. If the reliability of Mp3tag portable is suspect, I am inclined to change to the install version. Albeit very reluctantly, since the portable version has served me so well in the past, and I shy away from an uncontainable installation where I have to set up everything afresh.
Where are the folders located? On a local mass storage or a network drive?
Local, SATA3 internal HDD
Do the folders open, if you open them individually?
Since the issue is indiscriminating it remains difficult to define. I'd say mostly, yes. However, with "x" nested folders it seems like it becomes a more dodgy affair.
How did you get the context menu entry as that is not included in a installation?
Wish I knew myself ... it was usually present in the context menu in versions past (especially when still running Windows 7), but then it suddenly disappeared for a few versions — until now when, happily, it is back again. Not sure, but I think it's back since v2.31. (Out of desperation, I may have also tried getting it back by other means — again not sure about all the steps I followed.)
It is here too in the portable installation and I did nothing special to get it. Maybe it is because I have installed the standard-installation parallel?
Yes, the standard installation of Mp3tag installs the menu extension for the current Windows User.
If you install - in addition - one ore more portable Mp3tag versions, they don't install the menu extension.
You can check it easily: Which Mp3tag version will be opened if you use the menu extension?
(I'm pretty sure that it starts the standard installation, not one of the portable installations.)
The issue recurred just now. First, I ditched the portable version in favour of the installed version. This: Mp3tag v3.33-beta.5 • Dec 5 2025 15:46:03 (64-bit).
I tried to open 11 folders that contain ca. 600 files. Of those, only 25 opened within Mp3tag activated from the context menu. At first, I deployed xplorer2 and it opened 25 files from 600 (all nested in one folder/album). Then, I switched to Windows 10 Explorer, and it too, opened the same 25 files.
Are you using the Mp3tag context-menu extension added by the installer, or the same context-menu entry you've used before when you used the portable version?
To be clear, only the shell extension works with arbitrary amounts of files and folders.
Be that as it may, having done another thoroughly clean installation of Mp3tag v3.3 Beta 5, loading multiple folders via the Mp3tag context menu entry, appears to be working equally well now, at least initially, in 3 file managers — including Windows 10 Explorer.
If so, have you tested whether you see a different behaviour in respect to loading more or fewer folders when you switch on or off the function?
I think the cause has been identified: there is no shell extension for a portable installation. Everything else is an unsupported modification.
Thank you for your input, @ohrenkino. I deem it unnecessary to expand on my experiences with the Library option, since the cause of my issue has reached a foregone conclusion.