Having a problem with Windows's file path length limit

Support
1

Hey! I am having problems with the file path length limit in windows and using naming templates within Organize Library Files, which I have automatically managed.

I use this for my naming template at:

M:/Music/

image
An example of this is as so:

M:/Music/I/Imagine Dragons/[2012] Night Visions/Imagine Dragons - Night Visions - 1 01 - Radioactive.mp3

But this can cause paths to be really quite long. I don't want to shorten it because I have.. a lot of music, and I like to keep it the same, or almost the same.

Some tracks are beyond the 254 character path length limit that MusicBee (and other programs) can handle, but MusicBee will still rename them and disregard the fact that file lengths can only be so long.

If a file is renamed with a path length over that 254 char amount, and you close MusicBee after scanning in some music with that problematic long file, you will get a message on close saying that the database couldn't be saved and you have to use the last known backup (the backup prior to scanning in the long file). There is no protection in MusicBee from making long paths using automatic file sorting/naming.

I think some sort of fix should be made, and I have a few ideas of how to address this:

1.) Simply automatically cutting off the end of a file path when renaming automatically, eg, (imagining if this was beyond 255 chars), or allow some sort of filter or setting to do this manually.

M:/Music/I/Imagine Dragons/[2012] Night Visions/Imagine Dragons - Night Vis

2.) Save to the database of MusicBee in a way that a backup won't have to be completely restored, and warn user of the problematic file and tell them it won't be seen by MusicBee, so that the file could manually be fixed, eg. making the album name shorter. At least some sort of safeguard so that you don't need to rescan all of your work in and you're notified of the file that has a problem. There's no easy way to see what file is causing the issue, especially on a huge library.

3.) Simply allow longer file paths.

As a quick fix, I ask for some help on a few things to potentially help mitigate this issue without changing the original one much.

1.) Is there a way to use the display artist field instead of artist or albumartist? A song with a lot of artists might be the issue, and I don't want to use album artist because it might not necessarily be the song's artist. Or, to just use the first artist and bin the others?

2.) Is there a way to make it less likely for a file name to be too long, eg. limiting the song name to 20 chars, and limiting the artist field to 15?

Whenever I add something really long into my library, I won't know it, and my DB corrupts until it's manually found and fixed, and something like this won't show in the logs because MusicBee straight up thinks the entire DB is corrupted and loads a backup. This has happened a few times now, and I know this is the case because when I fix the long file, it fixes the problem.

Any help?
Thanks!

2

I would say that the musicbee problems are something for their support.

You can use all the scripting functions in MP3tag to create a new filename, e.g.

would be:
$left(%title%,20)
$left(%artist%,15)
which you can use instead of a plain %title% or %artist%
if you want to use the first artist, you can cut the artist field with a matching function - you do not say how you saved several artists. If they are stored in mulit-value fields (one artist field for each artist) then use $meta(artist,0)

3

Thanks!
They are separated fields as entirely.

4

For anyone who may stumble on this thread, I use the following string for auto-organization in my library now:
image
This makes sure characters of the whole path stay below 260 characters, which is the actual hard-coded limit to some parts of MusicBee after some searching, alongside truncating long artist, title, and album fields. The quotes preserve the space after " - ", otherwise the space after "-" ends up removed and becomes " -". $Meta cannot be used with $left inside of it, so it's a choice of one or the other and I believe that path length is the better way to go.

5

i assume that this is musicbee syntax?
As e.g. <album> will not work in MP3tag, just like $group is no MP3tag function.

6

It's musicbee's regex for musicbee's handling of renaming files within templates, and has nothing to do with mp3tag.

7

And that works?
I mean, wouldn't it be much easier to apply that rule when you create the file names in MP3tag (with MP3tag's functions) so that musicbee does not run into an error?
See e.g. here: