Waiting for progressbar to fill

Hello all,

I have a suggestion that I think could be usefull to many people.

I use all my music from network share, and speed is not ideal when using programs like mp3tag.

I would suggest adding action queue, so when you do a large action that takes like 5 minutes to complete (e.g. change artist on 1000 songs) you dont have to watch the progress bar fill, you can continue editing stuff, and program does long action in background, showing you only percentage of completion.

You could then also add more actions to queue as you perform them, GUI would show you the result, but actual changing of data would happen in background.

Also reading of data could be done in background, filling list in groups of 100 (or 10) as they are read, so you can start clicking right away, without waiting for all thousands of songs to be read first.

Thank you for taking your time to read and consider this :slight_smile:

I do not think that background activities would really be useful. On the contrary: if you apply a filter and have actions being executed in the background you can never be sure that files you see actually match the filter or when the list will show the final result - consequently, you will wait for the actions to complete (which is just the behaviour you see today).
Also, you would have to implement some kind of locking mechanism to prevent simultaneous edits from different actions. THis would then result in incomplete execution of actions as files are locked. The forum is full of complaints about editing failures induced by Explorer - the mp3tag internal locking would make problems worse.

What I would suggest: instead of copying data over the network for each edit (which is the case if you edit the files on the network source) you should copy the files to a local folder on the local drive and do all the editing there. This would enhance the performance dramatically.

Just to be not all to negative: there are suggestions to make mp3tag command-line capable and call actions and action groups via command line parameters - this would then emulate some kind of batch-processing. This is feature is not yet available (and I have no clue whether it ever will be).