[F] mp3 files are transformed to tmp files at saving

This problem occurs at my computer for about half a year. I don't remember what version I used then or if I have changed anything at that time. Maybe it was at the same time when i installed foobar2000, but I'm not sure.
I'm using now the latest mp3tag version (v2.46a) on Windows Vista but the problem also occured with the versions before.

The problem occurs only sometimes when I change files and save them. I happens both when a source script is saving and when I save manually. When I save more files at once, the problem occurs typically only with one or two of them.
I have the impression that it occurs more often with larger files (50MB+) but this could be only my feeling.
I also have the impression that there are times when the problem doesn't occur for hours and times when it happens at every tenth file. But this could just be a coincidence.

The problem occurs while the "Writing tag data" message field is shown in mp3tag. When it occurs an error message pops up which says:

File "C:\path\filename.mp3" cannot be opened for writing.
Do you want to continue?
Yes No

When I click yes, saving goes on with the other files. When I click no, the other files remain untouched.
In both cases, the "error-file" is tranformed into a .tmp file like "TMPxxxx.tmp" (x can be a number or a upper case letter).

I guess when the problem occurs, the saving process doesn't finish properly. When I change the ending of this file back to .mp3 manually I get the working mp3 file with the tags changed the way I wanted them.
When I watch the files in a windows folder while they are saved with mp3tag, the file names all change shortly into a tmp file and then back to mp3. My "error file" get proper changed ID-tags and the audio information isn't damaged in any way. The just don't get their name changed back to mp3.

There is also a second less often scenario of this bug where the file isn't transformed but keeps unchanged with old ID-tags. Instead there is an additional .tmp file which turns out (after being changed to mp3 manually) to be the mp3 file with the tags as they should be after saving.

As I said I have no idea why this happens sometimes and sometimes not. I don't think it happens with certain problematic files. When I got the unchanged files as written in the second scenario, I often run the source scripts a second time and it works without error. I also got situations where I had the same error again with the same file of a album for two or three times (creating three identical tmp file). But after another run it suddenly works.
The only assumption I have is that the problem could be caused by foobar2000. Foobar is constantly monitoring my mp3 collection and updates its library within seconds after changings. Maybe this monitoring involves a process which accesses the file in some kind which keeps mp3tag from saving them because they are opened by another program.

This also happens to me, but I've only noticed it happen on m4a files (because most of my files are m4a's).

I never thought it could be foobar2000's file monitoring, but now that you mention it, that could be the problem. I don't remember the last time I saved files with mp3tag when I didn't also have foobar2000 open.

i don't know if this is the same problem but it just got even worse!

I just ran a source script over a album of ogg files. I dragged the hole folder into mp3 tag and it shows twelve ogg files. Now after running the scpript there are only eleven!
But there was no error message this time and there is no tmp file from which i can recover the file. The file is really gone. When I click on the properties of the folder there is no hint of it. It says the folder contains 14 file (11 ogg + 3 jpg) and the foldersize also corresponds to the files visable. The missing file is also not in the recycle bin.
The twelveth file name is still listed in mp3 tag, with empty tag but filename, bitrate, filesize, length, codec [Vorbis (Xiph.Org libVorbis I 2050304)], Frequency and Stereo Mode are still shown!
When I click on it in mp3tag it says file not found.

The same problem has just occured with an .ogg file.
So it seems that it can happen to all files.

I've just tagged & re-tagged about 2000 files / 5 GB of music without foobar running in the background. The problem didn't occur at all. So I'm now pretty sure the problem results from a conflict between mp3tag and foobar.

Any suggestions/help?
As far as I have noticed many users here use foobar. Is there someone who doesn't have this problem or does this happen to all foobar&mp3tag users?
Is there a sollution for this problem?
Does anybody know if this problem is known in the foobar forum (hydrogenaudio)?
Any help please!

For what it's worth, I just saw this same or similar problem happen with v2.53. I removed the album covers in a flac and mp3 file (same song different codecs), and when I tried to add a different cover to both, Mp3tag responded with an error on the flac saying it could not write to the file. When I tried to redo it, mp3tag said it couldn't find the flac file. I finally found the file - it was renamed to a random name.tmp. I renamed the tmp file back to flac, and found that it worked and tags were still intact.

This has happened to me in the past with other mp3tag versions, but too infrequently to bother mentioning until now - maybe 5 or 10 times across several years and thousands of edited files. Some of those times the file was hopelessly corrupted. I have no idea what causes it or how to stop it from happening, but it only happens when I edit a tag field or cover in mp3tag. I was not knowingly accessing the file in any other application at the time, nor even having it visible in any File Explorer window or having it visible in any music player - but I can't vouch for what Win 7 is doing or not doing automatically. I use iTunes and foobar2000 for playback. The only activity foobar2000 does by itself that I know of is to monitor library folders, but I have no idea what that means and if this was a factor. iTunes was not open but foobar2000 was (and playing nothing) when this problem occurred this time.

It would seem that there is some kind of activity going on that is probably interrupting or confusing mp3tag in some fashion, but I can't even guess what that might be. If there is a way to improve how mp3tag locks access to a file so that it can't be interrupted when writing, that might be worth looking at. I know such infrequent problems can be virtually impossible to track down, but I thought I'd note this so that you have more info.

To me it looks like the simultaneous access problem that has been reported a number of times.
The only way around it seems to be ...
... a very disciplined workflow in which only MP3tag accesses the files. Special care has to be taken to avoid any WMP or Explorer access at the same time. So this rules out to have the Explorer showing the files of the currently edited folder as well as opening files with the explorer context menu.
... it seems to happen to big files, esp. flac. So make sure, you act as described above.

I do not know how MP3tag accesses files. But the more I think about it I would think that there must be an OS call to block a file while writing.
Looking at the TMP-phenomenon, though, it looks as though there is no direct writing to the original file but a copy is being made (the tmp file), the old file deleted (which seems to work as you do not find the original file any more) but then the tmp-file looks so interesting to windows that mp3tag cannot rename it to the original name.
So in a way - it should be possible to block both files.

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