cache of directory reading


Still using your program, your the best :smiley:

Would it be possible to store the results of a directory read, so the data is not lost between program closing and reopening.
I usually have to close the program when others use my pc and it takes an age to re-read 5,000 plus tags with all the mp3 tag info, which i know has not changed since the last directory read.

ps i am still using 2.23 I hope I am not asking for what is already in a later version. :unsure:





I have this same problem it takes quite a while for the directory to be read when I start mp3tag, I also find that I can only choose one favorite directory, it would be far better if mp3tag had a library like the godfather. It would cut down on the read time by simply having a database file of some type, it would also be good if you can add multiple directories to the "library."


Moderator: Topic Split from here

Disagree on that. I'd prefere to see Mp3tag as a tagging program not just yet another database.


You ever tried using the favorite folder function? Which would you rather do wait while the program re reads all 5000 songs in some 300 directories, or would you rather have the program read one file in one directory that contains what amounts to a chart listing all of the music you have in direcrories you defined? The favorite folder function is pretty crippled if you have to wait about twenty six seconds for just one of your music folders to finish being read by mp3tag [The favorite folder option appears to only let you define one folder.] as opposed to four to five seconds for the library cache [database] to load? I would think that since a mass tagger exists to help organize files that may be somewhat persistent [you leave them on a hard drive in our case.] it would be prudent to shorten the read time for large collections of files by doing this.


I do not see a reason for favorite folder to be the root of all the music collection.
Since Mp3tag is a tagging program it's hardly believable you will need to process the same files again and again.
Besides of long start it leads to overcrowded file view - is that convenient for you to find files you wanted to re-tag within 5000 entries?..

My favorite folder is C:\Downloads\Music :slight_smile: And after I put dowloaded files' tags in order I move those files to appropriate place.

And for you Ctrl-D shortcut might be a better solution than favorite folder. :wink:


Sorry, but adding a real cache/database on disk is still not planned.

Best regards,
~ Florian


Ok second directory has four hundred some odd songs and it takes about 25 seconds or so to load, ctrl+D doesn't actually solve anything, the point is that if you have specific directories that you use for your music why should I have to wait about a minute give or take for Mp3tag to read in the same directory every time? You think adding in the extra step of what is essentially a cd command is going to make the situation faster or slower especially considering how the tree will open? What you are telling me is that doing something like mp3tag \directory\directory\directory\directory\directory\ or cd \directory\ cd \directory\ mp3tag \directory is better than having the program use a single file that lists the location of your files that it will load into memory perhaps entirely at your discresion perhaps on load by default. Keep in mind the command line demonstration I gave although not syntaxtually correct is exactly what you do when you use the file browser to navigate through your directories to any folder on your system, in this case it would be a folder containing music. This tool is meant for batch editing of music file tags so I would only imagine the folders involved here would be somewhat large, so how is waiting a minute for a directory to read a good thing? Also how would using a database for directories whose contents are not nessecarily in flux make mp3tag not a tagging program? The idea is to tag large numbers of files in mass all at once, if I decide to route all of my music to one or two folders why shouldn't I be able to see all of them at once if I so choose without being punished with a one minute or more load time because the program feels the need to re read the entire set of directories again every time?
There is no reason for such a long wait at all, not when I could cache where the files are have mp3tag up in about four seconds and use filters to show the songs I needed to edit at a given time in less time than it would take for me to move to the proper parent directory and then tell mp3tag to launch and read in the given folder via the shell right-click context menu.

Even if I am not going to process all 700 songs again you have yet to tell me how doing ctrl+d and clicking through the folder tree would be faster than a database, in fact I am pretty sure it will almost never be faster. I could always disable recursive folder reading but that is silly when you are dealing with songs that may have some relationship ti each other like being made by the same artist or genre, or album, or sequel to an album etc. Why would I cd twice when I could do it once? Its easier to see certain types of mistakes when you are able to scroll through the whole set at once than it is when you can only see one part of it at a time, I know I have caught alot of errors that way. Besides since this is a batch tagging program should it not be geared towards being able to quickly display as many songs as possible if the user should choose to do so, how is it exactly a mass tagging program if it does not allow the user to view songs he or she already has on his computer in a timely fashion when he or she wants to change thier tags or even actual file names?

Say I wanted to make playlists should I be stuck cding through all of my directories as my query changes or would it be better to use the filters and have the entire collection loaded? Mp3tag already includes very useful features that are not nessecarily related to its primary task of file tag editing like playlist creation and the ability to use the internet to find out information about tracks, not to mention the ability to export html lists of your song collection. The user should definetly be able to view all 50, 60, 70, 700, or 5000 songs without a ridiculous load time period.

As for the supposedly crowded view iof the entire colection this is why I suggested the tree style groupng so the whole thing would not be nessecarily listed all at once and you could click on the root virtual folder, or go straight to a subset and view the files that fall into that category.