Possible to change behavior when "cannot be opened" occurs?

I have used Mp3tag for years. It is one of my favorite programs, and it is a critical part of my music workflow. Still, one issue has bugged me for a while. I searched the application options and the forum, but I didn't see anything.

Short Version:
When editing tags, is there a way to make Mp3tag display a "Try Again" option when it encounters a file that is in use and cannot be opened for writing?

Long Version
I use foobar as my music library and I use Mp3tag for all of my tagging. I very often load music into my foobar library to start auditioning the files, and then I discover that there are tagging errors, such as incorrect album name, date, etc. that I need to correct. I then load the files in Mp3tag to make corrections, but I often encounter the "cannot be opened" error because a file is still loaded and paused in foobar. The error window has only an "ok" button, which closes the window and deletes all the edits I just made. What I would like to see is a "Try Again" option on the error window, so I can close the file in foobar and have Mp3tag try to update the tags again. This way, I would not need to retype everything.

To make a comparison, imagine you're trying to delete a Word document while it is still open in Word. All you need to do is close the document and hit "try again," and then it deletes the file without the need to hit shift+delete again.

Is this possible? I did not find anything in the options, and it seems inefficient for the program to throw away all my edits simply because a file was left open in foobar. Thank you for your help!

If you scan through the threads that deal with the error message that a file could not opened you will find that there are numerous causes for this result:

  • a file is corrupt and has an invalid structure - a retry would be pointless
  • the access permissions are insufficient - a retry would be pointless
  • the filename conventions are not met and the maximum length is exceeded - a retry would be pointless
And even in the case of another program blocking the file it is necessary to investigate why the file is blocked. It could e.g. well be that a program like the WMP with internet access just tries to add information for this file from the internet. The file structure would change and would not be the same as when MP3tag started editing. Even if the file was unblocked after some time and if you had the retry button it could not be guaranteed that the file is still the same and the writing could fail for that reason.

IMHO the message that a file is blocked should be an alarm signal that something potentially dangerous is going on that needs further investigation.

The cause of the message was never in question on my end. It is 100% confirmed to occur because the file is still loaded in foobar. All I need to do in hit stop or start playing a different song in foobar, so the file in question is no longer in use. After doing so, I am able to edit tags in those files perfectly well.

My question is not about the cause of the error message but about the error window itself. Is there an way to give it a "try again" option rather than just "ok," so I don't need to retype all of tags after I unload the song from foobar?

To be more clear, let's say I have a song loaded and paused in foobar. I edit tags and hit save, but mp3tag can't save the tags because the file is being used by foobar. I load a different song in foobar, and now I am able to edit tags in the original file, but I need to retype every field I changed because mp3tag threw all that information away.

I think I understood what you mean:
You have a workflow that regularly leads to one particular error.
And instead of modifying your workflow you want to change the behaviour of the program.
If, in foobar, you have to move on to the next file anyway (as otherwise all the retries would fail), why don't you do it before you start editing files in MP3tag?

Basically, yes. This is a common thing in software. You can go into the settings and change how the program behaves according to your preferences and/or needs. I don't demand that mp3tag work the way I want, but I might as well ask if it can.

It's obvious from your last post that you aren't happy with my posts, so I'll wrap this thread up.

I never meant to ask the program to change to suit my workflow specifically. It's not even that I have a set-in-stone workflow for everything, but that I commonly encounter this error when making simple corrections to tags. All I asked is if such an option exists in mp3tag, and I think I have very well determined that it doesn't. I have worked with other programs, not necessarily audio related, that allow you to adjust how the program reacts or what options it displays when certain errors are encountered. I believe that there is a certain inefficiency to how mp3tag handles it when this particular error occurs, because it simply skips the files and deletes your edits rather than giving you the option to close the offending program or otherwise correct the problem and then hit "try again."

Thanks for taking the time to read the thread.

When there are suggestions for new or modified features, it is always hard to find out in forum what the original intention of the poster is: is it the search for a solution of a local problem and it is simply the lack of program feature knowhow that leads to the suggestion - you will find an awful lot of threads that suggest already existing features.
Or is it a certain, very special environment that leads to a dead end, and indeed, the only way out would be a completely different solution like a new feature. But this feature would then cater only for one very special case which probably never occurs again or - with better proficiency in the progam - be overcome in a different way.
And then there are, of course and thank God, the requests for real improvements.

So the discussion in the forum sometimes becomes a little heated when the evaluation of the pros and cons tilts very much to "contra" as it is problem that comes from a very individual, single local environment. And for which there are rather simple workarounds.

I agree with you, that the user should have as much control over the actions of the program as possible. And the plain message "I couldn't" is perhaps really a little too concise.

Yet, what I would like to see is a discussion that does not only consider the one case but also looks over the fence. So I found our discussion a little too focussed on the pair of foobar and mp3tag and the particular workflow (with the speciality that the error condition could only too simply be avoided if an anyway mandatory step like selecting the next file would be taken one stage earlier) but we did not get into a discussion about the other cases where a retry would be pointless as the error condition has to be rectified before further editing would be possible.
Which, by the way, also applies to your scenario: If you do not select a different file in foobar, a retry would fail again and again.

I can understand that you are not pleased with the experience that you work gets discarded because you did not a possible file block into account.
But how often you repeat this experience? No very often, I expect.
And then you do not need the retry button any more. And it is also not helpful for the other scenarios where the message could occur. So I do not see a lot sense in implementing a function that is hardly ever needed or useless.
But this is just my opinion. Perhaps the programmer thinks different and modifies the function.
He has now enough reasons to do it or to leave it as it is.

Your post makes sense, but please realize that I was never asking anyone to write new code to suit my needs. If you reread my posts, you'll see I was asking only if such functionality already exists in mp3tag. That's why I don't understand why you immediately got angry at me.

This is not limited to just foobar. It could apply to any case in which one accidentally leaves a file open in another application. It could be foobar, or any other music player, or a digital audio workstation, etc. I'm not asking anyone to add code. I do think it is useful feature that could save people time, though.

Since you mentioned it, I run into this problem quite often. It would not be useless, at least not to me.

Within the given constellation, any change in the "external" file, carried out in the desired way, is not subject to the internal control and tracking system of Mp3tag, so there is probably no backtracking if an error should occur.

DD.20170616.1848.CEST

This topic developed in a direction which I personally don't find very beneficial.

First, thanks "Impulse Response" for taking the time to suggest this new desired behavior. It makes totally sense and did come up before several times (on the forums and via email). It's just annoying when everything has to be typed in again in case of such errors.

When trying to follow the discussion here, I think the initial answer did not answer to the original suggestion but something else (post #2). Then a clarification was made that tried to make clear what was meant initially (post #3). And then the whole topic got a tone which I wish not be the default on these forums. It's quite far-fetched to assume that anyone pays always fully attention. The suggestion to stop the track in advance before saving in Mp3tag assumes this kind of attention and would render the request unnecessary. But since this issue comes up, it shows that the world is not like that :slight_smile:

I'd wish for the tone here to settle down, everyone stop making assumptions about what's necessary and what not and just see what has been suggested. I can't promise to implement it right away, but it's definitely on my radar now — not implying that this all is necessary for me to take notice :wink:

Kind regards
– Florian