Support for an overall command to cancel "Repair all open playlists"

[touwys]

With reference to the process initiated by the command Menu > Repair > Repair all open playlists:

Once activated, all the open playlists get repaired in sequence, and the only way to stop the whole process, is to cancel the repair of each playlist — individually. With only one or two playlists under repair, this does not hinder, but with numerous playlists under repair, it becomes a slog to wait to click through each playlist under repair in order to cancel the ongoing process. A command with which to cancel the overall process, would be a welcome, productive addition.

•••

[Borewit]

@touwys , can you confirm this #199 resolved this issue? Can be reviewed using a build of any recent PR.

[touwys]

@Borewit

Build number (ref. displayed, ignored): listFix()-2.8.0.13
(Installed after having installed release v2.8.1)

1. Review applies to: Main menu > "Repair"> "Repair all open playlists" (Crtl+Alt+Shift+R)

Issue #199 is now resolved in as much as if the repair process gets cancelled anywhere along the line, processing stops. No issues observed.

Observations & comments:

1. It may be worthwhile to review, sometime in future, the overall procedure as it applies to the repair of multiple playlists, all-in-one operation.

2. The repair process under review, does not start the repairs at the selected playlist, if, all of which, are already present in the playlist editor for the repair. The repair commences with the first playlist, chosen alphanumerically, as listed in the folder. Also, if the repair process is to be resumed after having been cancelled, the process again commences where it did at first, at playlist 1 in the folder, i.e. not where it stopped.

3. Is it not preferable to have the cancellation, once activated, followed by a confirmation dialogue immediately, with which the user can affirm, or negate, the cancellation, instead of having it end abruptly?

4. As for para. 3, support for a confirmation dialogue at the time when all the playlists, which are present in the editor, are all getting closed together — ref: "Ctrl+Shift+W"). Possibly provide a warning that all playlists are on the verge of being closed?

5. Should the playlist changes that have already been made, be saved before the process is getting cancelled. By default, these ar all automatically discarded. It is probably best to remain like that, as there appears to be no benefit, otherwise.

6. At the "Playlists Directories" pane: Open the context menu of an open a folder that contain multiple playlists. Select, and then run "Repair Playlist". For consistency of operations, should not all the playlists visible the folder also be opened in the Playlists Editor first, before the repair process commence on all of them? Because, there are no visible cues of the actual repairs taking place, except this one:

•

•

[Borewit]

The repair process under review, does not start the repairs at the selected playlist, if, all of which, are already present in the playlist editor for the repair. The repair commences with the first playlist, chosen alphanumerically, as listed in the folder. Also, if the repair process is to be resumed after having been cancelled, the process again commences where it did at first, at playlist 1 in the folder, i.e. not where it stopped.

It processes the playlist in sequence of the tabs, not some file sequence. Which playlist is currently selected has no influence on the sequence.

[Borewit]

Is it not preferable to have the cancellation, once activated, followed by a confirmation dialogue immediately

No, overkill, cancelling this process has no serious consequences.

[Borewit]

Should the playlist changes that have already been made, be saved before the process is getting cancelled.

Saving the result when a user hit cancel? We don't even save the playlist on success.

[Borewit]

At the "Playlists Directories" pane: Open the context menu of an open a folder that contain multiple playlists. Select, and then run "Repair Playlist". For consistency of operations, should not all the playlists visible the folder also be opened in the Playlists Editor first, before the repair process commence on all of them? Because, there are no visible cues of the actual repairs taking place, except this one.

Yes, agree, that's a total renegade operation. That deserves, Are you really, really sure you want to run this? confirmation. Maybe to get rid of it?

[touwys]

Saving the result when a user hit cancel?

It was meant as an observation, not a proposal. 😄 The context: if we are endeavouring to improve upon the speed in the search for matching tracks still, once the playlist repairs are initiated, can a further gain in speed be achieved by caching the search results up until the time of cancellation? Then, after having cancelled the repair getting processed, and as soon as it gets re-initiated, the new search-instance can pick up where the previous one was stopped i.e. by starting with the saved cache?

We don't even save the playlist on success.

As far as I know, we can save playlists on success. Please, elaborate?

---

Yes, agree, that's a total renegade operation. That deserves, Are you really, really sure you want to run this? confirmation. Maybe to get rid of it?

Well said. Then, the real question facing us is whether this "renegade" is to be welcomed, or whether it should be expelled. We have to consider whether it substantially contributes towards the overall functionality and performance of the app, in addition to whether an alternative path exists with which to achieve the same end. Even though the answers to these questions appear clear to me, I am going to leave the adjudication up to you, the developer, for you have the broader overview of its impact.

---

[touwys]

The repair process under review, does not start the repairs at the selected playlist, if, all of which, are already present in the playlist editor for the repair. The repair commences with the first playlist, chosen alphanumerically, as listed in the folder. Also, if the repair process is to be resumed after having been cancelled, the process again commences where it did at first, at playlist 1 in the folder, i.e. not where it stopped.

It processes the playlist in sequence of the tabs, not some file sequence. Which playlist is currently selected has no influence on the sequence.

I expected it to be like that; I simply jotted down what I did notice. It is a moot point whether, or not, it is advantageous to have the processing start at the playlist tab current in the Editor. However, what possible advantage does it offer to consistently have the focus leap away from the current playlist tab to focus on the first tab in the processing order? One would have expected the focus to remain at the current tab, irrespective of the background operations. Be that as it may, the benefit of staying the focus on the current tab is, in this particluar case, probably miniscule, albeit a nuisance, thus it makes sense to keep it the way it is done now.

[Borewit]

One would have expected the focus to remain at the current tab, irrespective of the background operations. Be that as it may, the benefit of staying the focus on the current tab is, in this particular case, probably minuscule, albeit a nuisance, thus it makes sense to keep it the way it is done now.

Yes, I agree. I don't like that focus going everywhere neither.