I propose adding an option of making a playlist when Mp3tag is closed. It should be crated automatically in the background. There should also be added a new icon, so that after reopening of Mp3tag the user could easily perform in a convenient way a "load last dumped playlist" task
The reason for this is that I often have a lot of opened windows; especially when I check multiple files in spectrogram [like when evaluating albums for quality]. And by a lot I mean like even dozens- in a mater of fact so many that I have to scroll horizontally through icons on my vertical Taskbar, even though those icons are small [so the Taskbar can house something like 40 of them in a single strip]. And so, to clean my virtual workspace I just quickly click the X in the top right corner- but sometimes I make that one click too many, thus accidentally closing the Mp3tag. And then I have to re-open Mp3tag and [most of the times] once again load the same set of files that I was just working on [but having also prior to that to navigate to those files in a filehandler]
And so if I could just re-open the Mp3tag and click an icon in it, this one-too-many-X-click would not be such a drag that it is now, happening to me time after time
And for comparison: this also happens with FreeCommander. Depending on what exactly I was doing and in what order, I sometimes close my filehandler accidentally. But I had my FreeCommander configured in such a way to show me the last opened folders- and so when I reopen it, in no time do I get back to whatever I was doing, with just a single click. And so this could also be possible with Mp3tag [but with two clicks]
This could be implemented in a very simple way: Mp3tag would create a constantly updated file in witch a list of files displayed in the main window would be kept - and the user could choose in General Tools if that list should be loaded up whenever Mp3tag is opened [excluding of course situation when it is opened with a playlist or folder dropped on its icon]
Does this feature scale by any means? I see rather big problems coming when the number of currently loaded files exceeds the first dozen - and for this dozen, I am sure, you can remember what they were.
Just imagine, you load a six-digit-number of files and then MP3tag starts a process to dump the references of these files to the file system... that would probably take longer than the span that you intended between 2 updates.
OK, I know now comes "then make it an option" - but this time the option is already there: File>Playlist (all files) which can be triggered any time you need it.
Because for this particular solution of yours a cont-argument is this: it requires attention and extra clicks from the idiot-user - while what I am proposing would be performed automatically; and thus serve as a kind of a fail-safe for
I think that is an absolute workflow blocker. Do you know how long it takes to save such a playlist?
How long should it take MP3tag to close?
I remember a thread where even the reactivation of hibernating drives took too long:
It would have been so nice if you had left this old thread as it was: also hibernating. Nobody saw a reason to take up the idea and answer in favour of it.
And now you also got two posters who are not really fond of it. Can't we leave it as it is?
I just did do a test just now - and now I can see how this can be a big problem. However:
A] This is suppose to be an option that is not turned on by default
B] The user could be prompted if the process should continue or should it be terminated
C] Mp3tag should do this constantly in a background
D] Mp3tag could do this constantly in a background
E] There could be an optional icon on the Toolbar to turn this setting on and off
F] There could be a new mandatory icon on the Toolbar that would close Mp3tag and create this dump list
ad A] This is for an advanced user
ad B] Of course a continuation means delaying of the closing of the software - but on the other hand being faced with having to cancel such dump creation would act as a fail-safe for accidental closure of Mp3tag
ad C] That would take care of this issue
ad D] But knowing that Mp3tag does not do anything in the background, I am making an educated guess here that this "could" would probably not be possible without a major rewriting of its code
ad E] Knowing that so far there already were so many pleas for a customizable Toolbar and / or modifications, we can assume that this would also be not possible in a foreseeable future
ad F] This one is a reasonable workaround to the issue of slowed down closing process by this new feature proposed by me
And this quote also sums up most of your other ideas that deal with manual interference, buttons in toolbars that have to be pressed - all this does not really ease the interaction with MP3tag, especially as there is already an easy way implemented.
The idea that
How should this work in practice? If it takes a long time to save a big playlist, it will take even longer, when working in the background.
In fact, either it comes to a standstill as soon some decent work (like sorting, filtering, executing actions) is carried out, or when updates have to be written to the files, I would very much like to have the full hdd bus capacity at hand to update the tags and not share it with wiriting such a playlist.
Then again: should the playlist be written at certain intervals (e.g. 30 seconds) or triggered by certain events?
A timed snapshot could produce a picture as random as it could be - e.g. I load a set of files but filter them ... what should be the contents of the playlist? The loaded files or the filtered ones? If it is the filtered ones and the filter does not get saved as well, then I will wonder next time when I open MP3tag where all the other files have gone and I would have to load them manually anyway.
If it is all the files, then I do not see the last step that I performed ... so I see little use in the playlist.
If the playlist gets written after certain events, then I doubt that writing the playlist in the background will catch up with all the changes.
Let us assume that there is an action that renames files - the complete playlist would have to be re-written every time a filename changes. Or next time, when the playlist gets opened, it will miss a couple of files as they have been renamed but this is not reflected in the playlist.
All these problems can be avoided if you simply use the built in function of saving a playlist. Then you know exactly what to expect next time you load it.
And the good thing: no additional function is required, it is already there.
Admittedly, it does not help to avoid the initial problem
And thus we return to my previous suggestion regarding user error. At what point does said user take responsibility for their own actions, and stop expecting mp3tag (or any other software) to guess at what mistakes they might make?