# Stopping At Errors

**URL:** https://community.mp3tag.de/t/stopping-at-errors/9375
**Category:** General Discussion
**Created:** [November 19, 2009, 7:30pm UTC](https://community.mp3tag.de/t/stopping-at-errors/9375 "2009-11-19T19:30:00Z")
**Posts on this page:** 6
**Page:** 1

<div class="post-metadata">

### Author: ![juggernaut](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/j/d07c76/32.png) [@juggernaut](https://community.mp3tag.de/u/juggernaut)
#### Post date: [November 19, 2009, 7:30pm UTC](https://community.mp3tag.de/t/stopping-at-errors/9375/1 "2009-11-19T19:30:00Z")

</div>

I came across an annoying problem which is an error (posted below). Now I don't know why the file isn't being read because it seems perfectly fine but that isn't the issue (I don't expect it to be able load every single mp3 file without errors). The issue is the fact that Mp3Tag immediately stops at an error and reports the issue.

Doing this is a great nuisance because it stops any further retagging occurring after the error. So thus makes it impossible to retag a large amount of files without being ready to deal with any errors that occur. Is it not possible to just skip the erroneous files and any syntax errors that occur then just report all the occurring errors after the entire re-tagging has finished? Perhaps also a good feature would then to also highlight all the erroneous files so you could move them someone separately to deal with.

Anyway here is the error that occurred, though it is not really relevant to what I am suggesting:  
[http://img693.imageshack.us/img693/9417/mp3tagerror.png](http://img693.imageshack.us/img693/9417/mp3tagerror.png)

ps like everyone else I absolutely love the program 🙂

---

<div class="post-metadata">

### Author: ![juggernaut](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/j/d07c76/32.png) [@juggernaut](https://community.mp3tag.de/u/juggernaut)
#### Post date: [November 26, 2009, 10:20pm UTC](https://community.mp3tag.de/t/stopping-at-errors/9375/2 "2009-11-26T22:20:39Z")

</div>

No response to this?

---

<div class="post-metadata">

### Author: ![Innuendo](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/i/898d66/32.png) [@Innuendo](https://community.mp3tag.de/u/Innuendo)
#### Post date: [November 27, 2009, 4:17am UTC](https://community.mp3tag.de/t/stopping-at-errors/9375/3 "2009-11-27T04:17:31Z")

</div>

> [@juggernaut](#):
>
> I came across an annoying problem which is an error (posted below). Now I don't know why the file isn't being read because it seems perfectly fine but that isn't the issue (I don't expect it to be able load every single mp3 file without errors). The issue is the fact that Mp3Tag immediately stops at an error and reports the issue.

Looks like a path length error to me.

---

<div class="post-metadata">

### Author: ![ccmix](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/c/e99b99/32.png) [@ccmix](https://community.mp3tag.de/u/ccmix)
#### Post date: [November 29, 2009, 1:42am UTC](https://community.mp3tag.de/t/stopping-at-errors/9375/4 "2009-11-29T01:42:11Z")

</div>

far from an expert but think that was happening to me just today...  
Use your OS and check the exact file name. Check for a space before the extension (ie "space" .mp3) Remove the space if found and then retry the program again.

Took me hours to notice that damn extra space! While MP3TAG seems to show you a "space truncated" view of the file name and not the "exact" file name itself.

maybe? especially when you aren't seeing the forest from the trees... (or vice versa in this case)

ie:  
Vivian Green - Emotional Rollercoaster Junior Vasquez Earth Mix.mp3  
Vivian Green - Emotional Rollercoaster Junior Vasquez Earth Mix .mp3

Seems to work fine after manual editing of the file name outside the program.  
Almost as if during the initial read of the directory MP3tag truncates the filename space padding and adds the extension to its working database. When you go to refer to the file the interface between the OS and the program says ... I can't access that file (cause it physically doesn't exist) or a generic error msg. Then once renamed the tag database matches reality and you can again work with the file without issue.

Hope that helps

---

<div class="post-metadata">

### Author: ![juggernaut](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/j/d07c76/32.png) [@juggernaut](https://community.mp3tag.de/u/juggernaut)
#### Post date: [December 3, 2009, 1:58am UTC](https://community.mp3tag.de/t/stopping-at-errors/9375/5 "2009-12-03T01:58:04Z")

</div>

Oh OK. Has this been reported as a bug though?

---

<div class="post-metadata">

### Author: ![Innuendo](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/i/898d66/32.png) [@Innuendo](https://community.mp3tag.de/u/Innuendo)
#### Post date: [December 3, 2009, 11:04pm UTC](https://community.mp3tag.de/t/stopping-at-errors/9375/6 "2009-12-03T23:04:22Z")

</div>

If you are talking about the space before the extension thing it looks like Snuggs reported it as a bug [here](https://community.mp3tag.de/t/9439/1). You may want to pop into that thread and report that you have encountered the bug as well. That way Florian will know it wasn't a one-off with Snuggs.  
.
