File "blah.mp3" cannot be opened for writing... reoccuring issue!

I am in the midst of using mp3tag 2.40 to re-organize my entire mp3 collection so that it is viewable by Zune social thanks to the new Zune market place source files. However, it is becoming quite a frustrating show stopper that mp3tag seems to choke on writing tag information for any large file/long song, the most recent being the last track from Genesis' 1972 album "Foxtrot." I've also had it choke on several Pink Floyd songs, specifically from the "Animals" and "Wish You Were Here" albums. There are many more occurances of this bug, too many to list.

The evil, non-free app, Tag&Rename, has no issues writing to these files, yet it lacks the Zune source support.

Please Help! :w00t:

Are you editing those files on removable device or on the hard disk of your computer?

I just played with retagging a 23 minute song from Pink Floyd (Echoes) and a 30minute song from the grateful dead and MP3TAG 2.40 worked fine on my end.

Yes, this also works flawlessly on my end.

I have tried it both ways. My mp3 collection is located on a remote fileserver (on the same LAN), physically in my basement. I usually run mp3tag from my laptop to manipulate those files, but I have also tried running mp3tag on the server itself and receive the same warning.

Is it some sort of timeout issue?

EDIT: Ok, the file I could not modify by running mp3tag locally yesterday, I was able to change remotely this morning. I am wondering if perhaps I have some other process that was holding it open and causing the problem. I will continue experimenting and if anything just to educate fellow mp3tag'rs.. :slight_smile:

Hi All,

I have encountered the same problem, while trying to tag a lot of files at once.

My files also reside on a NAS system on a LAN.

I´ve got the same error message on a lot o files like "File cannot be opened for writing, Continue or abort".

At a first glance to those files, that could not be tagged and which produces the error message, I also figured out, that those files are all about 6 to 10 minutes long. No problems with shorter files.

I then tried not to mark all files, which has to be tagged at once, but mark about 3000 files.

In this case, all files could be tagged correctly, with no error message coming up.

At least, it is a way, which works for me, if I split the tagging process into smaller parts, instead of trying to tag all files at once.

Regards
Tootsi

I suspected this was the problem as well, but even if I try to tag just one file, this time a 13 minute song, I get the error, both locally and from the server itself. This time it is a 13:43 song from Bill Wither's 'Live at Carnegie Hall' album.

It should also be noted that there are no problems EVER in renaming the files themselves, but just in manipulating the tag information.

I've continued trying to re-tag my collection, and I keep discovering that the 'choke' threshold for these files is when the song is over 10minutes long. The one thing I have not thought to verify is if it doesn't have a problem with a 128kbit mp3 compared to say a 192 or higher. It definitely doesn't like to manipulate tags when the file is 192 or higher.

Locally vs. remote execution seems inconsistent as well. I don't think that is the issue.

Do you run any on-access virus scanners or something similar?

definitely not.... they're the devil! :slight_smile:

That's why I was asking :slight_smile:

Is there any resolution to this?
I'm embedding album art into my MP3s and most have them have worked apart from ones over approximately 11 minutes long.

This seems to have been fixed for me with v2.41. Nice :slight_smile:

Glad to read this! Thanks for talking back :slight_smile:

I get the same Cannot be opened for writing message regardless of length on all files on my external HD (USB). Tags for files on my internal and networked drives can be changed just fine. OS: Vista Home Premium.

Please also see this thread and tell me if it helps.

well this problem seems to still be around :frowning:
I am editing a large number of files (using MP3 Tag 2.62 and Windows 7 Ultimate) - and many of them say file cannot be opened for writing

all the songs are on an internal hard drive - and the ones I've tested play just fine in iTunes

what's the latest on this problem? yes, I am running Trend Micro anti-virus - is that the likely problem?

AFAIK it is not the virus checker but Explorer. So perhaps the advice to D&D the folders into MP3tag was only part of the solution: it looks as though Explorer jumps at files that are being modified to see what the changes were. And so blocks them.
If you close Explorer or (which is the preferred way) open folders with the functions from within MP3tag (open folder and/or add folder) you should encounter the blocked file syndronm.

thanks, looks like I have an even more serious problem.

after doing multiple re-tagging (copying fields and replacing text in bulk), I returned to iTunes to see if the fields had been tagged correctly.
What I've found looks quite damaging

  1. many songs have lost text at the end of them...several characters and even whole words have dropped off
  2. even worse, my most important smart playlist has lost 700 songs. Because this is a smart playlist, it either means I have lost the songs entirely or the criteria which put them into the smart playlist is no longer valid, i.e. a value has changed

at the very least I will lose 2-3 days work. At worst I'll have to re-download my back-up in the clouds, which will take some weeks

anybody else ever heard of problems like this? Maybe I should've paid for the 64-bit software someone mentioned, which manages tagging and might have avoided these problems...

PS - MY WORST FEARS! I've just checked and found files that are totally corrupted, several fields missing data completely. It seems MP3tag was unable to handle the files properly. I thought I;d done the right thing by processing half the files at once but it seems not. People should be warned about this - it is extremely damaging.

Please note that the V1 tags have only a limited number of fields. In comparison to V2 you typically loose albumartist, composer, albumart etc.

Also there are restrictions in respect to length. The maximum length for a title is 32. Could it be that this is the length you find?

Before you issue wild accusations, please check what kind of tag versions you write.