Build run (#6226341690, attempt #1) artifacts

@touwys, please note that github-action bot is pointing out the location the distribution, see previous message. If there are multiple messages, I pushed changes, last message reflects the latest change in the PR.

This PR currently introduces a problem. It crashed on a playlist with a few broken entries

Build run (#6226652467, attempt #1) artifacts

Build run (#6264648985, attempt #1) artifacts

Build run (#6264660802, attempt #1) artifacts

@touwys can you review this one?

@touwys can you review this one?

👍🏻 Can do tomorrow, DV.

Is this what you want me to look out for?

Expected difference:

The playlist table will updated less progressive
Repairs are performed slightly faster
Possible errors may now be prevented but that is very hard to test for. In following PR, 

Parallel processing repairing playlist #203, I will propose parallel processing, in that scenario weird errors are more likely to occur without his fix.

Is this what you want me to look out for?

Most important is that I did not break anything. If you see difference as described then that is line with expectation, if you see no difference, that is totally fine as well.

Aiming to make a stable release available, without bells and whistles, shall we release after this one, or are there ugly things pending?

Aiming to make a stable release available, without bells and whistles, shall we release after this one, or are there ugly things pending?

No, there is nothing ugly that is pending that I am aware of. From my point of view, you have taken care of the more detrimental current issue with the fix for #194 and #196. I am going to do another test run tomorrow with the one you released today, to see whether I notice anything untoward, and I will report back as soon as I can.

@Borewit

listFix()-2.8.0.12_Windows PR #202

During testing, I did not notice anything substantially different in operation from the previous release, listFix()-2.8.0.10_Windows PR #201.

Whether the following matters, or even is something worth considering, is moot: What I did notice was is that the progress bar of the repair-playlist process dialogue, does not progress smoothly, but hesitantly, until closing. Also, for what it's worth, because it is not based on fact-based observation, I got the impression that the repair process has now slowed down slightly, rather than the opposite.

•

progress bar

What I did notice was is that the progress bar of the repair-playlist process dialogue, does not progress smoothly, but hesitantly, until closing.

That's a good observation. That's because processes working in the background (the repair process) are not allowed to directly update the progress This is exactly what I have changed., and yes, it looks less good, but this is the way to prevent freezing applications, incomplete graphical updates, crashes and all kind of other rare unpredictable side effects.