Preconditions: drive = network drive (samba)
amount of files in this directory structure: ~17,000 (in total inside the database ~500T)
mp3version: v3.22b / 64bit
fresh installation: no change in the behaviour
After search&replace within an ID3tag mp3tag didn't come back (respond); if I press 'Abbrechen' in the dialog then all buttons keep grey.
The only chance is to kill the mp3tag task
-- no entry in error log
2 screenshots added
Does the same happen when files can be accessed locally?
I would assume that on the NAS some kind of SW runs that blocks the files.
Also, a check for integrity would be nice (I know that nobdy likes to hear this but it is just to rule out all the local influences).
Does it happen to the same files always? Does it happen after a certain amount of files?
Unfortunately, I can not move the amount of files locally, so I can not test. Smaller quantities (eg 1 audiobook) goes without problems.
Locking was an idea I also had but even long wait brings nothing. These files on the server have no known quirks, because they have ALL been initially (when they copied on the server over many years) edited with mp3tag. Now I just want to do a cleanup of tags that I have treated differently over the years. No it happens with alle files when I try to make bulk edits. But I have no glue how many are affected when the error occurs. (e.g 1 story have no problem)
Connections to NAS frequently cause problems.
Your observation that MP3tag works without problem with smaller amounts of files would indicate to me that there is something happening in between MP3tag and the files.
And I would think this is the NAS and its indexing SW.
Still, you could make sure that the files are OK (and tagging then initially with MP3tag does not guarantee that they were OK in the first place), see the linked tools in this thread:
and if all that does not help, I am afraid that only treating smaller amounts of files will be the workaround.
See also here for NAS problems:
No slow respond isn't any issue I have. My NAS have a 4x1GB network access and this computer 1GB whitch is used approx >80% by mp3tag. No slow response even for 1 or multiple directories.
MP3 diags didn't work with networkdrives.
I don't think that blocking is an issue, because when I search and replace something which is definitely not existing (no change inside the files) the the same issue occurs. AND if I press 'abbrechen' then mp3tag keeps on non-respondig. So I assume this is a mp3tag issue and not a NAS or filebased one.
Edit: to make a cross-check I will add a new harddrive to this computer (~1h). I will post the results afterwards.
In order to find the bug, it would be necessary to reproduce it.
So I just loaded 25347 files and replaced every space character in the title with 2 space characters.
It took some time - but no problems.
The files were on an external USB drive.
I then replaced all double-spaces with a single one.
Also no problems.
So, at least over here, MP3tag works ok.
Perhaps you have to add the network location with a drive letter.
You are right, after the 2nd start the sw recognize my LAN drives. New HD is build-in, copy of the structure 'T' done. At the moment I check the copied 17thousand files of this structure with MP3diags.
Edit: Missing Infos in the 1st post:
|Prozessor|Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz 3.19 GHz|
|Installierter RAM|48,0 GB|
|Systemtyp|64-Bit-Betriebssystem, x64-basierter Prozessor|
|Stift- und Toucheingabe|Unterstützung für Stift- und Einzeltoucheingabe|
|Edition|Windows 11 Pro|
|Betriebssystembuild|22621.2428|
|Leistung|Windows Feature Experience Pack 1000.22674.1000.0|
Now it's getting difficult, because I don't know which of the 'findings' are affecting mp3tag in that way that it stop working. (Yes I see the hint in the 'how-to-check-files-for-errors')
As you assumed, there are a lot of 'findings' but I need a hint which of them are relevant. Some are funny eg. the hint missing ID3V2.3.0 because I use V2.4.0 for 100%. Some interesting because I delete always all tags in mp3tag and then generate new ID3V1 and ID3V2.4 (see picture) but the tool say I have some V2.3 AND V2.4. New tagging with MP3tag didn't change this issue ...
At least this will a huge task to clean my files ... I'm a little bit disappointed because I thought mp3tag clean all tags/metadata within the files. That was the main reason for me to use this tool so consequent in the last two decades. This analysis (only part 'T' :-o ) show me I'm very far away from that.
Usually, errors in files are not affecting responsiveness of Mp3tag. Maybe @ohrenkino remembers occurrences of that, but Mp3tag usually skips bad data or reports errors (in case of detecting erroneous structures while writing).
It's possible that the previous tags were written by a buggy program that wrote the tags either in the wrong format or at the wrong location. Mp3tag doesn't scan the files for errors like that, but replaces ID3v2 tags it finds with the one's it writes.
Regarding your initial problem of Mp3tag not responding, I honestly have no good idea. You can reproduce the error and send me a minidump created during the not responding state with Process Explorer - Sysinternals | Microsoft Learn (right click Mp3tag.exe → Create Dump → Create Minidump...) and I try to find something based on the information from that dump.
Thanks and understood, I've send you a mail with the dump to info@ ...
Best to all who try help.
Many thanks for the dump and for taking the time to try all these different options.
I identified a potential problem, where the UI thread was waiting infinitely for a message from the background worker thread that failed to be delivered.
I've added a workaround for this case with Mp3tag v3.22f. Thanks again for reporting!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
