Multiple messages that say the program cannot write to m4a files requires response. I have been clicking on ignore. Can you create a setting to allow users to select IGNORE ALL? I have thousands of files I am trying to tag correctly and will have to sit for hours to respond to every message.
Wouldn't this message indicate a serious problem with the files?
Shouldn't the root cause be investigated first?
Ignoring all cases would mean that you would not get an impression if you have a lot of files with problems or only very few cases.
See also here:
Please consider the option to ignore all messages. As explained by others for many years, there are many cases where this applies and this doesn't mean that the file is corrupt. In my actual case I am reworking my collection after rearranging songs in new folders and file-naming from tags. All of the songs are different versions, but many have identical tags. Filenames coexist in the same folder as they are, but when renaming from tags, duplicate filenames will trigger this error message, which I will ALWAYS ignore. They are hundreds of thousands in multiple directories, and having to press the IGNORE button thousands of times will simply break the batch operation and the tool purpose. All my files are in perfect condition. This option would be VERY helpful in many cases! Thank you.
Please note that this thread is about the issue that tags cannot be written to files.
It has nothing to do with renaming files.
If you have problems with the new filenames, then I would reconsider your applied naming scheme.
E.g. you could use
%artist% - %title% _ $num(%_counter%,3)
which would add a number to the end of a filename - and therefore create a unique filename.
It is a good suggestion, however doesn't work for me, I am precisely getting rid of those numbers and keep my filenames as clean a possible
This will only work if you have no duplicate filenames which the underlying OS will not allow.
If you want to get rid of the number again, then try
Convert>Filename-Filename
Pattern over old name: %1 _ %2
Pattern for new filename: %1
This will remove the number for all unique filenames but keep them for the ones that would lead to duplicates which the OS would consider as invalid names and issue a corresponding error message that is forwarded by MP3tag..
That is a great tip and will be used for specific folders in other collection, however on the collection I am working right now, at startup all filenames are ok. In order to get rid of many capitals on title and additional info, is that I am renaming the filename and after that attempt is where some show the error message. Anyway, just a use case for the 'Ignore All' feature. Many more will have their specific case and most won't need it. Hope one day it is implemented as right now the batch can't progress if I leave my PC for a sec. Thanks!
But sometimes dangerous as well because a user might disable the messages and then forget to restore them when they are really needed. That makes me leery of such an option, especially when a safe and easy workaround already exists in Mp3tag.
I disagree. A change to your workflow can safely eliminate these conflicts in Mp3tag as it is now. That is possible because a Tag to Filename conversion does not have to overwrite the source files. Instead, you can automatically save your edited files into another folder. You do this by adding that destination as a permanent prefix to your Tag to Filename conversion string, something like this:
C:\MUSIC\TEMP\%artist% - %title%
After conversion you can clear the original files from the source folder. Then you can safely move the edited and renamed files into the source folder. Done! No more button clicks for "thousands of times", just one clear and one move operation per source folder. And zero error messages about overwrites!
The overwrite problem reminds me of an old joke. A man goes to the doctor and says "Doctor, it hurts whenever I raise my arm". And the doctor replies "Stop raising your arm!"
3 Likes
Ok, let's go back and forget completely about renaming the filename. I am talking about >15TB (more than 2 million) DJ tracks that many are the same song with a subtle difference. Before trying to do the actual filename change, I was getting the same weirdy error message of '...conflicting filenames', although, I repeat, filenames were NOT touched by this action. Many other tags were modified but not the filename in anyways. I guess this message is caused by the program's logic of temporarily handling every file over the network and most users will never face this. No matter if the batch is of 20 files, they live inside a folder with 50,000 songs, so there is a significant msec overhead happening on the other side of the network. causing that at some point of the re-write of a certain file, the program randomly 'sees' a conflicting filename situation, that I guess is only a remanent of a delay while reading and writing, so at the end this is a truly 'ghost' message and nothing happens by selecting ignore. In this particular and real situation, I don't see any other workaround but having the option of automatically ignoring the error and continuing the interrupted operation. I have literally weeks doing this on something that would take no more than a couple of days (!!!!).
Wouldn't this indicate an error on the network rather than in MP3tag as MP3tag simply asks the OS to get the file and write the file and the OS then reports that the file still/already exists?
Does this also happen if you have the files on a local drive?
1 Like
No network error. This is how electronics work. Can be solved on the programming side but not worth to do. It is much simpler to activate an 'ignore all' option 
...reason for raising my arm
This is not what you stated previously.
Regardless, these renaming collisions should not be happening, even on a remote NAS drive. But as has already been discussed here and in other similar threads, the request to add the “Ignore All” button is an unsafe option and has intentionally not been added. The solutions shared with changing the workflow are the best practice approach.
One single user that inadvertently destroys an entire library would be one too many for this.
2 Likes
Disk drives are orders of magnitude slower than the electronics that control them, so delays in the electronics are unlikely to be the weak link here. However, it is possible that your Windows PC is inadequate for your tasks. You may find that upgrading to a very fast "high-end" 64-bit PC with lots of memory and a high speed solid state drive will solve your problems. If you have access to such a PC, I suggest doing some testing.
Thanks Doug for your suggestion. No needed upgrade on that part.