More “file cannot be opened for writing”

I too am having a similar problem when trying to update the cover art on mp3/flac files, getting the error “file cannot be opened for writing”. This was after updating to version 3.0.0.
The files are located on an Audio Server accessed across my home network, which I have don hundreds of times before. I then tried to rewind to my previous version 2.98 (I believe), to find that bad the same problem, although I’m sure I’d done that find beforehand.
After further experimenting, the files could be updated if copied to my local HD, and then copied back, so it’s not file corruption or invalid file problem. I could also update the files Tag information accessing across the network, just not when it comes to updating the cover art.
I subsequently tried an older version 2.57 and that seems to work fine, although I’ve been using newer versions many times since that version!
I tried installing as full installs and as portable installs, with the same results.
This is on a Windows 7 x64 computer, that same as I’ve used for many years doing the same thing! I don’t know what gas changed, the only thing is that I recently changed my router, but I don’t see what difference that would make! The only thing is that the IP address changed (served rom the DLNA).
There hasn’t really been any concrete solution for others with similar problems, although it sounds like those are when updating the Tags data themselves, which works ok for me.
Any ideas how to resolve this problem would be most helpful.

Flac files are usually fairly large and so it could be that while updating them over the slow network connection some other program interferes.
You would have to investigate which program that could be.
Good candidates are virus scanners, indexers, streamers, library updaters.

Nothing is interfering like that, I even tried temporarily turning off the virus scanner.
Same thing happens with smaller mp3s.
All works properly with version 2.57, but not with any newer version!
I’ve been doing it for years without trouble, now all of a sudden it doesn’t work.

As you say that the problem is not there if you treat the files locally, I would investigate the

and the permissions on the

Nothing has changed on the Audio server, permission wise, as I say I can change tag, just fails on cover image. Not sure what difference the router would make?

I still think it is a permission problem.
When you add an image, it is rather likely that the already existing padding is not big enough. So the file has to be rewritten to add the image.
This usually means that a tmp file is created for the new data and once that succeeded, the old file gets deleted and the tmp file is renamed.
So you would have to check if this process (create a new file, delete existing ones) is still allowed.
All this has nothing to do with the new version.

Yes I know how the temp file process works, and it does work fine with the older version, but not with the new!

If this works - where do you see the MP3tag problem?
Apparently, the MP3tag functions are all there - it is your local environment that has to be checked for consistency.
I am afraid I can't do that from the distance.