[F] 2.35j Not Responding after Ctrl-D

This has happened twice so far.

I have been cleaning up and merging some year specific directories.


1)Change Directory to e.g. "More 1969"
2)Clean up tags in this directory
3)Add Directory e.g. "1969"
4)Sort by Title
5)Ctrl Select duplicates in "More 1969"
6)Ctrl Delete all duplicates
7)Ctrl-D to "More 1969"

MP3Tag goes into permanent wait (hour-glass) at this point without consuming CPU.
Have to Close Process (Shows as Stopped Responding)

No problem repeating step 7 after re-starting MP3Tag.

The bug seems to be new to 2.35J.

I left MP3Tag running over-night the second time. Wait never cleared.

I can confirm this. In fact, I didn't even had to change a thing. I started MP3Tag, switched to a directory, then pressed CTRL+D and told it to load another folder and then the progress window popped up without showing any information.

BTW, I had to kill the process.

Edit: This is weird - sometimes CTRL+D works, sometimes it doesn't. When it's not working, it either hangs MP3Tag so that Windows is reporting that the program is not responding or MP3Tag displays the empty progress window.

Aaargh. This is getting nasty.

I seem to have two options at this point.

1)Regress to 2.35g

2)Find a start up command line option to prevent loading the last directory at start up or force a new start up directory.


You have three options where the third one is to wait 2 or 3 hours till I release a fixed version :slight_smile:

Thanks for your patience and for reporting!

This should be fixed with the current Development Build :slight_smile:

Best regards,
~ Florian

Fix works. I had managed to make "infrequent" deadlock 100% by cancelling initial directory load. (It was inappropriately set to the root of a library and was trying to load 14000 entries. My bad that it got that way.).

Back to my other questions however.

  1. In general, can I re-install a previous functioning release assuming I still have the setup exe for that release?

  2. Are there any startup command options available for MP3Tag?

Normally yes, but there are changes to internal configuration data from time to time which may not be playing well with previous releases.

Yes, but they are not documented (and may change). For now there are

  • /fn:path-to-file
  • /fp:path-to-folder
  • /m3u:path-to-playlist

Thanks for the info.

Tested /fp option. Worked a treat.

PS: Sorry for my "patience" earlier. I did not expect the quick fix to the problem and was looking for other options until you had time to fix the problem. The additional info may still be usefull in the future as I do, and plan to continue to, update fairly frequently

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.