[X] Crashing on Folder Selection

I've been using MP3-Tag for a while now, and using it in a very basic manner. I've only been using it as a quick way to tag everything, and it works awesome.

One problem I've noticed, is that some album folders have been causing it to crash. It's always the same folders, so I have just skipped them for a while hoping that an update would come along and fix it, but I'd like to know if this happens to anybody else, and/or any possible resolutions.

None of the tags come up, the instant the folder is selected the program freezes, and if I switch windows and back it's a pure white screen. If any other information is needed I'll be more than happy to answer, although I don't know what else I can really say about it.

Thanks!

See
/t/13082/1

I run fairly regular checks on my hardware and software. I have yet to run into a problem with any of my drives thus far.

About 25% free on it right now.

Not dying. Quite good.

C:, G:, M: are local only. F: is a network drive. However all the folders are on the G:.

What is different about these folders so that you can identify them as causing trouble?

I guess you are loading the whole folder into Mp3tag?

Try loading the single files into Mp3tag, one after the other. Maybe you can single out a file which causes the trouble. Or, if all files can be loaded, maybe in the folders are some hidden files which cause trouble.
Also try moving the files into a different folder, and load that folder into Mp3tag.

Never I saw such a behaviour of Mp3tag, as you have described.
To find out the one and only cause or maybe multiple causes is like fishing in troubled waters.
You got already some tips in this thread to find out what's going on with these miraculous folders.
I will put two more tips into the pool.

Check out the entire length of the longest filepath name of all the files in the bad folder, starting from drive letter down the folder tree to the longest filename including extension.
The longest filepath name string should not be longer than 255 259 characters.

Check out whether the filepath names contain any special character which is not a member of the allowed characters to be used in the file system. It is very unusual, but check anyway.
Read there something about the Windows file system ...
http://en.wikipedia.org/wiki/NTFS

Good luck on your odyssey!

DD.20120212.1036.CET, DD.20150125.1710.CET

Other than the naming there is absolutely no difference in the Folders.

Same result. Regardless of which folder I move them into, and/or which file I seperately (and manually) load it still freezes. Even tried dragging them into a newly created folder in the program and it crashes once I drop it in (if I'm currently viewing the contents of that folder).

Nothing even close to 255. The folder is fairly close to the Root, not much nesting at all.
G:\G\ (artist name) \ (album title) \ (file name)
G:\temp\ (artist name) \ (album title) \ (file name)

For now I've just been putting them into an "untaggable" folder. Perhaps I'll just try getting a different copy of these. Is there a console/debugger/error report generator that I could use and look over? Something to give me an idea of what the actual cause of the crash is.

The depth of nested folders is not decisive.
One can reach the 255 258 char size Mp3tag/NTFS limit alone with one filename in the root folder,
but 259 char size limit on a subfolder\filename path.

What filesystem is installed under the disk letter G: (FAT32, NTFS, or ...)?
How is the disk G: accessed (local, via network, usb, special driver hardware)?

You wrote about the fact, that you are able to copy and move the miraculous files from the problem folder to another new folder and the miracle migrates with.

Check out whether foobar2000 and it's file repair utilities can help.

Hmm, and check whether the folder and file access rights are set right and who is the owner of the files?

DD.20120213.1303.CET, DD.20150125.1707.CET

The drive is formatted to NTFS, and is accessed locally under an administrative login. The filenames are not long, not even close to the 255 limit, even with the folder names.

I'll check out foobar2000. See if it can solve the enigmatic file problem.

Thanks for all the help thus far :slight_smile:

[edit] The repair utilities did not help. I'll just have to continue separating the crashing folders for now, and replace them at some point later. Thankfully it is just a very small percentage of my library that does this.

Maybe someone can reproduce the crashes if you provide a problem file.
Sometimes that helps to resolve file-related issues.

Here's a link to one of the files. I tried redownloading it and opening it in Mp3-Tag to be sure, and same results.

That file opens without a problem with my system. Sorry, but that doesn't help much. :frowning:

The only odd thing I've found is an ID3v2.4 tag field called MusicCDIdentifier (with a binary value) which is not shown by Mp3tag in the Extended Tags view.

I see it by using "Exiftool" which is a command line application that can read many different tags from a variety of file types.

I'm no expert, but it seems unlikely such a tag field would cause any problems, especially since the file opens without crashing Mp3tag on my machine.

But just in case, here's a link to your file with all tags removed.

Yuppers. I could open the folder with that one fine. Time to dissect these files it seems. Thanks =)

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